【k8s】kubelet 和 API Server的关系
kubelet 和 API Server 是 Kubernetes 中紧密合作的两个组件。kubelet 承担了节点级别的资源管理和容器生命周期管理,而 API Server 则是集群级别的控制中心。两者通过安全通信和状态同步,确保集群中的资源调度和应用运行达到预期状态。
·
文章目录
概述
简单来说 API Server 是个全局管控者,是一个总经理,负责接收诉求,然后分派下属去做具体的事务。kubelet 是一个部门经理,从总经理那拿到具体的任务,做完后还要写报告,汇总到总经理处。
1. # kubelet 和 API Server 之间的关系
1. 角色和功能
1.1 kubelet
- 定义:
- kubelet 是运行在每个节点上的主要组件,负责管理该节点上的容器。
- 功能:
- 监听 API Server 的指令(如创建、删除 Pod)。
- 监控 Pod 和容器的运行状态。
- 通过 CRI(Container Runtime Interface)与容器运行时(如 Docker 或 containerd)交互。
- 上报节点和 Pod 的状态到 API Server。
- 处理本地事件(如健康检查、日志管理等)。
1.2 API Server
- 定义:
- API Server 是 Kubernetes 控制平面的核心组件,用于处理所有 RESTful API 请求。
- 功能:
- 接收和处理集群的配置变更请求(如创建、更新资源)。
- 存储集群的状态数据到 etcd。
- 提供认证和授权服务,确保安全的集群访问。
- 通知各个组件(如 kubelet、controller-manager)执行资源调度和变更。
2. 交互关系
2.1 kubelet 从 API Server 获取指令
- kubelet 定期向 API Server 查询其所在节点的工作负载信息(如 Pod 和 ConfigMap)。
- 工作流程:
- kubelet 使用
watch
或list
API 从 API Server 获取指令。 - 确保节点上运行的容器与 API Server 中的期望状态一致(同步状态)。
- kubelet 使用
2.2 kubelet 向 API Server 上报状态
- kubelet 定期向 API Server 上报:
- 节点状态(如资源使用情况、健康状态)。
- Pod 状态(如正在运行的容器信息)。
- API Server 接收状态信息并存储在 etcd 中,供其他组件使用。
2.3 kubelet 与 API Server 的认证和授权
- kubelet 通过 TLS 和 API Server 建立安全通信。
- 每个 kubelet 都有自己的认证凭据(通常是证书),以便与 API Server 交互。
- API Server 使用 RBAC(角色访问控制)确定 kubelet 的权限范围。
3. 典型交互场景
3.1 创建 Pod
- 用户提交请求:
用户通过kubectl
或其他工具向 API Server 提交 Pod 的创建请求。 - 调度器分配节点:
调度器(scheduler)根据资源情况,将 Pod 分配给某个节点。 - kubelet 接收指令:
kubelet 查询 API Server,获取分配给本节点的 Pod 信息。 - kubelet 执行操作:
kubelet 调用容器运行时(如 containerd),拉取镜像并运行容器。 - 状态上报:
kubelet 定期将 Pod 和容器的状态回报给 API Server。
3.2 健康检查
- 定义健康检查:
用户在 Pod 定义中设置健康检查(Liveness/Readiness Probes)。 - kubelet 执行检查:
kubelet 定期检查容器健康状态(通过 HTTP 或命令)。 - 上报状态:
kubelet 将健康状态上报给 API Server,影响服务的调度和负载均衡。
3.3 节点资源上报
- kubelet 启动后:
kubelet 定期向 API Server 上报节点的 CPU、内存等资源信息。 - 资源存储:
API Server 将节点资源信息存储在 etcd 中,供调度器等组件使用。
4. 核心通信机制
4.1 API Server 是核心中枢
- API Server 是 kubelet 和其他控制平面组件之间的桥梁。
- 所有操作(如创建 Pod、更新 ConfigMap)都通过 API Server 进行。
4.2 kubelet 的通信模型
- 主动拉取:kubelet 主动从 API Server 拉取资源定义(如 Pod)。
- 状态上报:kubelet 定期将状态通过 HTTP API 上报给 API Server。
4.3 TLS 安全通信
- kubelet 和 API Server 使用 HTTPS 进行通信。
- kubelet 的客户端证书由集群管理员或
kubeadm
初始化时生成。
5. 总结:kubelet 与 API Server 的关系
组件 | kubelet | API Server |
---|---|---|
角色 | 节点上的资源管理者 | 集群的控制中枢 |
通信方向 | 拉取指令、上报状态 | 接收状态、下发指令 |
依赖关系 | 依赖 API Server 提供工作负载信息 | 依赖 kubelet 上报的节点和 Pod 状态 |
认证方式 | TLS 证书认证,RBAC 授权 | 管控所有集群组件的访问权限 |
总结
kubelet 和 API Server 是 Kubernetes 中紧密合作的两个组件。kubelet 承担了节点级别的资源管理和容器生命周期管理,而 API Server 则是集群级别的控制中心。两者通过安全通信和状态同步,确保集群中的资源调度和应用运行达到预期状态。
2. kubelet 和 API Server 的运行方式
1. kubelet:每个节点一个进程(不是容器)
kubelet 是什么?
- kubelet 是一个 进程,不是运行在容器中的组件。
- 它直接运行在每个节点的操作系统上,负责管理该节点上的 Pod 和容器。
每个节点一个 kubelet
- 在每个 Kubernetes 节点(无论是 Master 节点 还是 Worker 节点),都会运行一个 kubelet 进程。
- 该进程通过 TLS 证书与 API Server 通信。
- 运行方式:
- 通常以 系统服务(systemd service) 的形式运行。
- 在某些环境(如 K3s 或某些特殊部署)中,可能会以容器形式运行 kubelet,但这是少见的。
每个节点
都有如下的进程:
$ ps -ef|grep kubelet
root 25354 1 8 Dec02 ? 10:24:07 /usr/bin/kubelet --v=0 --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --config=/etc/kubernetes/kubelet.dynamicConfig --log-file=/paasdata/op-log/k8s/kubelet.klog --node-ip=194.246.9.5 --pod-infra-container-image=swr:2512/admin/op-containers-pause:v7.23.30.03.19125487 --cert-dir=/etc/kubernetes/certs/apiserver_to_kubelet_cert --root-dir=/paasdata/docker --network-plugin=cni --logtostderr=false --alsologtostderr=false --stderrthreshold=2 --maximum-dead-containers-per-container=1 --minimum-container-ttl-duration=1m --hostname-override=194.246.9.5
职责
- 同步 Pod 的实际状态和期望状态。
- 管理容器的生命周期(启动、停止、健康检查)。
- 定期上报节点和 Pod 的状态信息。
2. API Server:高可用部署,多实例容器
API Server 是什么?
- API Server 是 Kubernetes
控制平面
的核心组件,用于处理用户和其他组件的 API 请求。
API Server 的部署方式
- 单节点部署:
- 在小型或测试集群中,API Server 可能作为一个容器运行在单个 Master 节点上。
- 高可用部署(HA):
- 在生产环境中,通常会部署多个 API Server 实例,运行在多个 Master 节点上。
- 使用 负载均衡(Load Balancer) 或虚拟 IP 将流量分发到不同的 API Server 实例。
运行方式
- 通常以容器形式运行。
- 默认情况下,使用 Kubernetes 的默认安装工具(如 kubeadm),API Server 会以 静态 Pod 的形式运行。这意味着:
- 它的配置文件存储在
/etc/kubernetes/manifests/kube-apiserver.yaml
。 - kubelet 自动将其作为 Pod 拉起。
- 它的配置文件存储在
仅在控制节点才有api-server 的pod:
$ kubectl get po -A -o wide|grep -i kube-api
kube-system kube-apiserver-194.246.9.3 1/1 Running 1 (5d6h ago) 10d 194.246.9.3 194.246.9.3 <none> <none>
kube-system kube-apiserver-194.246.9.4 1/1 Running 1 (5d6h ago) 10d 194.246.9.4 194.246.9.4 <none> <none>
kube-system kube-apiserver-194.246.9.5 1/1 Running 1 (5d6h ago) 10d 194.246.9.5 194.246.9.5 <none> <none>
在控制节点对应的进程:
]$ ps -ef|grep bin/kube-apiserver
root 27275 27259 6 Dec02 ? 07:55:44 /usr/local/bin/kube-apiserver --v=0 --etcd-servers=https://194.246.9.5:2379,https://194.246.9.3:2379,https://194.246.9.4:2379 --service-cluster-ip-range=123.123.0.0/16 --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,DefaultStorageClass,Priority,EventRateLimit,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook --default-not-ready-toleration-seconds=60 --default-unreachable-toleration-seconds=60 --tls-cert-file=/etc/kubernetes/certs/server.crt --tls-private-key-file=/etc/kubernetes/certs/server.key --tls-min-version=VersionTLS12 --client-ca-file=/etc/kubernetes/certs/ca.crt --service-account-key-file=/etc/kubernetes/certs/sign_sa_pub.key --service-account-signing-key-file=/etc/kubernetes/certs/sign_sa_pri.key --service-account-issuer=https://kubernetes.default.svc.cluster.local --api-audiences=kubernetes.default.svc --secure-port=6443 --bind-address=194.246.9.5 --apiserver-count=3 --advertise-address=194.246.9.5 --admission-control-config-file=/etc/kubernetes/admission_control/control-config.yaml --log-file=/paasdata/op-log/k8s/kube-apiserver.klog --profiling=false --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/paasdata/op-log/k8s/audit.klog --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=1000 --audit-log-compress=true --anonymous-auth=false --etcd-cafile=/etc/kubernetes/certs/etcd/Etcdtrustca.crt --etcd-certfile=/etc/kubernetes/certs/etcd/etcd-client.crt --etcd-keyfile=/etc/kubernetes/certs/etcd/etcd-client.key --encryption-provider-config=/etc/kubernetes/pki/encrypt.conf --event-ttl=15m --requestheader-client-ca-file=/etc/kubernetes/certs/proxy-ca.crt --requestheader-allowed-names=aggregator,gateway --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --proxy-client-cert-file=/etc/kubernetes/certs/proxy.crt --proxy-client-key-file=/etc/kubernetes/certs/proxy.key --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --kubelet-certificate-authority=/etc/kubernetes/certs/apiserver_to_kubelet_cert/ca.crt --authentication-token-webhook-config-file=/etc/kubernetes/webhook.kubeconfig --authorization-mode=Node,RBAC,Webhook --authorization-webhook-config-file=/etc/kubernetes/author-webhook.kubeconfig --feature-gates=ServerSideApply=false,CSIStorageCapacity=true,StorageObjectInUseProtection=false,IPv6DualStack=false --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 --kubelet-client-certificate=/etc/kubernetes/certs/apiserver_to_kubelet_cert/client.crt --kubelet-client-key=/etc/kubernetes/certs/apiserver_to_kubelet_cert/client.key --strict-transport-security-directives=max-age=31536000,includeSubDomains,preload --service-node-port-range=30000-32767 --auto-service-node-port-range=30601-30798,30803-30889,30895-30999,31901-31996,32077-32665 --logtostderr=false --alsologtostderr=false --stderrthreshold=4 --allow-privileged=true --runtime-config=events.k8s.io/v1=false,storage.k8s.io/v1alpha1=true --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
root 760726 2415847 0 14:39 pts/73 00:00:00 grep --color=auto bin/kube-apiserver
3. 总结:kubelet 和 API Server 的运行数量
组件 | 运行数量 | 是否容器化 |
---|---|---|
kubelet | 每个节点一个进程 | 通常不是容器化,但特殊部署可能是容器化 |
API Server | 单实例或多实例(生产环境建议多实例) | 通常容器化,作为静态 Pod 运行 |
4. 典型的生产环境布局
Worker 节点
- 每个节点运行 1 个 kubelet 进程。
Master 节点(高可用模式)
- 每个 Master 节点运行一个 API Server 容器。
- 使用负载均衡器管理对多个 API Server 实例的访问。
参考
更多推荐
已为社区贡献1条内容
所有评论(0)