教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载本文以 Kubernetes Handbook 项目中的 guide/tls-bootstrapping.md 为核心骨架结合仓库内的 master 节点部署实践、node 节点部署实践、kubeconfig 创建实践 以及 systemd unit 配置 等一手资料系统讲解 kubelet 如何通过 TLS Bootstrap 机制向 kube-apiserver 申请客户端证书、证书如何被 controller-manager 的 CSR 审批控制器批准以及如何用 RBAC 精细管控引导权限。读完本文你将掌握从生成 bootstrap token、构建 bootstrap kubeconfig、配置 kube-apiserver / kube-controller-manager / kubelet 三大组件到手动审批 CSR 的完整可运行链路并能理解证书轮换Alpha 特性的原理与启用方式。TLS Bootstrap 机制概述在早期的 Kubernetes 集群中每个 kubelet 都需要管理员预先签发一对客户端证书再分发到每台 Node 节点上证书扩容、续期都非常繁琐。Kubernetes 1.4 引入了一个用于从集群级证书颁发机构CA请求证书的 API其原始目的正是为 kubelet 提供 TLS 客户端证书kubelet 首次启动时只携带一个 bootstrap token向 kube-apiserver 发起证书签名请求CSR经审批后由 kube-controller-manager 用集群 CA 签发正式客户端证书之后 kubelet 便使用这张证书与 API server 通信。从仓库的部署实践可以看到这一机制解决了「每节点预分发证书」的痛点在 创建 kubeconfig 文件 中明确指出「kubernetes 1.4 开始支持由 kube-apiserver 为客户端生成 TLS 证书的 TLS Bootstrapping 功能这样就不需要为每个客户端生成证书了该功能当前仅支持为 kubelet生成证书」。整个引导链路由三个角色协同完成组件职责kube-apiserver通过--token-auth-file认证 bootstrap token通过--client-ca-file信任集群 CA接收 kubelet 的 CSR 请求kube-controller-manager通过--cluster-signing-cert-file/--cluster-signing-key-file持有 CA 签名材料运行csrapproving控制器对 CSR 做基于 RBAC 的审批审批通过后签发证书kubelet携带 bootstrap kubeconfig 发起 CSR拿到签发的证书后写入自己的 kubeconfig并可启用证书轮换一、kube-apiserver 配置kube-apiserver 需要做两件事一是通过静态 token 文件认证 bootstrap 请求的身份二是通过客户端 CA 包来校验后续 kubelet 出示的客户端证书。1.1 Token 认证文件您必须提供一个 token 文件其中指定了至少一个分配给 kubelet 特定 bootstrap 组的 “bootstrap token”。该组将作为 controller-manager 配置中的默认批准控制器而用于审批。随着功能的成熟您应确保 token 被绑定到基于角色的访问控制RBAC策略上严格限制与证书配置相关的客户端请求。使用 RBAC 将 token 范围划分为组可以带来很大的灵活性——例如当您配置完成节点后可以禁用特定引导组的访问。Token 生成Token 可以是任意的但应表示为从安全随机数生成器如现代操作系统中的/dev/urandom导出的至少 128 位熵。例如head -c 16 /dev/urandom | od -An -t x | tr -d 产生的 token 类似02b50b05283e98dd0fd71db496ef01e8。仓库实践 创建 kubeconfig 文件 中给出了可直接复制的生成脚本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 EOFToken 文件格式token 文件是一个 CSV 文件每行包含 token、用户名、用户 UID以及可选的组名多个组时需加双引号。参考格式如下02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,system:kubelet-bootstrap注意system:kubelet-bootstrap的配置当只有一个组时不需要加引号。关于 token 文件的语法guide/authentication.md 中的「静态 Token 文件」一节给出了权威说明token 文件每行至少包含三列token,user,uid其后是可选组名例如token,user,uid,group1,group2,group3。同时该文档还指出目前 token 会无限期持续下去且不重启 API server 就无法更改 token 列表。在 kube-apiserver 命令中添加--token-auth-fileFILENAME标志可能放在您的 systemd unit 文件中来启用 token 文件。仓库中的实际配置可直接对照master 部署实践 master-installation.md 与 etc/kubernetes/apiserver 中的KUBE_API_ARGS真实示例KUBE_API_ARGS--authorization-modeRBAC --runtime-configrbac.authorization.k8s.io/v1beta1 --kubelet-httpstrue --experimental-bootstrap-token-auth --token-auth-file/etc/kubernetes/token.csv --service-node-port-range30000-32767 --tls-cert-file/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file/etc/kubernetes/ssl/kubernetes-key.pem --client-ca-file/etc/kubernetes/ssl/ca.pem --service-account-key-file/etc/kubernetes/ssl/ca-key.pem --etcd-cafile/etc/kubernetes/ssl/ca.pem --etcd-certfile/etc/kubernetes/ssl/kubernetes.pem --etcd-keyfile/etc/kubernetes/ssl/kubernetes-key.pem --enable-swagger-uitrue --allow-privilegedtrue --apiserver-count3 --audit-log-maxage30 --audit-log-maxbackup3 --audit-log-maxsize100 --audit-log-path/var/lib/audit.log --event-ttl1h参数要点--experimental-bootstrap-token-auth启用 Bootstrap Token 认证器该参数在 1.9 版本已从实验特性转为正式特性更名为--enable-bootstrap-token-auth见 master-installation.md 的 Kubernetes 1.9 说明--token-auth-file/etc/kubernetes/token.csv静态 token 文件路径--authorization-modeRBAC指定在安全端口使用 RBAC 授权模式拒绝未通过授权的请求如果使用了 kubelet TLS Bootstrap 机制则不能再指定--kubelet-certificate-authority、--kubelet-client-certificate和--kubelet-client-key选项否则后续 kube-apiserver 校验 kubelet 证书时会出现x509: certificate signed by unknown authority错误。对应的 systemd 启动方式可查看 systemd/kube-apiserver.service其通过EnvironmentFile-/etc/kubernetes/apiserver引入上述参数。1.2 客户端证书 CA 包在 kube-apiserver 命令中添加--client-ca-fileFILENAME标志以启用客户端证书认证指定包含签名证书的证书颁发机构包例如--client-ca-file/var/lib/kubernetes/ca.pem仓库实践中该参数为--client-ca-file/etc/kubernetes/ssl/ca.pem。CA 的创建方法见 创建 TLS 证书和秘钥使用 CloudFlare 的 cfssl 工具生成ca.pem/ca-key.pem其中signing表示该证书可用于签名其它证书生成的ca.pem中CATRUE并定义server auth客户端可用该 CA 验证 server 证书与client authserver 可用该 CA 验证客户端证书两种用途。二、kube-controller-manager 配置请求证书的 API 向 Kubernetes controller manager 中添加了证书颁发控制循环使用磁盘上的 cfssl 本地签名文件形式。目前所有签发的证书均为一年有效期并具有一系列关键用途。2.1 签名文件您必须提供证书颁发机构这样才能提供颁发证书所需的密码学材料。kube-apiserver 通过--client-ca-fileFILENAME标志来认证和采信该 CA。CA 的管理超出本文范围但建议为 Kubernetes 生成专用的 CA。假定证书和密钥都是 PEM 编码的。kube-controller-manager 的标志为--cluster-signing-cert-file/etc/path/to/kubernetes/ca/ca.crt --cluster-signing-key-file/etc/path/to/kubernetes/ca/ca.key仓库中的真实配置见 master-installation.md 的 controller-manager 配置文件KUBE_CONTROLLER_MANAGER_ARGS--address127.0.0.1 --service-cluster-ip-range10.254.0.0/16 --cluster-namekubernetes --cluster-signing-cert-file/etc/kubernetes/ssl/ca.pem --cluster-signing-key-file/etc/kubernetes/ssl/ca-key.pem --service-account-private-key-file/etc/kubernetes/ssl/ca-key.pem --root-ca-file/etc/kubernetes/ssl/ca.pem --leader-electtrue要点说明--cluster-signing-*指定的证书和私钥文件用来签名为 TLS Bootstrap 创建的证书和私钥--root-ca-file用来对 kube-apiserver 证书进行校验指定该参数后才会在 Pod 容器的 ServiceAccount 中放置该 CA 证书文件--address值必须为127.0.0.1因为 kube-apiserver 期望 scheduler 和 controller-manager 在同一台机器完整 unit 见 systemd/kube-controller-manager.service。2.2 审批控制器csrapproving在 Kubernetes 1.7 版本中实验性的「组自动批准」控制器被弃用新的csrapproving控制器作为 kube-controller-manager 的一部分被默认启用。控制器使用SubjectAccessReviewAPI即subjectaccessreviews资源来确定给定用户是否已被授权允许请求 CSR然后根据授权结果进行批准。为了防止与其他批准者冲突内置审批者不会明确地拒绝 CSR只是忽略未经授权的请求——也就是说只有显式获得 RBAC 授权的 CSR 才会被批准未授权的 CSR 保持 Pending 状态等待人工处理。控制器将 CSR 分为三个子资源nodeclient用户的客户端认证请求要求Osystem:nodes、CNsystem:node:(node name)即新节点首次申请客户端证书selfnodeclient更新具有相同O和CN的客户端证书的节点即节点续期自己的客户端证书selfnodeserver更新服务证书的节点ALPHA需要 feature gate 开启。当前确定 CSR 是否为selfnodeserver请求的检查与 kubelet 的凭据轮换实现Alpha 功能相关联。因此selfnodeserver的定义将来可能会改变并且需要 controller-manager 上的RotateKubeletServerCertificatefeature gate--feature-gatesRotateKubeletServerCertificatetrue2.3 用 RBAC ClusterRole 控制审批以下 RBACClusterRoles分别代表nodeclient、selfnodeclient和selfnodeserver三个子资源的审批能力。在以后的版本中可能会自动创建类似的角色。# A ClusterRole which instructs the CSR approver to approve a user requesting # node client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: approve-node-client-csr rules: - apiGroups: [certificates.k8s.io] resources: [certificatesigningrequests/nodeclient] verbs: [create] --- # A ClusterRole which instructs the CSR approver to approve a node renewing its # own client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: approve-node-client-renewal-csr rules: - apiGroups: [certificates.k8s.io] resources: [certificatesigningrequests/selfnodeclient] verbs: [create] --- # 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/v1beta1 metadata: name: approve-node-server-renewal-csr rules: - apiGroups: [certificates.k8s.io] resources: [certificatesigningrequests/selfnodeserver] verbs: [create]这三个 ClusterRole 的规则写得很微妙它们授予的不是certificatesigningrequests本身的权限而是对certificatesigningrequests/nodeclient等子资源的create权限——这正是 csrapproving 控制器通过 SubjectAccessReview 检查的内容。拥有对应子资源create权限的用户其 CSR 才会被自动批准。将这些权限授予 bootstrap token。例如要复制由已被移除的自动批准标志提供的行为由单个组批准所有的 CSR可以这样对应——该标志在 1.7 起已失效# REMOVED: This flag no longer works as of 1.7. --insecure-experimental-approve-all-kubelet-csrs-for-groupkubelet-bootstrap-token管理员需要创建一个ClusterRoleBinding来定位该组# Approve all CSRs for the group kubelet-bootstrap-token kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: auto-approve-csrs-for-group subjects: - kind: Group name: kubelet-bootstrap-token apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: approve-node-client-csr apiGroup: rbac.authorization.k8s.io让节点更新自己的凭据管理员可以构造一个ClusterRoleBinding来定位该节点的凭据kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: node1-client-cert-renewal subjects: - kind: User name: system:node:node-1 # Let node-1 renew its client certificate. apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: approve-node-client-renewal-csr apiGroup: rbac.authorization.k8s.io删除该绑定将会阻止节点更新客户端凭据一旦其证书到期实际上就会将其从集群中删除——这是收紧节点生命周期管控的有效手段。关于 RBAC 的通用背景Role / ClusterRole / RoleBinding / ClusterRoleBinding 的概念与system:前缀的系统角色可参考仓库内的 Kubernetes 中的 RBAC 支持。其中特别提到了system:node-bootstrapper等与引导相关的系统角色。在 node-installation.md 中也有对应实操kubelet 启动时向 kube-apiserver 发送 TLS bootstrapping 请求需要先将 bootstrap token 文件中的kubelet-bootstrap用户赋予system:node-bootstrappercluster 角色kubelet 才有权限创建证书签名请求cd /etc/kubernetes kubectl create clusterrolebinding kubelet-bootstrap \ --clusterrolesystem:node-bootstrapper \ --userkubelet-bootstrap--userkubelet-bootstrap是在/etc/kubernetes/token.csv文件中指定的用户名同时也写入了/etc/kubernetes/bootstrap.kubeconfig文件。此外kubelet 通过认证后向 kube-apiserver 发送 register node 请求需要将kubelet-nodes用户赋予system:nodecluster 角色和system:nodes组kubectl create clusterrolebinding kubelet-nodes \ --clusterrolesystem:node \ --groupsystem:nodes三、kubelet 配置3.1 构建 bootstrap kubeconfig要向 kube-apiserver 请求客户端证书kubelet 首先需要一个包含 bootstrap 身份验证 token 的 kubeconfig 文件路径。可以使用kubectl config set-cluster、set-credentials和set-context来构建此 kubeconfig 文件。为kubectl config set-credentials提供kubelet-bootstrap的名称并包含--tokentoken-valuekubectl config set-credentials kubelet-bootstrap --token${BOOTSTRAP_TOKEN} --kubeconfigbootstrap.kubeconfig仓库实践 create-kubeconfig.md 给出了完整版构建过程需先在 master 节点安装 kubectlcd /etc/kubernetes export KUBE_APISERVERhttps://172.20.0.113:6443 # 设置集群参数 kubectl config set-cluster kubernetes \ --certificate-authority/etc/kubernetes/ssl/ca.pem \ --embed-certstrue \ --server${KUBE_APISERVER} \ --kubeconfigbootstrap.kubeconfig # 设置客户端认证参数 kubectl config set-credentials kubelet-bootstrap \ --token${BOOTSTRAP_TOKEN} \ --kubeconfigbootstrap.kubeconfig # 设置上下文参数 kubectl config set-context default \ --clusterkubernetes \ --userkubelet-bootstrap \ --kubeconfigbootstrap.kubeconfig # 设置默认上下文 kubectl config use-context default --kubeconfigbootstrap.kubeconfig要点--embed-certs为true时表示将certificate-authority证书写入生成的bootstrap.kubeconfig文件中这样分发到 Node 时无需附带单独的 CA 文件设置客户端认证参数时没有指定私钥和证书——这正是 Bootstrap 机制的核心后续由 kube-apiserver 自动生成生成的bootstrap.kubeconfig文件可直接拷贝到所有 Node 机器的/etc/kubernetes/目录下。关于 BOOTSTRAP_TOKEN 的维护BOOTSTRAP_TOKEN 将被写入 kube-apiserver 使用的token.csv文件和 kubelet 使用的bootstrap.kubeconfig文件。如果后续重新生成了 BOOTSTRAP_TOKEN则需要更新token.csv并分发到所有机器的/etc/kubernetes/目录重新生成bootstrap.kubeconfig并分发到所有 Node 的/etc/kubernetes/目录重启 kube-apiserver 和 kubelet 进程重新 approve kubelet 的 CSR 请求。3.2 kubelet 启动标志启动 kubelet 时如果--kubeconfig指定的文件不存在则使用 bootstrap kubeconfig 向 API server 请求客户端证书。在批准 kubelet 的证书请求并收到回执后将包含生成的密钥和证书的 kubeconfig 文件写入由--kubeconfig指定的路径。证书和密钥文件将被放置在由--cert-dir指定的目录中。启动 kubelet 时启用 bootstrap 用到的标志--experimental-bootstrap-kubeconfig/path/to/bootstrap/kubeconfig仓库中 etc/kubernetes/kubelet 的完整示例KUBELET_ARGS--cgroup-driversystemd --cluster-dns10.254.0.2 --experimental-bootstrap-kubeconfig/etc/kubernetes/bootstrap.kubeconfig --kubeconfig/etc/kubernetes/kubelet.kubeconfig --require-kubeconfig --cert-dir/etc/kubernetes/ssl --cluster-domaincluster.local --hairpin-mode promiscuous-bridge --serialize-image-pullsfalse --allow-privilegedtrue各项参数说明结合 node-installation.md 的注解--experimental-bootstrap-kubeconfig指向 bootstrap kubeconfig 文件kubelet 使用该文件中的用户名和 token 向 kube-apiserver 发送 TLS Bootstrapping 请求该参数在 1.9 版本已正式更名为--bootstrap-kubeconfig--kubeconfig/etc/kubernetes/kubelet.kubeconfig指向目标 kubeconfig 文件此文件在首次启动 kubelet 之前并不存在CSR 通过后由 kubelet 自动生成--cert-dir/etc/kubernetes/sslCSR 批准后kubelet 自动在该目录创建证书和私钥文件kubelet-client.crt和kubelet-client.key并写入--kubeconfig文件--require-kubeconfig建议在--kubeconfig配置文件中指定 kube-apiserver 地址如果未指定--api-servers选项则必须指定--require-kubeconfig后才从配置文件读取 kube-apiserver 地址该参数在 1.10 版本被移除--cgroup-driver配置成systemd保持与 Docker 的 cgroup driver 一致否则 kubelet 启动会报kubelet cgroup driver: cgroupfs is different from docker cgroup driver: systemd错误如果使用 systemd 方式启动还需要额外增加两个参数--runtime-cgroups/systemd/system.slice --kubelet-cgroups/systemd/system.sliceKubernetes 1.8 起 kubelet 配置取消了KUBELET_API_SERVER--api-servers改用 kubeconfig 文件定义 master 地址因此需注释掉KUBELET_API_SERVER配置。3.3 证书轮换Alpha 特性在 1.7 中kubelet 实现了Alpha功能使其客户端和/或服务器都能轮换提供证书。可以分别通过 kubelet 中的RotateKubeletClientCertificate和RotateKubeletServerCertificate功能标志启用此功能但在未来版本中可能会以向后兼容的方式发生变化--feature-gatesRotateKubeletClientCertificatetrue,RotateKubeletServerCertificatetrueRotateKubeletClientCertificate让 kubelet 在其现有凭据到期时通过创建新的 CSR 来轮换其客户端证书RotateKubeletServerCertificate让 kubelet 在引导客户端凭据后还可以请求服务证书并轮换该证书服务证书目前不要求 DNS 或 IP SANs。与之对应的controller-manager 侧需要开启RotateKubeletServerCertificatefeature gate 并授权selfnodeserver子资源见上文 2.2、2.3 节构成完整闭环。四、kubectl 手动审批 CSR签名控制器不会立即签署所有证书请求。相反它会一直等待直到适当特权的用户被标记为「已批准」状态。这最终将是由外部审批控制器处理的自动化过程但对于 Alpha 版本的 API 来说可以由集群管理员通过 kubectl 命令手动完成。管理员可以使用以下命令查看与审批# 列出所有 CSR kubectl get csr # 查看某个 CSR 的详细信息 kubectl describe csr name在 1.6 版本以前没有直接的批准/拒绝命令审批者需要直接更新 CSR 的 Status 信息。此后的 Kubernetes 版本提供了kubectl certificate approve name kubectl certificate deny name仓库实践 node-installation.md 完整演示了这一流程# 查看未授权的 CSR 请求 $ kubectl get csr NAME AGE REQUESTOR CONDITION csr-2b308 4m kubelet-bootstrap Pending $ kubectl get nodes No resources found. # 通过 CSR 请求 $ kubectl certificate approve csr-2b308 certificatesigningrequest csr-2b308 approved $ kubectl get nodes NAME STATUS AGE VERSION 10.64.3.7 Ready 49m v1.6.1CSR 通过后kubelet 会自动生成 kubelet kubeconfig 文件和公私钥$ ls -l /etc/kubernetes/kubelet.kubeconfig -rw------- 1 root root 2284 Apr 7 02:07 /etc/kubernetes/kubelet.kubeconfig $ ls -l /etc/kubernetes/ssl/kubelet* -rw-r--r-- 1 root root 1046 Apr 7 02:07 /etc/kubernetes/ssl/kubelet-client.crt -rw------- 1 root root 227 Apr 7 02:04 /etc/kubernetes/ssl/kubelet-client.key -rw-r--r-- 1 root root 1103 Apr 7 02:07 /etc/kubernetes/ssl/kubelet.crt -rw------- 1 root root 1675 Apr 7 02:07 /etc/kubernetes/ssl/kubelet.key运维要点假如更新了 Kubernetes 的证书只要没有更新token.csv当重启 kubelet 后该 Node 就会自动加入集群而不会重新发送 certificaterequest也不需要在 master 节点上执行kubectl certificate approve操作——前提是不要删除 Node 节点上的/etc/kubernetes/ssl/kubelet*和/etc/kubernetes/kubelet.kubeconfig文件否则 kubelet 启动时会提示找不到证书而失败。如果启动 kubelet 时遇到证书相关的报错还有一个技巧将 master 节点上的~/.kube/config文件拷贝到 Node 节点的/etc/kubernetes/kubelet.kubeconfig位置这样就不需要通过 CSRkubelet 启动后会自动加入集群。五、完整链路小结与排错提示一条完整的 TLS Bootstrap 链路按顺序包含生成集群 CA 与各组件证书用 cfssl 生成ca.pem/ca-key.pem见 创建 TLS 证书和秘钥并分发到/etc/kubernetes/ssl/生成 bootstrap tokenhead -c 16 /dev/urandom | od -An -t x | tr -d 写入token.csv构建 bootstrap.kubeconfigkubectl config set-clusterset-credentials --tokenset-context见 create-kubeconfig.md配置 kube-apiserver--token-auth-file、--client-ca-file、--experimental-bootstrap-token-auth1.9 后为--enable-bootstrap-token-auth配置 kube-controller-manager--cluster-signing-cert-file/--cluster-signing-key-file创建approve-node-client-csr等 ClusterRole 并通过 ClusterRoleBinding 授权给 bootstrap 组配置并启动 kubelet--experimental-bootstrap-kubeconfig1.9 后为--bootstrap-kubeconfig、--kubeconfig、--cert-dir审批 CSRkubectl get csr→kubectl certificate approve name节点自动变为 Ready。排错提示源自仓库实践中的踩坑记录kube-apiserver 与 kube-controller-manager 的 CA 文件必须一致--client-ca-file与--cluster-signing-*使用同一套 CAkubelet 报x509: certificate signed by unknown authority通常是 apiserver 额外配置了--kubelet-certificate-authority等选项与 Bootstrap 机制冲突应移除kubelet 无法注册节点Kubernetes 1.9 需将 apiserver 的--authorization-mode配置为Node,RBAC并为kubelet-bootstrap用户创建system:node-bootstrapper绑定token 更新后必须同步更新token.csv与所有 Node 的bootstrap.kubeconfig并重启 kube-apiserver 与 kubelet同时重新 approve 新的 CSR。参考与延伸阅读TLS Bootstrap 原始提议与进度追踪feature #43创建 kubeconfig 文件bootstrap.kubeconfig 与 kube-proxy.kubeconfig 的完整构建与分发部署 master 节点kube-apiserver 与 kube-controller-manager 的 systemd 配置与启动部署 node 节点kubelet 启动、CSR 审批与集群验证全流程创建 TLS 证书和秘钥CA 与各组件证书的 cfssl 生成方法Kubernetes 中的 RBAC 支持RBAC 角色、绑定与系统角色guide/authentication.md静态 token 文件、Bootstrap Token 与 Service Account token 认证机制使用 kubeconfig 文件配置跨集群认证kubeconfig 文件结构详解配置文件参考etc/kubernetes/apiserver、etc/kubernetes/kubelet、systemd/kube-apiserver.service、systemd/kube-controller-manager.service赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes TLS Bootstrapping 机制详解Kubernetes TLS Bootstrapping 机制详解 概述 在 Kubernetes 集群中工作节点上的组件kubelet 和 kube pr文档教程云原生Traefik 双向 TLSmTLS测试证书生成与客户端证书透传实践Traefik 双向 TLSmTLS测试证书生成与客户端证书透传实践 本文以 Traefik 仓库集成测试夹具 integration/fixtures/t后端API网关负载均衡微服务网络云原生2025关键优化Nginx TLS客户端证书验证的RFC合规性实践指南2025关键优化Nginx TLS客户端证书验证的RFC合规性实践指南 在当今数字化时代网络安全已成为企业和个人关注的焦点。Nginx作为一款高性能的HTT后端API网关负载均衡网络创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
