kubernetes 关键概念总结

kubernetes 关键概念总结

service

每个 service 对应一个 cluster IP，cluster IP 对应的服务网段最初是在配置 kube-apiserver、kube-controller-manager 和 kube-proxy 的 systemd unit 时指定的，如 kube-apiserver 参数为 --service-cluster-ip-range。

Service 提供提供了一种稳定访问一组pod的方式。Service 使用 clusterIP:port（默认方式）对外暴露服务，将外部流量从 clusterIP:port 导入到 service 中定义的selector 标签指定的 endpoint 的 targetport 端口上（默认情况下 targetport 将被设置为与 port 字段相同的值）。Kube-proxy 则为 service 提供了一种实现负载均衡的策略。Endpoint 会在 service 创建后被自动创建。

kube-dns

集群中可以通过配置Kube-dns来实现服务发现的功能。Kube-dns 实现了服务名到cluster IP 的映射关系。Kube-dns通常会为 service 赋予一个名为“service名称 .namespace.svc.cluster.local” 的A记录，用来解析 service 的 cluster IP。如果访问 default namespace下的服务，可以通过“service 名称”直接访问；如果访问其他namespace 下的服务，可以通过“service 名称 .namespace”访问。k8s 会为每个容器提供默认的 /etc/resolv.conf 配置，内容为：

search default.svc.cluster.local svc.cluster.local cluster.local; nameserver 10.0.0.10.

集群通过查询 /etc/resolv.conf 文件的 nameserver 字段来确定 dns 服务器，该文件是在 kubelet 服务启动配置中指定— cluster-dns，并在服务启动后自动生成的。当用“service 名称”访问服务时，最终会使用 default.svc.cluster.local 这条 search  记录拼接完整的服务名称；当使用“service名称 .namespace”时，最终会使用svc.cluster.local 这条 search 记录。

serviceaccount

Serviceaccount就是pod中的process访问kubernetes API的account。Serviceaccount只关联了一个 secret 资源作为 token，该 token 也叫 service-account-token，是真正在 API server 验证环节起作用的。

service-account-token 分为3部分：

ca.crt：API Server 的 CA 公钥证书，用于 POD 的 process 对 API server 服务端数字证书进行校验使用，由 kube-controller-manager 参数--root-ca-file 指定；namespace：secret 所在的 namespace 值的 base64 编码token：用 API server 私钥签发（sign）的 bearer tokens 的 base64 编码，用于 POD 访问 API server 的身份验证（Authorization header 首部）

一旦 API Server 发现 client 发起的 request 使用的是 service account token 的方式，API Server 就会自动采用signed bearer token方式进行身份校验。而request 就会使用携带的 service account token 参与验证。该 token 是 API Server 在创建service account时用kube-controller-manager启动参数：--service-account-private-key-file 指定的私钥签署(sign)的，同时必须指定 kube-apiserver 参数--service-account-key-file（如果没指定的话，会使用 –tls-private-key-file 替代）为该私钥对应的公钥，用来在认证阶段验证 token（You must pass a service account private key file to the token controller in the controller-manager by using the --service-account-private-key-file option. The private key will be used to sign generated service account tokens. Similarly, you must pass the corresponding public key to the kube-apiserver using the --service-account-key-file option. The public key will be used to verify the tokens during authentication），也就是说该证书对通过CN 和 O 指定了 serviceaccount 的授权权限。

通过authenticating后，API Server将根据Pod username所在的group system:serviceaccounts和system:serviceaccounts:(NAMESPACE)的权限对其进行authority 和admission control 两个环节的处理。（Service Accounts have usernames with the system:serviceaccount: prefix and belong to groups with the system:serviceaccounts: prefix，形如system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)）

不管是自动生成的 token 还是手动创建的 token 的值都是一样的，因为进行签署token 的 –service-account-key-file 是同一个。

Serviceaccount 中的 token 是 API server 私钥签署的，POD 在对 API Server 发起请求的时候会带上该 token，以确保能够通过 API server 的认证。对serviceaccount 的授权通过对 serviceaccount 对应的用户或组进行 RBAC 控制即可

参见：

https://k8smeetup.github.io/docs/admin/authorization/rbac/

tls-bootstrapping

当前该功能仅支持为 kubelet 生成证书。Bootstrap-token 是在新建集群或者在现有集群中添加新节点时使用的，为 kubelet 提供 tls 客户端证书。Bootstrap-token 被定义成一个特定类型的 secrets(bootstrap.kubernetes.io/token)。

kubelet 发起的 CSR 请求都是由 controller manager 来做实际签署的，对于 controller manager 来说，TLS bootstrapping 下 kubelet 发起的 CSR 请求大致分为以下三种

nodeclient: kubelet 以 O=system:nodes 和 CN=system:node:(node name) 形式发起的 CSR 请求，仅在第一次启动时会产生；selfnodeclient: kubelet client renew 自己的证书发起的 CSR 请求(与上一个证书就有相同的 O 和 CN)，kubelet renew 自己作为 client 跟 apiserver 通讯时使用的证书产生；selfnodeserver: kubelet server renew 自己的证书发起的 CSR 请求，kubelet 首次申请或后续 renew 自己的 10250 api 端口证书时产生

export BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')cat > token.csv <

绑定用户kubelet-bootstrap到内置ClusterRole（system:node-bootstrapper）：kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

对于 bootstrap下的 kubelet 的 CSR 的审批可以手动审批，也可以自动审批。

手动审批：

需要将用户与内置的 clusterrole system:node-strapper 绑定，并注意设置证书过期时间（默认有效期为1年）：设置 kube-controller-manager参数--experimental-cluster-signing-duration设置为10年（防止证书过期）：8760h0m0s

手动签发证书命令为：kubectl certificate approve XXX （xxx为CSR，使用kubectl get csr获取）

自动审批：

k8s 针对 bootstrap 下 kubelet 发起的3种 CSR 给出了3种对应的 clusterrole，想要 kubelet 能够自动续期，只要将适当的 clusterrole 绑定到 kubelet 自动续期时采用的用户或用户组上即可。基于3种 clusterrole 需要创建3个 clusterrolebinding。1.8 中已经创建了前两条 clusterrole，还需要创建一条：

# A ClusterRole which instructs the CSR approver to approve a node requesting a# serving cert matching its client cert.kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeserverrules:- apiGroups: ["certificates.k8s.io"]  resources: ["certificatesigningrequests/selfnodeserver"]  verbs: ["create"]

3 个 clusterrole 对应的 clusterbingding 如下：

# 自动批准 system:bootstrappers 组用户 TLS bootstrapping 首次申请证书的 CSR 请求kubectl create clusterrolebinding node-client-auto-approve-csr --clusterrole=system:certificates.k8s.io:certificatesigningrequests:nodeclient --group=system:bootstrappers# 自动批准 system:nodes 组用户更新 kubelet 自身与 apiserver 通讯证书的 CSR 请求kubectl create clusterrolebinding node-client-auto-renew-crt --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --group=system:nodes# 自动批准 system:nodes 组用户更新 kubelet 10250 api 端口证书的 CSR 请求kubectl create clusterrolebinding node-server-auto-renew-crt --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeserver --group=system:nodes

启动自动续期：kubelet启动时增加--feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true，--rotate-certificates；kube-controller-manager启动时增加--feature-gates=RotateKubeletServerCertificate=true

kubelet 端口

10250 kubelet API –kublet 暴露出来的端口，通过该端口可以访问获取 node 资源以及状态

10255 readonly API –kubelet 暴露出来的只读端口，访问该端口不需要认证和鉴权，该 http server 提供查询资源以及状态的能力

参考：

https://mritd.me/2018/01/07/kubernetes-tls-bootstrapping-note/

https://kubernetes.io/docs/tasks/tls/certificate-rotation/

出处：http://dwz.date/bQX9

8月献礼

分享本文/以下海报，即可有机会抽取【docker+k8s】课程一套

8.8日18:00准时开奖品