内容简介:Kubernetes 有各类资源对象来描述整个集群的运行状态。这些对象都需要通过调用 kubernetes api 来进行创建、修改、删除,可以通过 kubectl 命令工具,也可以直接调用 k8s api,或者使用对象语言的客户端库(例如:每个 kubernetes 对象都会包含两个关键字段:下面会宽泛的介绍一些 Kubernetes 的核心概念,便于初步的理解它们特征及工作模式。
概述
Kubernetes 有各类资源对象来描述整个集群的运行状态。这些对象都需要通过调用 kubernetes api 来进行创建、修改、删除,可以通过 kubectl 命令工具,也可以直接调用 k8s api,或者使用对象语言的客户端库(例如: golang , pythion )。
每个 kubernetes 对象都会包含两个关键字段: Object Spec 和 Object Status 。spec 描述了对象所期望达到的状态,status 描述了该对象的实际状态。
下面会宽泛的介绍一些 Kubernetes 的核心概念,便于初步的理解它们特征及工作模式。
核心概念
Pod
Pod 是 Kubernetes 最小的调度单元,可以由一个或者多个容器组成。
Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
Pod 的特征:
- 可以包含多个容器,它们之间共享 IPC、Network 、UTC、PID namespace,可以直接通过 localhost 进行通信。
- 支持 CPU / Mem 超卖
- 支持一个或者多个 init containers
- Pod 可以共享 Volume,使得多个容器之间可以共享数据。
- Pod 生命周期短暂,且不会自愈。需要结合 Deployment、DaemonSet、StatefulSet 等控制器来达到容错。
- 优雅退出:Pod 删除的时候先给其进程发送 SIGTERM,等待一段时间(grace period)后才强制停止依然还在运行的进程。
- 支持(反)亲和性
- 支持指定调度器
- 支持优先级和抢占性调度(v1.8 及以上)
- 支持配置 serviceAccount
kubernetes v1.8+ 且 docker >= 1.13.1 才支持容器之间共享 PID
namespace,还需要配置 kubelet —docker-disable-shared-pid=false
Labels & Selectors
Labels 是 Key-Value 对,k8s 用于标识其所有资源;而 Selectors 是标签选择器,用于选择特定 labels 的资源。
Selectors 目前支持两种选择器:Equality-based(基于平等) 和 Set-based(基于集合)。
1. Equality-based
基于相等的或者不想等的条件用标签的 keys 和 values 进行过滤。支持三种运算符:“=”,“==” 和 “!=”。还可以使用逗号操作符,连接多个运算符。
2. Set-based
Set-based 的选择器允许用一组 value 来过滤 key。
支持三种操作符:in,notin 和 exists(仅针对于 key 符号)。
例如:
env in (dev, test, staging, prod) env notin (staging, prod) partition !partition
Set-based 可以和 Equality-based 条件结合使用。
Deployment
Kubernetes 有几个版本的副本控制器,比如 Replication Controller、Replica Set(RC 升级版)和 Deployments。
Deployment 是逻辑层的一种抽象,为 Pod 和 ReplicaSet 提供了一种声明式定义,来代替以前的 Replication Controller 更方便的管理应用。
在 Kubernetes 的实际使用中,RS 也属于底层概念,由 Deployment 来管理,因此用户一般都是与 Deployment 打交道。
Deployment 有几种 典型的应用场景
,比如:
- 定义 Deployment 来创建 Pod 和 ReplicaSet
- 滚动升级和回滚应用,比如蓝绿发布,金丝雀发布等等
- 扩容和缩容
- 暂停和继续 Deployment
RC、RS、Deployment 等对象都是为了解决无状态服务而设计,下面还会针对有状态服务,介绍对应的对象。
Service
Kubernetes Pod 有自己的生命周期,可以随时被创建和销毁,而一旦销毁就永远结束了。而每个 Pods 都有自己的 IP,而 Pod 的生命周期也意味着 这些 IP 地址不总是稳定可靠的。所以需要有针对容器的服务发现与负载均衡机制,来访问这个 Pod 逻辑分组。
service 是对一组提供相同功能的 Pods 集合的抽象,为这组Pods提供统一的访问入口。借助 Service 可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。
在 Kubernetes 集群中,每个 Node 都会部署一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP (虚 IP)。
Service 有四种类型:
NodeIP:NodePort
Ingress
通常情况下,Service 和 Pod 仅支持在集群内部进行服务访问。而 Ingress 可以提供外部服务可访问的 URL / 负载均衡器等。
Ingress 对象只是配置了一些规则,若要实现集群外部的访问,还需要部署一个 Ingress Controller
,它会从 kube-apiserver 监听 Ingress 和 Service 的变更,并根据 Ingress 的规则配置负载均衡来提供访问入口。
Job
Job 负责批量处理短暂的一次性任务,仅执行一次,并保证处理的一个或者多个Pod成功结束。
具体的可以查看: 深入K8S Job(一):介绍
PV & PVC
PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷:PV 提供网络存储资源,而 PVC 请求存储资源。这样,设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建 PVC 来将 Pod 跟数据卷关联起来。PV 和 PVC 可以将 pod 和数据卷解耦,pod 不需要知道确切的文件系统或者支持它的持久化引擎。
PV 也是集群的资源(等同于cpu / mem),但不同于 pod volume,它是独立于 Pod 的生命周期。
支持类别划分,比如不同的服务质量级别(SSD / SATA),不同的备份策略等。 支持动态 PV(StorageClass)。 支持卷的扩容及快照(v1.8+ 特性)。 支持 Local Volume,允许将 Node 本地的磁盘、分区或者目录作为持久化存储使用。但是需要注意该模式不支持动态创建,使用前需要预先创建好 PV。
PV 是存储资源,而 PVC 是对 PV 的请求。PVC 和 Pod 类似,Pod 消费 Node 资源,而 PVC 消费 PV 资源;Pod 能够请求 CPU 和内存资源,而 PVC 请求特定大小和访问模式的数据卷。
StatefulSet
StatefulSet 用于支持部署有状态服务,而有状态的服务很关键的就是持久化存储,这就依赖上面介绍的 PV & PVC 了。
StatefulSet 的应用场景包括:
- 稳定的持久化存储,即不需要关心 Pod 的重新调度,服务访问的还是相同的持久化数据。
- 稳定的网络标志,即 Pod 重新调度后其 PodName 和 HostName 不变。
- 有序部署,即 Pod 的创建是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行创建,基于 init containers 来实现。
- 有序收缩(删除)。
参考案例: Running ZooKeeper, A Distributed System Coordinator - Kubernetes
- 推荐在 k8s v1.9 + 的版本使用 statefulSet。
- 为了保证数据安全,删除 StatefulSet 是不会删除 PV 的,需要考虑清理策略。
- StatefulSet 需要提前创建一个 Headless Service 来定义 DNS domain。
Other
还有很多别的资源对象,这里暂不一一介绍了,因为涉及的篇幅会比较长。 对于上面或者未提及的资源对象需要多了解一下的,建议查阅 官方文档 。
比如:
- Namespace
- Node
- Secret:集群的秘药管理
- ConfigMap:集群的配置管理
- Event:记录k8s集群运行所遇到的各种大事件
- HPA(HorizontalPodAutoscaler):自动扩缩容
- DaemonSet:保证每个Node上都运行一个容器副本,常用于部署一些集群服务的agent(日志/监控…), 也可以基于Pod进行亲和部署。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。