Kubernetes 系列第一篇: Kubernetes 介绍和名词解释

标签：通信   两种   ice   负载   ret   ali   快速   dashboard   vol   

1.1. 什么是 Kubernetes

kubernetes 简称 k8s(因为k和s之间有8个字母), 是 Google 旗下的开源容器编排平台, k8s 的诞生深受 Google 内部容器编排系统 Borg 的影响, k8s 实现了如下功能

自动装箱

建构于容器之上, 基于资源依赖及其他约束条件自动完成容器部署

自我修复

支持容器故障后自动重启、节点故障后重新调度容器, 以及节点健康状态检查失败后关闭容器并重新创建等自我修复机制

水平扩展

支持通过命令或 UI 手动水平扩展, 以及基于 CPU 等资源负载率的自动水平扩展机制

服务发现和负载均衡

k8s 通过 CoreDNS 附件为系统内置了服务发现功能, 为每个 Service 配置 DNS 名称, 并允许集群内的客户端直接使用此名称发出访问请求, Service 通过 iptables 或 ipvs 内建负载均衡机制

自动发布和回滚

k8s 支持灰度更新应用程序或其配置信息, 在更新过程中 k8s 将会监控更新过程中应用程序的健康状态, 以确保 k8s 不会在同一时刻杀掉所有实例, 而此过程中一旦有故障发生, 将会立即自动执行回滚操作

秘钥和配置管理

k8s 的 ConfigMap 实现了配置数据与 Docker 镜像解耦, 需要时仅对配置做出变更而无须重新构建 Docker 镜像, 这为应用开发和部署带来极大的灵活性
对于应用所依赖的一些敏感数据, 如用户名和密码、令牌、密钥等信息, k8s 提供了 Secret 对象为其解耦, 既便利了应用的快速开发和交付, 又提供了一定程度上的安全保障

存储编排

k8s 支持 Pod 对象按需自动挂载不同类型的存储系统, 包括节点本地存储、公有云服务商云存储, 以及网络存储系统(NFS, Ceph, GlusterFS 等)

2. 节点和组件

一般情况下一个 k8s 集群由多个工作节点(worker node)和一个集群控制节点(master)以及一个集群状态存储系统(etcd)组成

2.1. Master 节点

Master 是集群的网关和中枢, 负责集群的管理工作, 诸如为用户和客户端暴露API, 跟踪其他服务器的健康状况、以最优方式调度工作负载, 以及编排其他组件之间的通信等任务, 它是用户或客户端与集群之间的核心联络点
单个 Master 节点即可完成其所有的功能, 但出于冗余及负载均衡等目的, 生产环境中通常需要部署多个 master 节点
Master 节点主要由 apiserver、controller-manager 和 scheduler 三个组件以及一个用于存储集群状态的 etcd 存储服务组成

2.2. Node 节点

Node 是 k8s 集群的工作节点(Worker), 并接收来自 Master 的指令并根据指令完成响应操作, 如创建或销毁 Pod 对象、调整网络规则等操作
Master 节点主要由 kubelet、kube-proxy 和容器引擎(docker 是最为常见的容器引擎) 组成

2.3. Master 组件

集群网关(API Server)

k8s 集群的网关接口, 负责解析客户端的请求

集群状态存储(etcd)

存放 k8s 持久化数据, 提供监听(watch)机制, 用于监听和推送变更
在 k8s 集群系统中, etcd 中的键值发生变化时会通知到 API Server, 并由其通过 watchAPI 向客户端输出。基于 watch 机制 k8s 集群的各组件实现了高效协同

调度器(Scheduler)

在用户发出创建 Pod 请求时, Scheduler 根据各 Node 资源情况, 以及容器所需要的资源做出调度决定这个 Pod 将在那个 Node 上创建

控制器管理器(ControllerManager)

检查控制器是否处于健康状态

2.4. Node 组件

kubelet

负责和 Master 节点进行通信, 接收 Master 调度过来的任务, 检查节点上的 Pod 是否处于健康状态

容器引擎

负责运行容器, 目前最为流行的容器引擎为 Docker, k8s 目前支持 Rtk 和 Docker 两种容器引擎

kube-proxy

根据 Service 资源对象生 iptables 或 ipvs 规则, 从而将用户请求转发到指定的 Pod 中

3. k8s 术语

3.1. Pod

k8s 并不直接调度容器, 而是使用一个抽象的资源对象来封装一个或者多个容器, 这个抽象对象被称为 Pod, 它也是 k8s 最小的调度单元
同一 Pod 中的容器共享网络名称空间和存储资源, 这些容器可经由本地回环节口lo直接通信, 但彼此之间又在 Mount、User 以及 PID 等名称空间上保持隔离
尽管 Pod 中可以包含多个容器, 但是作为最小调度单元, 它应该尽可能地保持小, 即通常只应该包含一个主容器, 以及其他必要的辅助型容器(sidecar)

3.2. 资源标签

标签(Label)是将资源进行分类的标识符, 资源标签其实就是一个键值型(key/values)数据
标签是在指定对象上辨识性的属性, 这些属性仅对用户存在特定的意义, 对 k8s 集群来说意义并不大
标签可以在对象创建时附加在其上, 并能够在创建后的任意时间进行添加和修改。一个对象可以拥有多个标签, 一个标签也可以附加在多个对象上

3.3. 标签选择器

标签选择器(Selector)全称为Label Selector它是一种根据 Label 来过滤符合条件的资源对象的机制
例如, 将附有标签role: backend的所有 Pod 对象挑选出来归为一组就是标签选择器的一种应用
用户通常使用标签对资源对象进行分类, 而后使用标签选择器挑选出它们, 对他们进行批量操作

3.4. Pod 控制器

通常情况下用户不会直接去部署和管理 Pod 对象, 而是要借助于另一类抽象控制器(Controller)对其进行管理
k8s 内置了大量的控制器用于管理 Pod 对象, 常见的控制器如下

ReplicationController   K8s 早期使用的控制器
ReplicaSet              副本集, 一般不直接使用此管理器而是使用 Deployment 管理器
Deployment              管理无状态应用
StatefulSet             管理有状态应用
Job                     运行作业
Cronjob                 运行周期性作业
DaemonSet               在每个 Node 上都运行一个副本, 而不是在随机节点上运行

3.5. 服务资源(service)

Service 是建立在一组 Pod 对象之上的资源抽象, 它通过标签选择器(Label Selector)选定一组 Pod 对象, 并为这组 Pod 对象定义一个统一的固定访问入口(通常是一个IP 地址), 若 k8s 集群存在 DNS 附件, 它就会在 Service 创建时为其自动配置一个DNS 名称以便客户端进行服务发现
到达 Service IP 的请求将被负载均衡至其后的各个 Pod 对象之上, 因此 Service 从本质上来讲是一个四层代理服务

3.6. 存储卷(volume)

存储卷(Volume)是独立于容器文件系统之外的存储空间, 常用于扩展容器的存储空间并为它提供持久存储能力
k8s 集群上的存储卷大体可分为临时卷、本地卷和网络卷
临时卷和本地卷都位于 Node 本地, 一旦 Pod 被调度至其他 Node, 此种类型的存储卷将无法被访问到, 因此临时卷和本地卷通常用于数据缓存, 持久化的数据则需要放置于持久卷(persistent volume)之上

3.7. Name 和 Namespace

Name 是 k8s 集群中资源对象的标识符, 它们的作用域通常是名称空间(Namespace)在同一个名称空间中, 同一类型资源、对象的名称必须具有唯一性
名称空间通常用于实现用户或项目的资源隔离, 从而形成逻辑分组, 默认的名称空间为 default

3.8. Annotation(注解)

Annotation(注解)是一种附加在对象之上的键值类型的数据, 它拥比 Label 有更大的数据容量
Annotation 常用于将各种非标识型数据附加到对象上, 但它不能用于标识和选择对象, 通常也不会被 k8s 直接使用, 其主要目的是方便用户的阅读及查找等

3.9. Ingress

k8s 将 Pod 对象和外部网络环境进行了隔离, Pod 和 Service 等对象间的通信都使用其内部专用地址进行, 如若需要开放某些 Pod 对象提供给外部用户访问, 则需要为其请求流量打开一个通往 k8s 集群内部的通道, 除了 service 之外, Ingress 也是这类通道的实现方式之一

3.10. Pause 容器

在每个 Pod 中都运行着一个特殊的容器, 即 Pause 容器, 而其他容器则为用户定义的容器, 这些用户定义的容器共享 Pause 容器的网络栈和 Volume 挂载卷, 因此它们之间的通信和数据交换更为高效; 在程序设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个 Pod 中

4. 核心附件

k8s 通过一组被称为附件的组件提供更加丰富的功能, 附件通常由第三方提供, 为 k8s 提供特定的功能, 且通常以 Pod 的方式运行在 k8s 集群之上

4.1. k8s 常见附件

• CoreDNS 为 k8s 集群提供 DNS 服务
• Kubernetes Dashboard 为 k8s 集群提供 Web UI 界面
• Heapster k8s 集群监控, 目前已逐步被 Prometheus 代替
• Ingress Controller k8s 网络的另一种实现方式, 为 k8s 提供区别于 service 的网络模型

5. k8s 网络

k8s 网络中主要有 4 种网络通信类型

5.1. 网络通信类型

同一 Pod 内的容器之间互相通信

同一 Pod 之间的容器共享网络名称空间, 通过 lo 接口进行通信

Pod 与 Pod 之间的通信

Pod 网络由 k8s 网络插件实现, 执行插件都遵循 CNI 协议, 主流的网络插件有 flannel、calico、canel 等, 这些网络插件会为所有的 Pod 对象配置至少一个特点的地址, 即 Pod IP, Pod IP 实际存在于网卡之上

Pod 和 Service 之间的通信

Service 由 k8s 集群指定, 默认使用的 10.96.0.0/12 网段, 一般情况下每一组 Pod 都至少有一个 Service, 这一组 Pod 之间通过 Service 进行网络通信
Pod 通过标签选择器和 Service 创建关联关系, Service 地址不存在于任何网络接口之上, 它是由 kube-proxy 借助 iptables 或者 ipvs 创建的 NET 规则

集群外部流量和 Service 之间的通信

k8s 对外暴露一个访问地址, 当用户访问时先到达这个唯一访问接口, 在通过 iptables 或者 ipvs 规则转发到指定 Service, Service 在将其转发的特定的 Pod 之上

Kubernetes 系列第一篇: Kubernetes 介绍和名词解释

标签：通信   两种   ice   负载   ret   ali   快速   dashboard   vol   

原文地址：https://blog.51cto.com/hongchen99/2438924