🌟谭先生✨

Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足扩展要求、故障转移、部署模式等，提供以下服务

• 服务发现和负载均衡
• 存储编排
• 自动部署和回滚
• 自动完成装箱计算
• 自我修复
• 密钥与配置管理

组件

• 控制面组件（管理面）

  1. kube-apiserver 服务器，提供API
  2. kube- controler-manager
     • node controller：负责节点出现故障时进行通知和响应
     • replication controller：负责为系统中每个副本控制器对象维护正确数量的pod
     • endpoint controller：填充endpoints对象（即加入service与pod）
     • service account& token contolers：为新的命名空间传家默认账户和API访问令牌
  3. kube-scheduler 监视新创建 未指定node的pods，选择node让pod运行
  4. etcd 保存集群数据

• Node组件（数据面）

  1. kubelet 每个node上的代理。保证containers都运行在pod中。接收一组提供给kubelet的PodSpecs，确保PodSpecs描述的容器处于运行状态且健康。不会管理不是kubernets创建的容器
  2. kube-proxy 每个节点上运行的网络代理，维护节点上的网络规则

• Container Runtime 负责运行容器的软件（docker containers CRI-O）

• 插件（Addons）

  插件使用 Kubernetes 资源（DaemonSet、 Deployment等）实现集群功能。如DNS，Dashboard

架构

节点

• 可用节点上都包括kubelet，Container Runtime及kube-proxy

• 向API服务器添加节点的方式主要有两种：

  1. 节点上的kubelet向控制面执行自注册

     当 kubelet 标志 --register-node 为 true（默认）时，它会尝试向 API 服务注册自己

  2. 手动注册
     执行操作后，控制面会检查新的node对象是否合法。 如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。 否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。

控制面节点通信

• 节点到控制面
  Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。 apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求。应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。
  当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。kubernetes 服务（位于所有名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发 请求到 apiserver 的 HTTPS 末端。
  控制面组件也通过安全端口与集群的 apiserver 通信。
  集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的， 能够在不可信的网络或公网上运行。

• 控制面到节点

  1. API服务器到kubelet

     从apiserver到kubelet的连接用于：

     • 获取pod日志
     • 挂接（通过kubectl）到运行中的pod
     • 通过kubelet的端口转发功能
       这些连接终止于 kubelet 的 HTTPS 末端。 默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击， 在非受信网络或公开网络上运行也是 不安全的。

  2. apiserver到节点，pod和服务

     从 apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密，这些连接 目前还不能安全地 在非受信网络或公共网络上运行。