5.3 kubelet

目录

• 1. kubernetes创建跟证书和秘钥
• 2. ETCD集群部署及维护
• 3. kubectl部署以及基本使用
• 4. Master节点部署及维护
  • 4.1 kube-apiserver
  • 4.2 kube-scheduler
  • 4.3 kube-controller-manager
• 5. Node节点部署及维护
  • 5.1 Flannel部署及维护
  • 5.2 kubernetes runtime部署及维护
  • 5.3 kubelet
  • 5.4 kube-proxy

kubelet 运行在每个 worker 节点上，接收 kube-apiserver 发送的请求，管理 Pod 容器，执行交互式命令，如 exec、run、logs 等。

kubelet 启动时自动向 kube-apiserver 注册节点信息

为确保安全，部署时关闭了 kubelet 的非安全 http 端口，对请求进行认证和授权，拒绝未授权的访问(如 apiserver、heapster 的请求)。

部署策略:

• 动态创建 bootstrap token，而不是在 apiserver 中静态配置；
• 使用 TLS bootstrap 机制自动生成 client 和 server 证书，过期后自动轮转；
• 在 KubeletConfiguration 类型的 yaml 文件配置主要参数；
• 关闭只读端口，在安全端口 10250 接收 https 请求，对请求进行认证和授权，拒绝匿名访问和非授权访问；
• 使用 kubeconfig 访问 apiserver 的安全端口；

部署软件规划:

IP	部署软件包
10.40.61.116	kubelet
10.40.58.153	kubelet
10.40.58.154	kubelet

01.创建 Bootstrapping Token

Token可以是任意的包含128 bit的字符串，可以使用安全的随机数发生器生成。

export BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')

cat > bootstrap-token.csv <

注意：在进行后续操作前请检查 bootstrap-token.csv 文件，确认其中的 ${BOOTSTRAP_TOKEN} 环境变量已经被真实的值替换。

kube-apiserver启动时需要使用--token-auth-file=bootstrap-token.csv

如果后续重新生成了 BOOTSTRAP_TOKEN，则需要：

• 更新 bootstrap-token.csv 文件，分发到所有机器 (master 和 node）的 /etc/kubernetes/ 目录下，分发到node节点上非必需；
• 重新生成 bootstrap.kubeconfig 文件，分发到所有 node 机器的 /etc/kubernetes/ 目录下；
• 重启 kube-apiserver 和 kubelet 进程；
• 重新 approve kubelet 的 csr 请求；

02.创建 bootstrap kubeconfig 文件

执行下面的命令时需要先安装kubectl命令，请参考安装kubectl命令行工具。

• --embed-certs 为 true 时表示将 certificate-authority 证书写入到生成的 bootstrap.kubeconfig 文件中；

• 设置客户端认证参数时没有指定秘钥和证书，后续由 kube-apiserver 自动生成；

  export KUBE_APISERVER="https://apiserver-p001.svc.gxd88.cn:6443"
  

• 设置集群参数

  kubectl config set-cluster kubernetes \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=${KUBE_APISERVER} \
    --kubeconfig=bootstrap.kubeconfig
  

• 设置客户端认证参数

  kubectl config set-credentials kubelet-bootstrap \
    --token=${BOOTSTRAP_TOKEN} \
    --kubeconfig=bootstrap.kubeconfig
  

• 设置上下文参数

  kubectl config set-context default \
    --cluster=kubernetes \
    --user=kubelet-bootstrap \
    --kubeconfig=bootstrap.kubeconfig
  

• 设置默认上下文

  kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
  

• 分发 kubeconfig 文件

将两个 kubeconfig 文件分发到所有 Node 机器的 /srv/kubernetes/kubeconfig 目录

cp bootstrap.kubeconfig  /srv/kubernetes/kubeconfig

03.维护配置文件

新版本的kubelet很多参数已经废弃只能通过创建单独的配置文件方式维护, 启动程序时使用--config

根据主机的实际情况替换address和healthzBindAddress

cat > /srv/kubernetes/conf/kubelet-config.yaml <

authentication.anonymous.enabled: 设置为 false，不允许匿名访问 10250 端口；
authentication.x509.clientCAFile: 指定签名客户端证书的 CA 证书，开启 HTTPs 证书认证；
authentication.webhook.enabled=true: 开启 HTTPs bearer token 认证。

04.使用systemd管理kubelet

根据实际情况替换--hostname-override, 并且kube-proxy配置的过程中也需要指定该参数

cat > /etc/systemd/system/kubelet.service <

• 如果设置了 --hostname-override 选项，则 kube-proxy 也需要设置该选项，否则会出现找不到 Node 的情况；
• --bootstrap-kubeconfig：指向 bootstrap kubeconfig 文件，kubelet 使用该文件中的用户名和 token 向 kube-apiserver 发送 TLS Bootstrapping 请求；
• K8S approve kubelet 的 csr 请求后，在 --cert-dir 目录创建证书和私钥文件，然后写入 --kubeconfig 文件；

注意：kube-controller-manager 需要配置 --cluster-signing-cert-file 和 --cluster-signing-key-file 参数，才会为 TLS Bootstrap 创建证书和私钥。

05.启动/停止 kubelet

sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable kubelet.service

kube-schedulercan be started and stopped as follows:

sudo systemctl start kubelet.service
sudo systemctl stop  kubelet.service

06.验证

0601.授权

kubelet 首次启动时向 kube-apiserver 发送证书签名请求，必须通过后 kubernetes 系统才会将该 Node 加入到集群。

启动时会查找--kubeletconfig参数对应的文件是否存在，如果不存在则使用 --bootstrap-kubeconfig 指定的 kubeconfig 文件向 kube-apiserver 发送证书签名请求 (CSR)。

kube-apiserver 收到 CSR 请求后，对其中的 Token 进行认证，认证通过后将请求的 user 设置为 kubelet-bootstrap:，user 设置为 user=kubelet-bootstrap，这一过程称为 Bootstrap Token Auth。

kubelet 创建 CSR 请求后，下一步需要创建被 approve，有两种方式：

• kube-controller-manager 自动 aprrove；
• 手动使用命令 kubectl certificate approve；

CSR 被 approve 后，kubelet 向 kube-controller-manager 请求创建 client 证书，kube-controller-manager 中的 csr approving controller 使用 SubjectAccessReview API 来检查 kubelet 请求（对应的 User 是 kubelet-bootstrap）是否具有相应的权限。

默认情况下，这个 user 没有创建 CSR 的权限，因此 kubelet 会启动失败，可通过如下方式创建一个 clusterrolebinding，将 user kubelet-bootstrap 和 clusterrole system:node-bootstrapper 绑定。

kubectl create clusterrolebinding kubelet-bootstrap \
  --clusterrole=system:node-bootstrapper \
  --user=kubelet-bootstrap

注意：
--user=kubelet-bootstrap 是在 [创建 TLS Bootstrapping Token](#创建 TLS Bootstrapping Token) 章节中 bootstrap-token.csv 文件中指定的用户名，bootstrap-token.csv 同时也写入了 bootstrap.kubeconfig 文件

0602.查看kubelet服务

$ systemctl status kubelet|grep active
   Active: active (running) since 四 2020-04-16 16:25:45 CST; 1 day 22h ago

0603.查看端口

netstat -lnpt|grep kubelet
tcp        0      0 10.40.61.116:10248      0.0.0.0:*               LISTEN      27496/kubelet
tcp        0      0 10.40.61.116:10250      0.0.0.0:*               LISTEN      27496/kubelet
tcp        0      0 127.0.0.1:37325         0.0.0.0:*               LISTEN      27496/kubelet

• 10248: healthz http 服务；
• 10250: https 服务，访问该端口时需要认证和授权（即使访问 /healthz 也需要）；
• 未开启只读端口 10255；

07.允许approve CSR 请求，生成 kubelet client 证书

如果觉的手动允许approve麻烦可以直接配置自动approve

0701.手动允许approve CSR

查看未授权的 CSR 请求:

$ kubectl  get csr
NAME        AGE   SIGNERNAME                      REQUESTOR                                          CONDITION
csr-fsk6w   21s   kubernetes.io/kubelet-serving   system:node:py-modelo2o08cn-p005.pek3.example.net   Pending

通过 CSR 请求:

$ kubectl certificate approve csr-fsk6w
certificatesigningrequest "csr-2b308" approved

$ kubectl get nodes
NAME                                   STATUS   ROLES    AGE   VERSION
py-modelo2o08cn-p005.pek3.example.net   Ready       74m   v1.18.1

自动生成了 kubelet kubeconfig 文件和公私钥:

$ ls  -l /srv/kubernetes/kubeconfig/kubelet.kubeconfig
-rw------- 1 root root 2326 4月  15 12:23 kubeconfig/kubelet.kubeconfig

$ ls -al /srv/kubernetes/pki/kubelet*
-rw------- 1 root root 1265 4月  15 12:23 /srv/kubernetes/pki/kubelet-client-2020-04-15-12-23-43.pem
lrwxrwxrwx 1 root root   58 4月  15 12:23 /srv/kubernetes/pki/kubelet-client-current.pem -> /srv/kubernetes/pki/kubelet-client-2020-04-15-12-23-43.pem
-rw-r--r-- 1 root root 2355 4月  14 15:38 /srv/kubernetes/pki/kubelet.crt
-rw------- 1 root root 1675 4月  14 15:38 /srv/kubernetes/pki/kubelet.key
-rw------- 1 root root 1342 4月  15 13:37 /srv/kubernetes/pki/kubelet-server-2020-04-15-13-37-56.pem
lrwxrwxrwx 1 root root   58 4月  15 13:37 /srv/kubernetes/pki/kubelet-server-current.pem -> /srv/kubernetes/pki/kubelet-server-2020-04-15-13-37-56.pem

0702.自动approve

创建三个 ClusterRoleBinding，分别用于自动 approve client、renew client 证书。

根据官方文档介绍 renew server证书基于安全的考虑要自己实现controller

Note: The CSR approving controllers implemented in core Kubernetes do not approve node serving certificates for security reasons. To use RotateKubeletServerCertificate operators need to run a custom approving controller, or manually approve the serving certificate requests.

$ cat > csr-crb.yaml <

auto-approve-csrs-for-group：自动 approve node 的第一次 CSR； 注意第一次 CSR 时，请求的 Group 为 system:kubelet-bootstrap；

auto-approve-renewals-for-nodes：自动 approve node 后续过期的 client 证书，自动生成的证书 Group 为 system:nodes;

创建资源:

kubectl apply -f csr-crb.yaml

08.授予 kube-apiserver 访问 kubelet API 的权限

因为kubelet启动时已经关闭了anonymous认证， 指定了authentication.x509.clientCAFile证书认证, 并且kube-apiserver中使用--kubelet-client-certificate和--kubelet-client-key标志启动apiserver， 所以需要进行对应的授权

kube-apiserver 的启动参数如下

/srv/kubernetes/bin/kube-apiserver \
  --kubelet-https=true \
  --kubelet-client-certificate=/srv/kubernetes/pki/apiserver.pem \
  --kubelet-client-key=/srv/kubernetes/pki/apiserver-key.pem

apiserver.pem 中的CN为kubernetes，所以需要对该用户授权访问kubelet资源的授权

• verb=*, resource=nodes, subresource=proxy
• verb=*, resource=nodes, subresource=stats
• verb=*, resource=nodes, subresource=log
• verb=*, resource=nodes, subresource=spec
• verb=*, resource=nodes, subresource=metrics

授权指令

$ kubectl create clusterrolebinding kube-apiserver:kubelet-apis --clusterrole=system:kubelet-api-admin --user kubernetes

如果不授权会报如下错误

kubectl  logs kubernetes-dashboard-7c4995887f-zt4rp -n kube-system
Error from server (Forbidden): Forbidden (user=kubernetes, verb=get, resource=nodes, subresource=proxy) ( pods/log kubernetes-dashboard-7c4995887f-zt4rp)

更多细节请看https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/#kubelet-authentication

09.控制证书轮转时间

由于kubelet的证书是kube-controller-manager负责签发的， 在kube-controller-manager启动参数中添加如下配置：

/srv/kubernetes/bin/kube-controller-manager \ 
    --experimental-cluster-signing-duration=24h0m0s 

默认时间为8760h0m0s也就是1年

09.Q&A

Q:
遇到了一个大坑， 我查看了大量的bootstrap TLS 相关的文档， 文档上大部分的都是说使用bootstrap kubeconfig自动的签名node节点的证书，又根据文档查看说如果不指定--kubeconfig会自动使用bootstrap kubeconfig的APIserver地址， 但是一直报错

server.go:560] standalone mode, no API client

A:
启动的时候要指定--bootstrap-kubeconfig, 也要指定--kubeconfig， 这里的--kubeconfig是指证书生成以后自动生成的kubelet.kubeconfig的目录

Q:

 failed to run Kubelet: cannot create certificate signing request: certificatesigningrequests.certificates.k8s.io is forbidden: User "kubelet-bootstrap" cannot create resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope

A:
kubelet 启动时向 kube-apiserver 发送 TLS bootstrapping 请求，需要先将 bootstrap token 文件中的 kubelet-bootstrap 用户赋予 system:node-bootstrapper cluster 角色(role)， 然后 kubelet 才能有权限创建认证请求(certificate signing requests)：

kubectl create clusterrolebinding kubelet-bootstrap \

--clusterrole=system:node-bootstrapper
--user=kubelet-bootstrap

Q:
因为我没有安装cni-plugin， 所以我没有指定cni相关的配置， worker几点一直是NotReady的状态， 但是查看官方文档说kubelet存在默认的docker网络插件， 我使用的就是docker， 那么问题出现在那里呢？

kubelet: E0415 12:24:19.385879   22377 kubelet.go:2187] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
kubelet: W0415 12:24:23.101522   22377 cni.go:237] Unable to update cni config: no networks found in /srv/kubernetes/cni/net.d

A:
经过万能的--help查看， 他是这么说的

--network-plugin string The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to docker.

但是又看--help人家说container-runtime默认就是docker， 情急之下删除了所有cni相关的配置， 发现居然起来了， 那看来就是这样了

Q:
查看kubelet日志报如下的错误

kubelet: E0512 13:20:08.674812   17205 controller.go:178] failed to update node lease, error: Operation cannot be fulfilled on leases.coordination.k8s.io "py-modelo2o08cn-p005.pek3.wecash.net": the object has been modified; please apply your changes to the latest version and try again

A:
报错的主要原因是--hostname-override=py-modelo2o08cn-p005.pek3.wecash.net 三个节点配置的相同， 需要清理rm -rf kubelet-*证书文件和rm -rf kubelet.kubeconfig文件