了解整体思路
1、了解，k8s 生态的基础组件
2、服务发布的/回滚过程
3、业务请求过程
4、服务数据监控过程
5、故障探查和治愈
6、POD生命周期和服务发现
基本架构
1.1 Master 主键说明
**K8s-server-api**：
它是k8s的中央处理器，所有的业务和服务请求处理都要经过它====》集群的统一入口，各组件协调者，以HTTP API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给ETCD存储。
**K8s-controll-manager**:
它的作用就是怎么控制和后管理面的pod, 处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的
（ replication controller、endpoints controller、namespace controller）。不同的 controller 管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。
**kube-scheduler**：
它是k8s集群的协调器，它来决定Pod 这个对象放在那个地方那个node; Scheduler 在调度时会充分考虑 Cluster 的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。
**Kublete**:
他是k8s-Scheduler的小弟，干活的；当 Scheduler 确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该节点的 kubelet，kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。
**kube-proxy**：
它是配合service用的，转发service请求的。
service 在逻辑上代表了后端的多个 Pod，外界通过 service 访问 Pod。service 接收到的请求是如何转发到 Pod 的呢？
这就是 kube-proxy 要完成的工作。每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。
**ETCD**:
K8s 集群的数据存储库，储存K8S服务的节点信息业务信息等；
Terway: [暂时不用关系，阿里自研]
K8s 集群的基础网络，使用的是Terway，是阿里云开源的基于专有网络VPC的容器网络接口CNI（Container Network Interface）插件，支持基于Kubernetes标准的网络策略来定义容器间的访问策略。您可以通过使用Terway网络插件实现Kubernetes集群内部的网络互通
**Prometheus+Grafana**：
K8s 集群的监控Prometheus主要负责数据抓取（service+agent模式），Grafana则是图形的展示。
-
服务的部署/回滚：
这里简单说明一下自动部署大致步骤哈：K8s 自动部署的步骤大概如下：
- Jenkins触发部署某个服务=====》产生部署请求指令，并传递部署配置和版本镜像（这部分需要脚本配合），请求传达到master的k8s-server-API.
- k8s-server-API将部署需求转发给k8s-contrall-manage,由它结合预先写好的k8s.yml相关配置文件，来定制这个服务怎么部署（如用什么方式部署，需要部署几个副本pod，走的什么网络flannel，对外映射的什么端口）
- 当k8s-contrall-manage这个架构是将这些部署标准定制好了，邮件给k8s-scheduler这个运维主管说你安排哈看把这些服务部署到后面那些服务器上吧，然后k8s-scheduler就来调度，把这个服务放到那些节点（如1，3，5的node节点），并把最终方案一起发给k8s-server-API这个leader过目. 然后Kublete 在工作安排上发现leader给他安排的这个新任务，于是就开始部署安排pod(小弟)干活了
- Pod干活的小弟将自己干活的状态在反馈给Kublete说自己干的怎样（好/不好）
- Kublete 则如实将手下pod干活的情况反馈给k8s-server-API这个leader
- k8s-server-API这个leader则将这最后这次发布任务的节点信息，干的怎么样全部存储到ETCD中,并将最终执行结果反馈给jenkins(大boss)。
2.1 服务的回滚：
服务的回滚和发布流程是一样的，类似于一次发布，他们的区别在于执行脚本的调用命令不同：
Kubectl { apply(发布) /Rolling (升级)/ rollout(回滚) }
以回滚为例：
我们通过kubectl rollout history 可以发现httpd可回滚的版本有三个，这个时候我们回滚到revison1
- 业务请求流程 ！！！这个很重要，请大家详细了解
业务请求如请求K8S后端的httpd服务： ** 1. 将请求信息发送给k8s-server-API ** 2. k8s-server-API 去后端ETCD 抓取请求元素，（server、端口等） ** 3. k8s-server-API将抓到的信息反馈给业务服务 ** 4. 业务服务取请求server,然后kube-proxy转发server的tcp/udp请求协议到后面真实的pod ** 5. Pod 将最终的情求内容反馈给我的业务服务
- 服务的监控
Prometheus+Grafana 集群监控
K8s 集群的监控Prometheus主要负责数据抓取（service+agent模式），Grafana则是图形的展示。
- Health Check
Liveness 探测让用户可以自定义判断容器是否健康的条件。如果探测失败，Kubernetes 就会重启容器。
启动进程首先创建文件 /tmp/healthy，30 秒后删除，在我们的设定中，如果 /tmp/healthy 文件存在，则认为容器处于正常状态，反正则发生故障。 livenessProbe 部分定义如何执行 Liveness 探测： 1. 探测的方法是：通过 cat 命令检查 /tmp/healthy 文件是否存在。如果命令执行成功，返回值为零，Kubernetes 则认为本次 Liveness 探测成功；如果命令返回值非零，本次 Liveness 探测失败。 2. initialDelaySeconds: 10 指定容器启动 10 之后开始执行 Liveness 探测，我们一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花 30 秒，那么 initialDelaySeconds 的值就应该大于 30。 3. periodSeconds: 5 指定每 5 秒执行一次 Liveness 探测。Kubernetes 如果连续执行 3 次 Liveness 探测均失败，则会杀掉并重启容器。
下面创建 Pod liveness：
35秒之后，日志会显示 /tmp/healthy 已经不存在，Liveness 探测失败。再过几十秒，几次探测都失败后，容器会被重启。
除了 Liveness 探测，Kubernetes Health Check 机制还包括 Readiness 探测
用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。
Readiness 探测的配置语法与 Liveness 探测完全一样，下面是个例子：
5.1 Liveness 探测和 Readiness 探测区别： Liveness 探测和 Readiness 探测是两种 Health Check 机制，如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。 两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。 Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。
