核心组件组成
Kubernetes 主要由以下几个核心组件组成:
- etcd :保存整个集群的状态
- API Server:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制
- Controller Manager:负责维护集群的状态,如故障检测、自动扩展、滚动更新等
- Scheduler:负责资源的调度、按照预定的调度策略将pod调度到相应的节点上
- Kubelet:负责维护容器的生命周期、同时也负责Volume(CVI)和网络(CNI)的管理
- Container Runtime:负责镜像管理以及pod和容器的真正运行(CRI)
- Kube-proxy:负责为Service提供cluster内部的服务发现和负载均衡
组件之间的通信
API Server 负责 etcd 存储的所有操作,且只有 API Server 才直接操作 etcd 集群
Kubernetes 多组件之间的通信原理为:
- API Server 负责 etcd 存储的所有操作,且只有 API Server 才直接操作 etcd 集群
- API Server 对内(集群中的其他组件)和对外(用户)提供统一的 REST API,其他组件均通过 API Server 进行通信
- Controller Manager、Scheduler、Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况,并对资源作相应的操作
- 所有需要更新资源状态的操作均通过 API Server 的 REST API 进行
- API Server 也会直接调用 Kubelet API(如 logs, exec, attach 等),默认不校验 Kubelet 证书,但可以通过 --kubelet-certificate-authority 开启(而 GKE 通过 SSH 隧道保护它们之间的通信)
# 比如创建一个pod的流程:
1.用户通过 REST API 创建一个 Pod
2.API Server 将其写入 etcd
3.Scheduluer 检测到未绑定 Node 的 Pod,开始调度并更新 Pod 的 Node 绑定
4.Kubelet 检测到有新的 Pod 调度过来,通过 Container Runtime 运行该 Pod
5.Kubelet 通过 Container Runtime 取到 Pod 状态,并更新到 API Server 中
各组件使用的端口号
kube-apiserver
核心功能:资源的操作入口
- 提供集群管理的REST API接口、包括认证授权、准入控制、数据校验以及集群状态变更等
- 负责其他模块之间的数据交互和通信的枢纽。
- 只有 ApiServer 能直接操作 Etcd,其他模块均需要通过它来查询或修改数据
REST API
kube-apiserver 支持同时提供 https(默认监听在 6443 端口)和 http API(默认监听在 127.0.0.1 的 8080 端口),其中 http API 是非安全接口,不做任何认证授权机制,不建议生产环境启用。两个接口提供的 REST API 格式相同,参考 Kubernetes API Reference 查看所有 API 的调用格式
在实际使用中,通常通过 kubectl 来访问 apiserver,也可以通过 Kubernetes 各个语言的 client 库来访问 apiserver。
在使用 kubectl 时,打开调试日志也可以看到每个 API 调用的格式,比如
$ kubectl --v=8 get pods
# 查询 Kubernetes API 支持的 API 版本
$ kubectl api-versions
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
apps/v1beta1
apps/v1beta2
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
metrics.k8s.io/v1beta1
networking.k8s.io/v1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1
# 集群支持的API版本
$ kubectl api-versions | grep apps
apps/v1
apps/v1beta1
apps/v1beta2
# 所有支持的资源
$ kubectl api-resources
# 获取特定组 apps 的资源
$ kubectl api-resources --api-group=storage.k8s.io
NAME SHORTNAMES APIGROUP NAMESPACED KIND
storageclasses sc storage.k8s.io false StorageClass
volumeattachments storage.k8s.io false VolumeAttachment
# 资源详细解释
$ kubectl explain svc
$ kubectl explain svc.spec
kube-controller-manager
核心功能:是 Kubernetes 的大脑,通过与apiserver交互来实现整个集群的状态,确保集群处于预期的状态
图中cloud-controller-manager 在 Kubernetes 启用 Cloud Provider 的时候才需要,用来配合云服务提供商的控制
kube-controller-manager 由以下的控制器组成
每个控制器的作用参考:
Replication Controller
Node Controller
CronJob Controller
Daemon Controller
Deployment Controller
Endpoint Controller
Garbage Collector
Namespace Controller
Job Controller
Pod AutoScaler
RelicaSet
Service Controller
ServiceAccount Controller
StatefulSet Controller
Volume Controller
Resource quota Controller
***
kube-controller-manager 由一系列的控制器组成,这些控制器可以划分为三组
必须启动的控制器
EndpointController
ReplicationController
PodGCController
ResourceQuotaController
NamespaceController
ServiceAccountController
GarbageCollectorController
DaemonSetController
JobController
DeploymentControlle
ReplicaSetController
HPAController
DisruptionController
StatefulSetController
CronJobController
CSRSigningController
CSRApprovingController
TTLController
默认启动的可选控制器,可通过选项设置是否开启
TokenController
NodeController
ServiceController
RouteController
PVBinderController
AttachDetachController
默认禁止的可选控制器,可通过选项设置是否开启
BootstrapSignerController
TokenCleanerController
kube-controller-manager 启动示例
kube-controller-manager \
--enable-dynamic-provisioning=true \
--feature-gates=AllAlpha=true \
--horizontal-pod-autoscaler-sync-period=10s \
--horizontal-pod-autoscaler-use-rest-clients=true \
--node-monitor-grace-period=10s \
--address=127.0.0.1 \
--leader-elect=true \
--kubeconfig=/etc/kubernetes/controller-manager.conf \
--cluster-signing-key-file=/etc/kubernetes/pki/ca.key \
--use-service-account-credentials=true \
--controllers=*,bootstrapsigner,tokencleaner \
--root-ca-file=/etc/kubernetes/pki/ca.crt \
--service-account-private-key-file=/etc/kubernetes/pki/sa.key \
--cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt \
--allocate-node-cidrs=true \
--cluster-cidr=10.244.0.0/16 \
--node-cidr-mask-size=24
# 注意:
Controller Manager 在启动时,如果设置了--cluster-cidr 参数,对于没有设置Sepc.PodCIDR的Node节点生成一个CIDR地址
并用该CIDR地址设置节点的Spec.PodCIDR属性,防止不同的节点的CIDR地址发生冲突。
#高可用
在启动时设置 --leader-elect=true 后,controller manager 会使用多节点选主的方式选择主节点。
只有主节点才会调用 StartControllers() 启动所有控制器,而其他从节点则仅执行选主算法
#Node驱逐
默认情况下,Kubelet 每隔 10s (--node-status-update-frequency=10s) 更新 Node 的状态,而 kube-controller-manager 每隔 5s 检查一次 Node 的状态 (--node-monitor-period=5s)。
kube-controller-manager 会在 Node 未更新状态超过 40s 时 (--node-monitor-grace-period=40s),将其标记为 NotReady (Node Ready Condition: True on healthy, False on unhealthy and not accepting pods, Unknown on no heartbeat)。
当 Node 超过 5m 未更新状态,则 kube-controller-manager 会驱逐该 Node 上的所有 Pod。
Kubernetes 会自动给 Pod 添加针对 node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable 的容忍度,且配置 tolerationSeconds=300。
你可以通过 tolerations 配置 Pod 的容忍度,来覆盖默认的配置:
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 10
- key: "node.kubernetes.io/not-ready"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 10
Node 控制器在节点异常后,会按照默认的速率(--node-eviction-rate=0.1,即每10秒一个节点的速率)进行 Node 的驱逐。
Node 控制器按照 Zone 将节点划分为不同的组,再跟进 Zone 的状态进行速率调整:
Normal:所有节点都 Ready,默认速率驱逐。
PartialDisruption:即超过33% 的节点 NotReady 的状态。
当异常节点比例大于 --unhealthy-zone-threshold=0.55 时开始减慢速率:
- 小集群(即节点数量小于 --large-cluster-size-threshold=50):停止驱逐
- 大集群,减慢速率为 --secondary-node-eviction-rate=0.01
FullDisruption:所有节点都 NotReady,返回使用默认速率驱逐。但当所有 Zone 都处在 FullDisruption 时,停止驱逐。
标签:--,核心,Controller,API,io,组件,k8s,v1beta1 From: https://www.cnblogs.com/littlecc/p/18282014