目录
- 一、前言
- 二、Kubernetes 架构图
- 三、Kubernetes
- Kubernetes和Docker的关系
- 最小调度单元Pod
- 四、基本概念
- 容器生态和标准化
- 资源
- Workload资源:控制器对象
- 服务担保
- Service&Ingress
- 1. 两者的介绍以及与 OSI 七层模型关系
- 2. 常见的 Service 类型
- 3. Ingress 和 Ingress Controller
- 4. 如何选择 service 和 Ingress
- 探针Probe
- 五、高阶概念
- 存储
- 认证授权
- 安全
- 调度和驱逐
一、前言
在 WHAT - 容器化系列(一) 我们简单介绍过 Kubernetes 的产生过程以及它解决了大规模容器集群管理的难题,推动了容器技术在生产环境中的应用。
因此Kubernetes在容器化发展进程具备非常重要的意义,我们今天主要来介绍Kubernetes。
二、Kubernetes 架构图
三、Kubernetes
Kubernetes(常简称为K8s)是一个用于自动化部署、扩展和管理容器化应用程序的开源平台。它提供了一个容器编排的基础架构,使得管理和运行大规模容器化应用(或者说大规模容器集群管理)变得更加简单和高效。
Kubernetes和Docker的关系
Docker是一种容器化技术,用于打包、交付和运行应用程序。而Kubernetes则是一个容器编排平台,用于管理和调度这些Docker容器。
简而言之,Docker负责将应用程序打包为容器,而Kubernetes则负责在集群中运行、管理和调度这些容器。
最小调度单元Pod
Pod是Kubernetes中最小的部署和调度单元。
它是一个由一个或多个容器组成的逻辑单元,这些容器共享网络命名空间、IP地址和存储卷等资源。
Pod提供了一种封装、管理和调度容器的机制,使得它们可以作为一个整体来管理。
示例:创建一个独立的pod
kubectl run nginx --image=nginx
四、基本概念
容器生态和标准化
在 WHAT - 容器化系列(一) 中我们介绍过:CRI-O则是针对Kubernetes设计的轻量级容器运行时。
Kubernetes支持多种容器运行时,包括containerd等。它提供了一套标准化的API和规范,使得不同的容器运行时可以无缝集成和交互。
还有哪些运行时?
- KataContainer:一个基于轻量化vm实现的容器运行时,兼容OCI(by Intel);
- gvisor:一个基于用户态模拟kernel实现的容器运行时,兼容OCI(by google);
- rkt(rocket):coreos公司基于runc开发的容器运行时,不兼容OCI
- NablaContainers 类似gvisor的竞相产品(by IBM)
资源
Kubernetes允许你为容器分配CPU、内存等资源,并且提供了资源配额和限制的机制,以确保各个容器在资源利用上的平衡和稳定性。
CPU和内容资源单位:
- 1cpu指的是1vcore/hyperthread。0.1cpu表示方法为"100m",读作"100 millicpu"
- 内存单位K、M、G是10进制单位,Ki、Mi、Gi是二进制单位。1M=1000K,1Mi=1024Ki,注意两者在数量上略有差异。
Pod通过Request和Limit向k8s申请资源,理解为:
- Request。k8s为pod提供的最小担保资源。
- Limit。pod能够使用的最大资源上线。
注意,k8s将按照request指定数量为pod分配node资源。request不是pod实际的最小消耗值,但limit 是pod资源消耗的最大值。
Workload资源:控制器对象
Kubernetes支持多种工作负载类型,包括Deployment、StatefulSet、DaemonSet等,每种工作负载类型都有不同的用途和特点,可以满足不同的应用场景需求。
有哪些Workload资源?
- deployment&replicasets
- statefulset
- daemonset
- job
- cronjobs
示例:创建一个deployment
kubectl create deployment nginx-deployment --image=nginx
服务担保
Kubernetes通过Pod和Service等抽象层,提供了服务的高可用性和容错能力。它可以自动进行故障检测和恢复,确保应用程序在面临硬件或软件故障时仍然能够正常运行。
Kubernets提供3种QoS,分别是:
- Guaranteed, 即Request==Limit,Kubernetes为POD提供有担保的Qos。
- Burstable, 即Request <Limit,Kubernetes为POD提供最小request资源担保,POD可以burst到最大Limit的数量,但是 Request–>limist之间是不能担保的。
- BestEffort, 即不设置Request也不设置Limit,Kubernetes不为POD提供任何的担保。当资源不足的时候,此类POD将最先被限制或者踢出。
资源不足踢出优先级:BestEffort --> Burstable --> Guaranteed
Service&Ingress
1. 两者的介绍以及与 OSI 七层模型关系
Service是Kubernetes中用于暴露应用程序的服务,它可以将外部流量负载均衡到一组后端Pod。而Ingress则是一种管理外部访问到集群内服务的方式,通过定义Ingress规则,可以将外部流量路由到集群内部的Service。
Service 和 Ingress 是 Kubernetes 中用于管理网络访问的关键组件,它们与 OSI 模型的七层网络模型之间存在着一定的关系。
下面是它们与 OSI 模型的关系:
Service(服务):
在 OSI 模型中,Service 可以与第四层(传输层)和第七层(应用层)对应。
-
第四层:Service 提供了一种在网络传输层面上实现服务发现和负载均衡的机制。它通过 Cluster IP、Node Port 或者 LoadBalancer 类型来暴露服务,并且可以在相同的服务后面负载均衡流量到多个 Pod。
-
第七层:在某种程度上,Service 也可以与应用层相关联,因为它可以基于应用程序的名称、端口号等信息进行服务发现和路由。此外,Kubernetes 还支持通过 Headless Service 来直接暴露 Pod 的 IP 地址,这种模式更贴近应用层的服务发现。
- Ingress(入口):
Ingress 主要与 OSI 模型的第七层(应用层)相关。
- 第七层:Ingress 允许在应用层面上对流量进行路由和访问控制。它基于 HTTP/HTTPS 协议对流量进行路由,并支持基于域名、路径等条件进行流量分发。因此,Ingress 可以看作是一种高级的服务暴露机制,能够根据应用层的信息对流量进行更细粒度的控制。
2. 常见的 Service 类型
- Cluster:在集群内部暴露服务端口
- NodePort:在集群外部通过nodeport的形式暴露服务端口
- Loadbalancer:通过云供应商的LB服务暴露端口,需要云供应商controller的支持
流量示意图:
3. Ingress 和 Ingress Controller
我们可以先做一个类比,以 ingress-nginx-controller 举例:
- ingress-nginx-controller 理解为 nginx 服务器
- ingress 对象理解为 nginx 的 virtual-server 配置文件,只是 ingress 是 k8s 的标准对象
具体来说,在 Kubernetes 中,Ingress 是一种 API 资源,用于定义从集群外部到集群内部服务的 HTTP 和 HTTPS 路由规则。简单来说,Ingress 允许你将外部流量路由到集群内的 Service。但是,Ingress 本身并不处理流量,它只是定义了一组规则。而 Ingress Controller 则是负责实际处理 Ingress 规则并路由流量的组件。它监听 Kubernetes API,检测到 Ingress 资源的变化后,会根据定义的规则配置底层的负载均衡器(如 Nginx、HAProxy、Traefik 等),以确保流量按照 Ingress 规则进行正确的路由。
简单来说,Ingress 是规则,Ingress Controller 是实现这些规则的组件。在 Kubernetes 中,通常会配合使用 Ingress 资源和 Ingress Controller 来实现对外服务的访问控制和流量路由。
流量示意图:
4. 如何选择 service 和 Ingress
4层tcp流量场景
业务为4层流量,只能使用service方式暴露,比如车联网mqtt协议、dns udp 协议等。
7层http流量场景:
一般的http和https为单向认证流量,即可以使用service 4层方式暴露,也可以使用ingress 7层方式暴露。
http流量细分场景:
-
后端服务需要验证client端证书的https双向流量,因为密钥交换需要在4层完成,必须用service方式暴露
-
后端服务唯一,http/https(单向)流量不需要路由的,既可以用service方式,也可以用ingress方案暴露
-
后端服务多个,http/https(单向)流量需要配置转发路由的情况,必须用ingress方式暴露
探针Probe
Kubernetes通过探针(Probe)来检查容器的健康状态,包括存活性探针(Liveness Probe)和就绪性探针(Readiness Probe)。这些探针可以帮助Kubernetes确定何时启动、停止或重新启动容器,以确保应用程序的稳定性和可用性。
k8s提供3类probe探针,分别是:
- Readiness Probe 探测通过表示pod状态正常,pod接入service接收请求。
- Liveness Probe 探测通过表示pod状态存活,不通过表示pod僵死自动重启pod
- Startup Probe POD重启初始化节点探测pod存活状态,一旦通过则有Livenss接管
存活状态探测(主要用于定义初始化时长)。
以上探针支持http、tcp、grpc、command 等方式。
五、高阶概念
k8s 还包括如下一些高级概念,可以按需自行学习。
存储
- persistent volumes(pv)
- Persistent Volume Claim (pvc)
- Storage Class (sc)
认证授权
- authenticating
- RBAC
安全
- PodSecurityPolicy
- NetworkPolicy
调度和驱逐
- Nodeseletor/Affinity
- priority和preempt
- Taints和Tolerations
- api 扩展
- CustomResourceDefinitions
- API server aggregation