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
options ndots:5

集群通过查询/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 端口证书时产生

首次启动时，kube-apiserver会指定--token-auth-file=FILENAME来启用用户的token，同时该用户的token和apiserver的CA证书被写入了kubelet的bootstrap.kubeconfig文件中，这样在首次请求时，kubelet 使用 bootstrap.kubeconfig 中的 apiserver CA 证书来与 apiserver 建立 TLS 通讯，使用 bootstrap.kubeconfig 中的用户kubelet-bootstrap（需要创建clusterRoBingding来将预设用户与内置的system:node-bootstrapper绑定到一起） 的Token 来向 apiserver 声明自己的 RBAC 授权身份（用户为kubelet-bootstrap，组为system:kubelet-bootstrap）。

export BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')
cat > token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"

绑定用户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: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeserver
rules:
- 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/