Kubernetes精华总结

一、概念
1.Kubernetes 是一个开源的容器编排引擎、可弹性运行分布式系统的框架。
Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。K8s 这个缩写是因为 K 和 s 之间有 8 个字符的关系。
Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上，结合了社区中最优秀的想法和实践。
2.Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。
由于 Kubernetes 是在容器级别运行，而非在硬件级别，它提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡，允许用户集成他们的日志记录、监控和警报方案。
但是，Kubernetes 不是单体式（monolithic）系统，那些默认解决方案都是可选、可插拔的。Kubernetes 为构建开发人员平台提供了基础，但是在重要的地方保留了用户选择权，能有更高的灵活性。

二、Kubernetes组件
（1）控制平面组件（Control Plane Components）
kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager
（2）Node 组件
kubelet、kube-proxy、容器运行时（Container Runtime）
（3）插件（Addons）
DNS、Web 界面（仪表盘）、容器资源监控、集群层面日志、网络插件

三、Kubernetes架构

四、kubelet启动过程
当工作节点启动时，kubelet 执行以下操作：
1、寻找自己的 kubeconfig 文件
2、检索 API 服务器的 URL 和凭据，通常是来自 kubeconfig 文件中的 TLS 密钥和已签名证书
3、尝试使用这些凭据来与 API 服务器通信
具体过程如下：
（1）kubelet 启动
（2）kubelet 看到自己没有对应的 kubeconfig 文件
（3）kubelet 搜索并发现 bootstrap-kubeconfig 文件
（4）kubelet 读取该启动引导文件，从中获得 API 服务器的 URL 和用途有限的一个“令牌（Token）”
（5）kubelet 建立与 API 服务器的连接，使用上述令牌执行身份认证
（6）kubelet 现在拥有受限制的凭据来创建和取回证书签名请求（CSR）
（7）kubelet 为自己创建一个 CSR，并将其 signerName 设置为 kubernetes.io/kube-apiserver-client-kubelet
（8）CSR 被以如下两种方式之一批复：
- 如果配置了，kube-controller-manager 会自动批复该 CSR
- 如果配置了，一个外部进程，或者是人，使用 Kubernetes API 或者使用 kubectl 来批复该 CSR
（9）kubelet 所需要的证书被创建
（10）证书被发放给 kubelet
（11）kubelet 取回该证书
（12）kubelet 创建一个合适的 kubeconfig，其中包含密钥和已签名的证书
（13）kubelet 开始正常操作
（14）可选地，如果配置了，kubelet 在证书接近于过期时自动请求更新证书
（15）更新的证书被批复并发放；取决于配置，这一过程可能是自动的或者手动完成

五、kubelet初始启动引导认证
为了让启动引导的 kubelet 能够连接到 kube-apiserver 并请求证书，必须首先在服务器上认证自身身份。
尽管所有身份认证策略都可以用来对 kubelet 的初始启动凭据来执行认证，但出于容易准备的因素，建议使用
如下两个身份认证组件：
（1）启动引导令牌（Bootstrap Token）
使用启动引导令牌，必须在 kube-apiserver 上使用下面的标志启用：
–enable-bootstrap-token-auth=true
启动引导令牌被定义成一个特定类型的 Secret（bootstrap.kubernetes.io/token），并存在于kube-system 名字空间中。
过期的令牌可以通过启用控制器管理器中的 tokencleaner 控制器来删除：–controllers=*,tokencleaner
（2）令牌认证文件
向 kube-apiserver 添加 --token-auth-file=FILENAME 标志以启用令牌文件

六、使用 kubectl 来生成启动引导 kubeconfig 文件

kubectl config --kubeconfig=/etc/kubernetes/bootstrap-kubeconfig set-cluster bootstrap --server='https://172.16.0.90:6443' --certificate-authority=/etc/kubernetes/pki/ca.pem
kubectl config --kubeconfig=/etc/kubernetes/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/etc/kubernetes/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/etc/kubernetes/bootstrap-kubeconfig use-context bootstrap

七、批复CSR的方式
（1）控制器管理器内置的批复控制器来自动批复。
（2）由外部批复控制器来自动执行批复。
（3）使用 kubectl 来手动批准证书请求。

手动批复：
#来列举所有的 CSR

kubectl get csr

#描述某个 CSR 的细节

kubectl descsribe csr <name>

#批准某 CSR

kubectl certificate approve <name>

#拒绝某 CSR

kubectl certificate deny <name>

八、节点与控制面之间通信
（1）节点 —> 控制面
Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。所有从节点（或运行于其上的 Pod）发出的 API 调用都终止于 API 服务器。
其它控制面组件都没有被设计为可暴露远程服务。API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求。
- kubelet通过客户端凭据连接到API 服务器
- Pod使用服务账号安全地连接到API 服务器
- 控制面组件也通过安全端口与集群的 API 服务器通信
（2）控制面 —> 节点
API 服务器到节点有两种主要的通信路径：
- API服务器到集群中每个节点上运行的 kubelet 进程,默认情况下，API 服务器不检查 kubelet 的服务证书,这使得此类连接容易受到中间人攻击，在非受信网络或公开网络上运行也是不安全的。
- API服务器通过它的代理功能连接到任何节点、Pod 或者服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密.这些连接目前还不能安全地在非受信网络或公共网络上运行。

九、cgroup
在 Linux 上，cgroup 约束分配给进程的资源。
kubelet 和底层容器运行时都需要对接 cgroup 来强制执行为 Pod 和容器管理资源，这包括为容器化工作负载配置 CPU/内存请求和限制。
Linux 中有两个 cgroup 版本：cgroup v1 和 cgroup v2。cgroup v2 是新一代的 cgroup API。
使用 cgroup v2 的推荐方法是使用一个默认启用 cgroup v2 的 Linux 发行版。

#识别 Linux 节点上的 cgroup 版本

stat -fc %T /sys/fs/cgroup/

对于 cgroup v2，输出为 cgroup2fs。
对于 cgroup v1，输出为 tmpfs。