作者：石义峰

安装部署神器-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​​ 文件或分布式应用程序包