kubernetes关键概念总结

时间:2024-10-21 11:33:32
  • 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  /dev/urandom | od -An -t x | tr -d ' ')
cat > token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,,"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/