【k8s】kubelet 和 API Server的关系

文章目录

概述
[1. # kubelet 和 API Server 之间的关系](# kubelet 和 API Server 之间的关系)
- [**1. 角色和功能**](#1. 角色和功能)
- - [**1.1 kubelet**](#1.1 kubelet)
  - [**1.2 API Server**](#1.2 API Server)
- [**2. 交互关系**](#2. 交互关系)
- - [**2.1 kubelet 从 API Server 获取指令**](#2.1 kubelet 从 API Server 获取指令)
  - [**2.2 kubelet 向 API Server 上报状态**](#2.2 kubelet 向 API Server 上报状态)
  - [**2.3 kubelet 与 API Server 的认证和授权**](#2.3 kubelet 与 API Server 的认证和授权)
- [**3. 典型交互场景**](#3. 典型交互场景)
- - [**3.1 创建 Pod**](#3.1 创建 Pod)
  - [**3.2 健康检查**](#3.2 健康检查)
  - [**3.3 节点资源上报**](#3.3 节点资源上报)
- [**4. 核心通信机制**](#4. 核心通信机制)
- - [**4.1 API Server 是核心中枢**](#4.1 API Server 是核心中枢)
  - [**4.2 kubelet 的通信模型**](#4.2 kubelet 的通信模型)
  - [**4.3 TLS 安全通信**](#4.3 TLS 安全通信)
- [**5. 总结：kubelet 与 API Server 的关系**](#5. 总结：kubelet 与 API Server 的关系)
- **总结**
[2. kubelet 和 API Server 的运行方式](#2. kubelet 和 API Server 的运行方式)
- [**1. kubelet：每个节点一个进程（不是容器）**](#1. kubelet：每个节点一个进程（不是容器）)
- - [**kubelet 是什么？**](#kubelet 是什么？)
  - [**每个节点一个 kubelet**](#每个节点一个 kubelet)
  - **职责**
- [**2. API Server：高可用部署，多实例容器**](#2. API Server：高可用部署，多实例容器)
- - [**API Server 是什么？**](#API Server 是什么？)
  - [**API Server 的部署方式**](#API Server 的部署方式)
  - **运行方式**
- [**3. 总结：kubelet 和 API Server 的运行数量**](#3. 总结：kubelet 和 API Server 的运行数量)
- [**4. 典型的生产环境布局**](#4. 典型的生产环境布局)
- - [**Worker 节点**](#Worker 节点)
  - [**Master 节点（高可用模式）**](#Master 节点（高可用模式）)
参考

概述

简单来说 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）。
工作流程 ：
1. kubelet 使用 watch 或 list API 从 API Server 获取指令。
2. 确保节点上运行的容器与 API Server 中的期望状态一致（同步状态）。

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，但这是少见的。

每个节点都有如下的进程：

bash 复制代码

$ 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:

bash 复制代码

$ 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>

在控制节点对应的进程：

bash 复制代码

]$ 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 实例的访问。

参考

02.K8S架构详解
 深度好文：我花了10个小时，写出了这篇K8S架构解析