共计 2827 个字符，预计需要花费 8 分钟才能阅读完成。
我第一次接触容器编排调度工具是 Docker 自家的 Docker Swarm，次要解决过后公司外部业务我的项目部署繁琐的问题，我记得过后我的项目实现容器化之后，花在我的项目部署运维的工夫大大减少了，过后感觉这玩意还挺陈腐的，原来自动化运维能够这么玩。前面因为工作起因，很久没碰过容器方面的常识了。最近在公司的数据同步我的项目中，须要应用到散布式调度数据同步执行单元，目前应用的计划是将数据同步执行单元打包成镜像，应用 K8s 进行调度，正好趁这个机会理解一下 K8s，上面我就用图解的模式将我所了解的 K8s 分享给大家。
K8s 三大外围性能
K8s 是一个轻便的和可扩大的开源平台，用于治理容器化利用和服务。通过 K8s 可能进行利用的自动化部署和扩缩容。
K8s 是比容器更上一层的架构，它能够反对多种容器技术，比方咱们相熟的 Docker，K8s 定位是一个容器调度工具，它次要具备以下三大外围能力：
1、主动调度
k8s 将用户部署提交的容器放到 k8s 集群的任意一个节点中，k8s 能够依据容器所须要的资源大小，以及节点的负载状况来决定容器放在哪个节点下面。
2、主动修复
当 k8s 的健康检查机制发现某个节点呈现问题，它会主动将该节点上的资源转移到其它节点下面实现主动复原。
3、横向主动扩缩容
在 k8s 1.1+ 版本中，有一个性能叫“Horizontal Pod Autoscaler”，简称“HPA”，意思是 Pod 主动扩容，它能够事后定义 Pod 的负载指标，当达到预期设定的负载指标后，就会依据指标主动触发主动动静扩容 / 缩容行为。
1）横向主动扩容
2）横向主动缩容
节点
从下面的图能够看进去，k8s 集群的节点有两个角色，别离为 Master 节点和 Node 节点，整个 K8s 集群 Master 和 Node 节点关系如下图所示：
1、Master 节点
Master 节点也称为管制节点，每个 k8s 集群都有一个 Master 节点负责整个集群的管理控制，咱们下面介绍的 k8s 三大能力都是通过 Master 节点发动的，Master 节点蕴含了以下几个组件：
- API Server：提供了 HTTP Rest 接口的服务过程，所有资源对象的增、删、改、查等操作的惟一入口；
- Controller Manager：k8s 集群所有资源对象的自动化控制中心；
- Scheduler：k8s 集群所有资源对象自动化调度控制中心；
- ETCD：k8s 集群注册服务发现核心，能够保留 k8s 集群中所有资源对象的数据。
2、Node
Node 节点的作用是承接 Master 调配的工作负载，它次要有以下几个要害组件：
- kubelet：负责 Pod 对应容器的创立、启停等操作，与 Master 节点严密合作；
- kube-porxy：实现 k8s 集群通信与负载平衡的组件。
从图上可看出，在 Node 节点下面，还须要一个容器运行环境，如果应用 Docker 技术栈，则还须要在 Node 节点下面装置 Docker Engine，专门负责该节点容器管理工作。
Pod
Pod 是 k8s 最重要而且是最根本的一个资源对象，它的构造如下：
从以上 Pod 的结构图能够看出，它其实是容器的一个下层包装构造，这也就是为什么 K8s 能够反对多种容器类型的起因，基于这方面，我了解 k8s 的定位就是一个编排与调度工具，而容器只是它调度的一个资源对象而已。
Pod 可蕴含多个容器在外面，每个 Pod 至多会有一个 Pause 容器，其它用户定义的容器都共享该 Pause 容器，Pause 容器的次要作用是用于定义 Pod 的 ip 和 volume。
Pod 在 k8s 集群中的地位如下图所示：
Label
Label 在 k8s 中是一个十分外围的概念，咱们能够将 Label 指定到对应的资源对象中，例如 Node、Pod、Replica Set、Service 等，一个资源能够绑定任意个 Label，k8s 通过 Label 可实现多维度的资源分组治理，后续可通过 Label Selector 查问和筛选领有某些 Label 的资源对象，例如创立一个 Pod，给定一个 Label，workerid=123，后续可通过 workerid=123 删除领有该标签的 Pod 资源。
Replica Set
Replica Set 目标是为了定义一个冀望的场景，比方定义某种 Pod 的正本数量在任意时刻都处于 Peplica Set 冀望的值，假如 Replica Set 定义 Pod 的正本数目为：replicas=2，当该 Replica Set 提交给 Master 后，Master 会定期巡检该 Pod 在集群中的数目，如果发现该 Pod 挂掉了一个，Master 就会尝试根据 Replica Set 设置的 Pod 模版创立 Pod，以维持 Pod 的数量与 Replica Set 预期的 Pod 数量雷同。
通过 Replica Set，k8s 集群实现了用户利用的高可用性，而且大大减少了运维工作量。因而生产环境个别用 Deployment 或者 Replica Set 去管制 Pod 的生命周期和期望值，而不是间接独自创立 Pod。
相似 Replica Set 的还有 Deployment，它的外部实现也是通过 Replica Set 实现的，能够说 Deployment 是 Replica Set 的升级版，它们之间的 yaml 配置文件格式大部分都雷同。
Service
Service 是 k8s 可能实现微服务集群的一个十分重要的概念，顾名思义，k8s 的 Service 就是咱们平时所提及的微服务架构中的“微服务”，本文下面提及的 Pod、Replica Set 等都是为 Service 服务的资源，如下图示意 Service、Pod、Replica Set 的关系：
从上图可看出，Service 定义了一个服务拜访的入口，客户端通过这个入口即可拜访服务背地的利用集群实例，而 Service 则是通过 Label Selector 实现关联与对接的，Replica Set 保障服务集群资源始终处于期望值。
以上只是一个微服务，通常来说一个利用我的项目会由多个不同业务能力而又彼此独立的微服务组成，多个微服务间组成了一个弱小而又高可用的应用服务集群。
Namespace
Namespace 顾名思义是命名空间的意思，在 k8s 中次要用于实现资源隔离的目标，用户可依据不同我的项目创立不同的 Namespace，通过 k8s 将资源分配到不同 Namespace 中，即可实现不同我的项目的资源隔离：
作者简介
作者张乘辉，善于消息中间件技能，负责公司百万 TPS 级别 Kafka 集群的保护，作者保护的公号「后端进阶」不定期分享 Kafka、RocketMQ 系列不讲概念间接真刀真枪的实战总结以及细节上的源码剖析；同时作者也是阿里开源分布式事务框架 Seata Contributor，因而也会分享对于 Seata 的相干常识；当然公号也会分享 WEB 相干常识比方 Spring 全家桶等。内容不肯定八面玲珑，但肯定让你感触到作者对于技术的谋求是认真的！
公众号：后端进阶
技术博客：https://objcoding.com/
GitHub：https://github.com/objcoding/