kubernetes核心之kube-apiserver剖析

本文介绍了Kubernetes中apiserver如何使用go-restful框架提供RESTful服务,包括Container、WebService和Route的概念,以及gRPC框架的高效特性,如ProtocolBuffers序列化和HTTP/2协议的利用。同时,概述了kube-apiserver的命令行启动流程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

流程

  • 我们首先用一次简单的pod创建流程来演示apiserver是如何运行的
    在这里插入图片描述

go-restful原理

  • rest是现代客户端应用程序通过http协议与http server进行通信的机制,也是目前最流程的API设计规范,它支持基本的CRUD操作,具体规范就是用GET请求查询,用POST请求创建,用PUT请求修改,用DELETE请求删除
  • Kubernetes选择了使用go-restful框架,这种框架支持多个Container,每个Container都相当于一个http server,不同的Container之间检控不同的地址和端口,对外提供不同的http服务,每个Container可以包含多个WebService,WebService相当于一组不同服务的分类,每个WebService下面又包含了多个Router,Router根据http请求的URL路由到对应的处理函数(Handler Func)
    在这里插入图片描述

github.com/emicklei/go-restful@v2.9.5+incompatible/container.go

// Find best match Route ; err is non nil if no match was found
var webService *WebService
var route *Route
var err error
func() {
  c.webServicesLock.RLock()
  defer c.webServicesLock.RUnlock()
  webService, route, err = c.router.SelectRoute(
    c.webServices,
    httpRequest)
}()
...
route.Function(wrappedRequest, wrappedResponse)
...

gRPC框架

  • gRPC是Google开发的RPC服务,分为两部分,RPC框架和数据序列化框架
  • gPRC是一个超快速、超高效的RPC服务,可以在许多主流的编程语言、平台、框架中轻松创建高性能、可扩展的API和微服务
  • gRPC默认使用Protocol Buffers作为IDL(Interface Description Language)语言,Protocol Buffers,简称Protobuf,是一种高性能的开源二进制序列化协议,可以轻松定义服务并自动生成客户端库,主要用于结构化数据的序列化和反序列化
  • gRPC基于HTTP/2协议标准实现,它复用了很多HTTP/2的特性,例如双向流、流控制、报头压缩,以及通过单个TCP连接的多路复用请求等

命令行参数

https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/

启动流程

在这里插入图片描述

<think>好的,用户现在的问题是关于k8s集群中api-server服务消失,并且他们提到/etc/kubernetes/manifests/kube-apiserver.yaml这个配置文件丢失了,想要重新生成或获取一个示例。我需要仔细分析他们的需求,然后提供有效的解决方案。 首先,用户之前已经得到过如何重启api-server的指导,现在遇到了更具体的问题,即配置文件丢失。这可能发生在手动误删除、系统故障或升级过程中。我需要考虑不同部署方式的情况,尤其是kubeadm部署的集群,因为这是最常见的,而kubeadm通常会使用静态Pod来管理控制平面组件。 接下来,用户可能需要知道如何重新生成这个文件。对于kubeadm部署的集群,这个文件通常由kubeadm自动生成,位于/etc/kubernetes/manifests/目录下。如果文件丢失,可能需要通过kubeadm命令重新生成,或者从备份中恢复。如果没有备份,可能需要手动创建一个,但需要确保配置正确,否则可能导致集群无法正常工作。 我需要考虑用户可能没有备份,所以需要提供一个生成该文件的方法。kubeadm config print init-defaults命令可以输出默认的配置,用户可能需要根据现有的集群配置进行调整。另外,如果用户曾经使用kubeadm init的配置文件,可能可以从中提取相关部分。 另外,用户可能需要一个示例的yaml文件,以便手动创建。这时候需要提醒用户根据自己集群的实际参数进行调整,比如证书路径、etcd地址、服务网段等。需要强调示例中的参数可能需要修改,否则直接使用可能导致问题。 此外,用户可能不知道如何验证生成的配置文件是否正确,可能需要指导他们如何应用这个文件,并监控kubelet是否成功启动api-server的Pod。可能需要检查日志,确保没有配置错误。 还要考虑到用户可能使用的是高可用集群,有多个控制平面节点,这时候每个节点的kube-apiserver.yaml可能会有不同的参数,比如绑定到不同的IP地址。需要提醒用户注意这些差异。 最后,需要提醒用户备份的重要性,避免未来再次出现类似问题。如果用户没有备份,可能需要指导他们如何定期备份关键配置文件。 总结步骤可能包括: 1. 检查备份,如果有则恢复。 2. 使用kubeadm重新生成配置文件。 3. 手动创建配置文件,并提供示例,但需要根据实际情况调整。 4. 应用配置后,重启kubelet服务。 5. 验证api-server是否正常运行。 需要注意的潜在问题包括证书路径错误、etcd连接信息不正确、网络参数不匹配等,这些都会导致api-server无法启动。因此,在提供示例时,必须强调根据实际环境修改参数,并检查相关文件是否存在。 可能还需要提醒用户,如果是多节点集群,每个控制平面节点都需要正确的配置文件,确保一致性。此外,如果用户使用的是外部etcd,配置中的etcd服务器地址和证书路径也需要相应调整。 最后,确保回答结构清晰,分步骤说明,并提供验证方法,帮助用户确认操作成功。</think>以下是针对kube-apiserver.yaml配置文件丢失的完整解决方案,请根据你的集群部署情况选择对应方法: --- ### **一、kubeadm部署集群的恢复方案** #### 方法1:通过kubeadm重新生成 ```bash # 1. 生成默认配置文件模板 kubeadm config print init-defaults > kubeadm-config.yaml # 2. 修改旧集群配置参数(需要回忆或查找历史配置) # 重点检查以下参数: # - localAPIEndpoint.advertiseAddress # - networking.serviceSubnet/podSubnet # - kubernetesVersion # - 证书相关路径 # 3. 重新生成控制平面清单 sudo kubeadm init phase control-plane apiserver --config kubeadm-config.yaml # 4. 确认文件生成 ls -l /etc/kubernetes/manifests/kube-apiserver.yaml ``` #### 方法2:从其他控制平面节点复制(多节点集群) ```bash # 1. 从正常节点拷贝文件 scp root@healthy-control-plane:/etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/ # 2. 修改节点特定参数 sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml # 需要修改的参数: # --advertise-address=当前节点IP # --node-name=当前节点名称 ``` --- ### **二、手动创建配置文件模板** ```yaml apiVersion: v1 kind: Pod metadata: annotations: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.0.0.1:6443 labels: tier: control-plane component: kube-apiserver name: kube-apiserver namespace: kube-system spec: containers: - command: - kube-apiserver - --advertise-address=10.0.0.1 # 必须修改为当前节点IP - --allow-privileged=true - --authorization-mode=Node,RBAC - --client-ca-file=/etc/kubernetes/pki/ca.crt - --enable-admission-plugins=NodeRestriction - --enable-bootstrap-token-auth=true - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key - --etcd-servers=https://127.0.0.1:2379 # 如果是外部etcd需修改 - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key - --requestheader-allowed-names=front-proxy-client - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt - --requestheader-extra-headers-prefix=X-Remote-Extra- - --requestheader-group-headers=X-Remote-Group - --requestheader-username-headers=X-Remote-User - --secure-port=6443 - --service-account-issuer=https://kubernetes.default.svc.cluster.local - --service-account-key-file=/etc/kubernetes/pki/sa.pub - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --service-cluster-ip-range=10.96.0.0/12 # 需与历史配置一致 - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key image: registry.k8s.io/kube-apiserver:v1.27.4 # 需与实际版本一致 livenessProbe: failureThreshold: 8 httpGet: host: 10.0.0.1 # 当前节点IP path: /livez port: 6443 scheme: HTTPS initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 15 name: kube-apiserver readinessProbe: httpGet: host: 10.0.0.1 # 当前节点IP path: /readyz port: 6443 scheme: HTTPS initialDelaySeconds: 10 timeoutSeconds: 15 resources: requests: cpu: 250m volumeMounts: - mountPath: /etc/kubernetes/pki name: k8s-certs readOnly: true - mountPath: /etc/ssl/certs name: ca-certs readOnly: true hostNetwork: true priorityClassName: system-node-critical volumes: - hostPath: path: /etc/kubernetes/pki type: DirectoryOrCreate name: k8s-certs - hostPath: path: /etc/ssl/certs type: DirectoryOrCreate name: ca-certs ``` --- ### **三、关键配置验证步骤** ```bash # 1. 检查证书文件是否存在 ls -l /etc/kubernetes/pki/apiserver.* ls -l /etc/kubernetes/pki/etcd/ca.crt # 2. 应用配置文件后触发kubelet sudo systemctl restart kubelet # 3. 观察Pod创建状态 watch -n1 "crictl ps | grep kube-apiserver" # 4. 查看错误日志(如果启动失败) journalctl -u kubelet -n 100 --no-pager | grep -C 20 apiserver ``` --- ### **四、注意事项** 1. **IP地址一致性**: - `--advertise-address` 必须设置为当前节点的真实IP - 所有`host`字段需要与节点IP一致 2. **证书路径验证**: ```bash # 确认所有证书文件存在 sudo find /etc/kubernetes/pki -name 'apiserver*' ``` 3. **版本匹配原则**: - kube-apiserver镜像版本必须与集群当前版本一致 - 可通过其他控制平面节点查看历史版本: ```bash docker images | grep kube-apiserver ``` 4. **多节点集群处理**: - 每个控制平面节点的`--etcd-servers`参数需包含所有etcd节点地址 - 示例: ``` --etcd-servers=https://10.0.0.1:2379,https://10.0.0.2:2379,https://10.0.0.3:2379 ``` --- ### **五、灾备建议** 1. 定期备份关键配置文件: ```bash # 备份整个manifests目录 sudo tar czvf /backup/k8s-manifests-$(date +%Y%m%d).tar.gz /etc/kubernetes/manifests/ # 备份证书目录 sudo tar czvf /backup/k8s-pki-$(date +%Y%m%d).tar.gz /etc/kubernetes/pki/ ``` 2. 使用版本控制系统管理配置文件: ```bash # 将manifests目录纳入git管理 cd /etc/kubernetes sudo git init sudo git add manifests/ sudo git commit -m "Initial k8s configs" ``` 如果配置恢复后仍然无法启动,请检查以下日志获取具体错误信息: ```bash # 查看kubelet日志 journalctl -u kubelet --since "5 minutes ago" | grep -i apiserver # 查看容器启动日志(如果已创建容器) crictl logs $(crictl ps -a | grep apiserver | awk '{print $1}') ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Clarence Liu

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值