作者：石义峰

起源：恒生 LIGHT 云社区

装置部署神器 -Kubeadm

Kubeadm 是一个提供了 kubeadm init 和 kubeadm join 的工具，作为创立 Kubernetes 集群的“快捷路径”的最佳实际。

kubeadm 通过执行必要的操作来启动和运行最小可用集群。依照设计，它只关注启动疏导，而非配置机器。同样的，装置各种“精益求精”的扩大，例如 Kubernetes Dashboard、监控计划、以及特定云平台的扩大，都不在探讨范畴内。

相同，咱们心愿在 kubeadm 之上构建更高级别以及更加合规的工具，现实状况下，应用 kubeadm 作为所有部署工作的基准将会更加易于创立一致性集群。

如何装置

要装置 kubeadm, 请参照【零根底入门云原生 -k8s，轻松实战】k8s 实际——装置配置及运行.

kubeadm 常用命令

kubeadm init 初始搭建管制立体节点

[kubeadm join]() 搭建工作节点并将其退出到集群中

[kubeadm upgrade]() 降级 Kubernetes 集群到新版本

[kubeadm config]() 配置集群命令。如果应用 v1.7.x 或更低版本的 kubeadm，初始化集群时则应用 kubeadm upgrade 来配置你的集群

[kubeadm token]() 用于治理 kubeadm join 应用的令牌

[kubeadm reset]() 用于复原 / 回滚通过 kubeadm init 或者 kubeadm join 命令对节点进行的任何变更

[kubeadm certs]() 用于治理 Kubernetes 证书

[kubeadm kubeconfig]() 用于治理 kubeconfig 文件

[kubeadm version]() 用于打印 kubeadm 的版本信息

[kubeadm alpha]() 用于预览一组可用于收集社区反馈的个性

命令行工具 kubelet

kubelet 是在每个 Node 节点上运行的次要“节点代理”。它能够应用以下之一向 apiserver 注册：主机名（hostname）；笼罩主机名的参数；某云驱动的特定逻辑。

kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个形容 Pod 的 YAML 或 JSON 对象。kubelet 承受通过各种机制（次要是通过 apiserver）提供的一组 PodSpec，并确保这些 PodSpec 中形容的容器处于运行状态且运行状况良好。kubelet 不治理不是由 Kubernetes 创立的容器。

除了来自 apiserver 的 PodSpec 之外，还能够通过以下三种形式将容器清单（manifest）提供给 kubelet。

文件（File）：利用命令行参数传递门路。kubelet 周期性地监督此门路下的文件是否有更新。监督周期默认为 20s，且可通过参数进行配置。

HTTP 端点（HTTP endpoint）：利用命令行参数指定 HTTP 端点。此端点的监督周期默认为 20 秒，也能够应用参数进行配置。

HTTP 服务器（HTTP server）：kubelet 还能够侦听 HTTP 并响应简略的 API（目前没有残缺标准）来提交新的清单。

kube-apiserver

Kubernetes API 服务器验证并配置 API 对象的数据，这些对象包含 pods、services、replicationcontrollers 等。API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端，所有其余组件都通过该前端进行交互。

kube-controller-manager

Kubernetes 控制器管理器是一个守护过程，内嵌随 Kubernetes 一起公布的外围管制回路。在机器人和自动化的利用中，管制回路是一个永不休止的循环，用于调节零碎状态。在 Kubernetes 中，每个控制器是一个管制回路，通过 API 服务器监督集群的共享状态，并尝试进行更改以将以后状态转为冀望状态。目前，Kubernetes 自带的控制器例子包含正本控制器、节点控制器、命名空间控制器和服务账号控制器等。

kube-proxy

Kubernetes 网络代理在每个节点上运行。网络代理反映了每个节点上 Kubernetes API 中定义的服务，并且能够执行简略的 TCP、UDP 和 SCTP 流转发，或者在一组后端进行 循环 TCP、UDP 和 SCTP 转发。以后可通过 Docker-links-compatible 环境变量找到服务集群 IP 和端口，这些环境变量指定了服务代理关上的端口。有一个可选的插件，能够为这些集群 IP 提供集群 DNS。用户必须应用 apiserver API 创立服务能力配置代理。

kube-scheduler

Kubernetes 调度器是一个管制面过程，负责将 Pods 指派到节点上。调度器基于束缚和可用资源为调度队列中每个 Pod 确定其可非法搁置的节点。调度器之后对所有非法的节点进行排序，将 Pod 绑定到一个适合的节点。在同一个集群中能够应用多个不同的调度器；kube-scheduler 是其参考实现。

Kubelet 认证 / 鉴权

kubelet 的 HTTPS 端点公开了 API，这些 API 能够拜访敏感度不同的数据，并容许你在节点上和容器内以不同级别的权限执行操作。

本文档介绍了如何对 kubelet 的 HTTPS 端点的拜访进行认证和鉴权。

Kubelet 身份认证

默认状况下，未被已配置的其余身份认证办法回绝的对 kubelet 的 HTTPS 端点的申请会被视为匿名申请，并被赋予 system:anonymous 用户名和 system:unauthenticated 组。

要禁用匿名拜访并向未经身份认证的申请发送 401 Unauthorized 响应，请执行以下操作：

• 带 --anonymous-auth=false 标记启动 kubelet

要对 kubelet 的 HTTPS 端点启用 X509 客户端证书认证：

• 带 --client-ca-file 标记启动 kubelet，提供一个 CA 证书包以供验证客户端证书
• 带 --kubelet-client-certificate 和 --kubelet-client-key 标记启动 apiserver

要启用 API 持有者令牌（包含服务帐户令牌）以对 kubelet 的 HTTPS 端点进行身份验证，请执行以下操作：

• 确保在 API 服务器中启用了 authentication.k8s.io/v1beta1 API 组
• 带 --authentication-token-webhook 和 --kubeconfig 标记启动 kubelet
• kubelet 调用已配置的 API 服务器上的 TokenReview API，以依据持有者令牌确定用户信息

Kubelet 鉴权

任何胜利通过身份验证的申请（包含匿名申请）之后都会被鉴权。默认的鉴权模式为 AlwaysAllow，它容许所有申请。

细分对 kubelet API 的拜访权限可能有多种起因：

• 启用了匿名身份验证，然而应限度匿名用户调用 kubelet API 的能力
• 启用了持有者令牌认证，但应限度任意 API 用户（如服务帐户）调用 kubelet API 的能力
• 启用了客户端证书身份验证，但仅应容许已配置的 CA 签名的某些客户端证书应用 kubelet API

要细分对 kubelet API 的拜访权限，请将鉴权委派给 API 服务器：

• 确保在 API 服务器中启用了 authorization.k8s.io/v1beta1 API 组
• 带 --authorization-mode=Webhook 和 --kubeconfig 标记启动 kubelet
• kubelet 调用已配置的 API 服务器上的 SubjectAccessReview API，以确定每个申请是否失去鉴权

kubelet 应用与 apiserver 雷同的申请属性办法对 API 申请执行鉴权。

申请的动词依据传入申请的 HTTP 动词确定：

资源和子资源是依据传入申请的门路确定的：

名字空间和 API 组属性始终是空字符串，资源名称始终是 kubelet 的 Node API 对象的名称。

在此模式下运行时，请确保传递给 apiserver 的由 --kubelet-client-certificate 和 --kubelet-client-key 标记标识的用户具备以下属性的鉴权：

• 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

TLS 启动疏导

在一个 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）须要与 Kubernetes 主控组件通信，尤其是 kube-apiserver。为了确保通信自身是私密的、不被烦扰，并且确保集群的每个组件都在与另一个 可信的组件通信，咱们强烈建议应用节点上的客户端 TLS 证书。

启动疏导这些组件的失常过程，尤其是须要证书来与 kube-apiserver 平安通信的 工作节点，可能会是一个具备挑战性的过程，因为这一过程通常不受 Kubernetes 管制，须要不少额定工作。这也使得初始化或者扩缩一个集群的操作变得具备挑战性。

为了简化这一过程，从 1.4 版本开始，Kubernetes 引入了一个证书申请和签名 API 以便简化此过程。

内置工具

Minikube

[minikube]() 是在工作站上本地运行单节点 Kubernetes 集群的工具，用于开发和测试。

仪表盘

[Dashboard]()，基于 Web 的 Kubernetes 用户界面，容许通过用户界面将容器化的应用程序部署到 Kubernetes 集群，对它们进行故障排查，并治理集群及其资源自身。

Helm

[Kubernetes Helm]() 是一个用于治理预配置 Kubernetes 资源包的工具，也就是 Kubernetes 图表。

Helm 性能 / 作用：

• 查找和应用打包为 Kubernetes 图表的风行软件
• 将本人的应用程序共享为 Kubernetes 图表
• 为 Kubernetes 应用程序创立可重现的构建
• 智能治理 Kubernetes 清单文件
• 治理 Helm 包的公布

Kompose

Kompose 帮忙应用 Docker Compose 的用户迁徙到 Kubernetes 的工具。

Kompose 性能 / 作用：

• 将 Docker Compose 文件翻译成 Kubernetes 对象
• 从本地 Docker 开发转到通过 Kubernetes 管理应用程序
• 转换 Docker Compose v1 或 v2 版本的 yaml 文件或分布式应用程序包