零基础入门云原生-k8s工具介绍～

安装部署神器-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 动词确定：

HTTP 动词	请求动词
POST	create
GET, HEAD	get
PUT	update
PATCH	patch
DELETE	delete

资源和子资源是根据传入请求的路径确定的：

Kubelet API	资源	子资源
/stats/*	nodes	stats
/metrics/*	nodes	metrics
/logs/*	nodes	log
/spec/*	nodes	spec
其它所有	nodes	proxy

名字空间和 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 文件或分布式应用程序包