图解 K8s 核心概念和术语

我第一次接触容器编排调度工具是 Docker 自家的 Docker Swarm，主要解决当时公司内部业务项目部署繁琐的问题，我记得当时项目实现容器化以后，花在项目部署运维的时间大大减小了，当时以为这玩意还挺新鲜的，原来自动化运维能够这么玩。后面因为工做缘由，好久没碰过容器方面的知识了。最近在公司的数据同步项目中，须要使用到分布式调度数据同步执行单元，目前使用的方案是将数据同步执行单元打包成镜像，使用 K8s 进行调度，正好趁这个机会了解一下 K8s，下面我就用图解的形式将我所理解的 K8s 分享给你们。

K8s 三大核心功能

K8s 是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。经过 K8s 可以进行应用的自动化部署和扩缩容。

K8s 是比容器更上一层的架构，它能够支持多种容器技术，好比咱们熟悉的 Docker，K8s 定位是一个容器调度工具，它主要具有如下三大核心能力：

一、自动调度

k8s 将用户部署提交的容器放到 k8s 集群的任意一个节点中，k8s 能够根据容器所须要的资源大小，以及节点的负载状况来决定容器放在哪一个节点上面。

二、自动修复

当 k8s 的健康检查机制发现某个节点出现问题，它会自动将该节点上的资源转移到其它节点上面完成自动恢复。

三、横向自动扩缩容

在 k8s 1.1+ 版本中，有一个功能叫 “ Horizontal Pod Autoscaler”，简称 “HPA”，意思是 Pod自动扩容，它能够预先定义 Pod 的负载指标，当达到预期设定的负载指标后，就会根据指标自动触发自动动态扩容/缩容行为。

1）横向自动扩容

2）横向自动缩容

节点

从上面的图能够看出来，k8s 集群的节点有两个角色，分别为 Master 节点和 Node 节点，整个 K8s 集群Master 和 Node 节点关系以下图所示：

一、Master 节点

Master 节点也称为控制节点，每一个 k8s 集群都有一个 Master 节点负责整个集群的管理控制，咱们上面介绍的 k8s 三大能力都是通过 Master 节点发起的，Master 节点包含了如下几个组件：

• API Server：提供了 HTTP Rest 接口的服务进程，全部资源对象的增、删、改、查等操做的惟一入口；
• Controller Manager：k8s 集群全部资源对象的自动化控制中心；
• Scheduler：k8s 集群全部资源对象自动化调度控制中心；
• ETCD：k8s 集群注册服务发现中心，能够保存 k8s 集群中全部资源对象的数据。

二、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/