参看链接：https://zhuanlan.zhihu.com/p/162928436
https://zhuanlan.zhihu.com/p/425527511

Kubernetes，简称 k8s（k，8 个字符，s——明白了？）或者 “kube”

k8s多master节点

当集群中只有一个master节点时，如果其出现了故障，会导致Kubernetes(k8s)的控制平面完全失效。如要保证Kubernetes(k8s)集群的高可靠性，可以设置多个master，当其中部分master出现故障时，其他master还可以管理整个集群。
正常情况下，可以使用一个负载均衡器(Loadbalance)将请求转发给集群中的master，如果有一天其中的一个master出现故障后，负载均衡器仅需要将请求发送另外的master即可。

K8s 服务的负载均衡是如何实现的？

Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 Controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址。这样就产生了一个问题：如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？K8s 给出的解决方案是 Service。 Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 Label 来挑选。Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，K8s 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。

云原生

为了让应用程序（项目，服务软件）都运行在云上的解决方案，这样的方案叫做云原生。
云原生有如下特点：
容器化，所有服务都必须部署在容器中
微服务，Web 服务架构式服务架构
CI/CD
DevOps

K8s 架构

概括来说 K8s 架构就是一个 Master 对应一群 Node 节点

Master 节点结构

apiserver 即 K8s 网关，所有的指令请求都必须要经过 apiserver；
scheduler 调度器，使用调度算法，把请求资源调度到某一个 Node 节点；
controller 控制器，维护 K8s 资源对象；
etcd 存储资源对象；

Node节点

kubelet 在每一个 Node 节点都存在一份，在 Node 节点上的资源操作指令由 kubelet 来执行；
kube-proxy 代理服务，处理服务间负载均衡；
Pod 是 k8s 管理的基本单元（最小单元），Pod 内部是容器，k8s 不直接管理容器，而是管理 Pod；
Docker 运行容器的基础环境，容器引擎；
Fluentd 日志收集服务；

K8s 核心组件K8s

组件K8s 是用来管理容器，但是不直接操作容器，最小操作单元是 Pod （间接管理容器）。
一个 Master 有一群 Node 节点与之对应
Master 节点不存储容器，只负责调度、网管、控制器、资源对象存储
容器的存储在 Node 节点，容器是存储在 Pod 内部的）
Pod 内部可以有一个容器，或者多个容器
Kubelet 负责本地 Pod 的维护
Kube-proxy 负责负载均衡，在多个 Pod 之间来做负载均衡

Pod 是什么？

Pod 也是一个容器，这个容器中装的是 Docker 创建的容器，Pod 用来封装容器的一个容器，Pod 是一个虚拟化分组；
Pod 相当于独立主机，可以封装一个或者多个容器。
Pod 有自己的 IP 地址、主机名，相当于一台独立沙箱环境。

Pod 到底用来干什么？

通常情况下，在服务部署时候，使用 Pod 来管理一组相关的服务。一个 Pod 中要么部署一个服务，要么部署一组有关系的服务。一组相关的服务是指：在链式调用的调用连路上的服务。Web 服务集群如何实现？实现服务集群：只需要复制多方 Pod 的副本即可，这也是 K8s 管理的先进之处，K8s 如果继续扩容，只需要控制 Pod 的数量即可，缩容道理类似。Pod 底层网络，数据存储是如何进行的？Pod 内部容器创建之前，必须先创建 Pause 容器；
服务容器之间访问 localhost ，相当于访问本地服务一样，性能非常高

Helm

很多人都使用过 Ubuntu 下的 ap-get 或者 CentOS 下的 yum, 这两者都是Linux 系统下的包管理工具。采用 apt-get/yum ,应用开发者可以管理应用包之间的依赖关系，发布应用；用户则可以以简单的方式查找、安装、升级、卸载应用程序。这里可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis (https://deis.com/) 开发的一个用于 kubernetes 的包管理器。每个包称为一个 Chart，一个 Chart 是一个目录（一般情况下会将目录进行打包压缩，形成 name-version.tgz 格式的单一文件，方便传输和存储）。对于应用发布者而言，可以通过 Helm 打包应用，管理应用依赖关系，管理应用版本并发布应用到软件仓库。对于使用者而言，使用 Helm 后不用需要了解 Kubernetes 的 Yaml 语法并编写应用部署文件，可以通过 Helm 下载并在 kubernetes 上安装需要的应用。除此以外，Helm 还提供了 kubernetes 上的软件部署，删除，升级，回滚应用的强大功能

Helm 组件及相关术语

Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库。

Tiller

Tiller 是 Helm 的服务端，部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求，并根据 Chart 生成 Kubernetes 的部署文件（ Helm 称为 Release ），然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。

Chart

Helm 的软件包，采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一组定义 Kubernetes 资源相关的 YAML 文件。

Repoistory

Helm 的软件仓库，Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。

Release

使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release。

Chart Install

过程：
Helm从指定的目录或者tgz文件中解析出Chart结构信息
Helm将指定的Chart结构和Values信息通过gRPC传递给Tiller
Tiller根据Chart和Values生成一个Release
Tiller将Release发送给Kubernetes用于生成Release