87 lines
6.4 KiB
Markdown
87 lines
6.4 KiB
Markdown
---
|
||
title: Kubernetes基础术语
|
||
date: 2021-04-01 17:03:05
|
||
tags: [DevOps, Kubernetes]
|
||
categories:
|
||
- [DevOps, Kubernetes]
|
||
keywords: Kubernetes,k8s,术语,pod
|
||
---
|
||
要完成一个服务在Kubernetes上的部署，必须先了解以下关于Kubernetes中的知识点，这些知识点决定着一个应用在Kubernetes上的部署行为。
|
||
<!-- more -->
|
||
|
||
## 术语集
|
||
|
||
* **Master**，Kubernetes中的集群控制节点，所有的集群控制命令都是在Master节点上运行。
|
||
* **Node**，Kubernetes集群中的实体机器或者虚拟机，是Kubernetes中的工作负载节点。
|
||
* **Namespace**，对一组资源和对象的抽象集合，通常用来在Kubernetes内部划分不同的项目组。默认创建的资源都是隶属于`default`命名空间的。
|
||
* **Pod**，Kubernetes中最基础的服务单元，其中包含至少一个容器。
|
||
* **Label**，标签是一个键值对，每个资源可以有任意数量的标签
|
||
* **Replication Controller**，即**RC**，用于控制Pod部署的副本控制器，现在已经建议使用**Deployment**替代。
|
||
* **Replica Set**，最新一代的Pod副本控制器。与RC相比提供了更新的选择器支持。
|
||
* **Deployment**，用于控制Kubernetes集群中Pod的编排，内部使用**Replica Set**实现。
|
||
* **StatefulSet**，运行一个或者多个能够被跟踪应用状态的Pod，适用于Pod需要把数据做永久存储的需求。StatefulSet中的Pod可以与PersistentVolume对应，来使得Pod的状态得以保存。
|
||
* **DaemonSet**，用于在Node上提供支持设施的Pod，集群会自动在符合条件的每一个Node上运行一个Pod。
|
||
* **Service**，定义Kubernetes上一个服务的入口，对来自客户端的访问进行请求转发和负载均衡控制。Service都拥有一个唯一的名称，拥有一个虚拟IP，并且会被映射在一组Pod上。
|
||
* **Endpoint**，Kubernates中用来记录一个Service所对应的所有Pod的访问地址，即所有Pod的IP地址和端口。只有Service中配置了Selector，才会自动创建Endpoint。
|
||
|
||
## 网络IP类型
|
||
|
||
在Kubernetes中，Pod、Node和Cluster这三层元素就会引入以下三个IP系统。
|
||
|
||
* **Node IP**，这是Kubernetes集群中每个Node的物理网卡地址。
|
||
* **Pod IP**，每个Pod都在Kubernetes集群中拥有一个独一无二的IP地址，可以用来支持Pod在集群中的相互访问。Pod IP是一个虚拟的二层网络。
|
||
* **Cluster IP**，Kubernetes集群中的一个Service的IP地址。Cluster IP是一个完全虚拟的IP，无法被Ping到，只能用于支持Kubernetes内部服务之间的相互访问。
|
||
|
||
## Label
|
||
|
||
Label允许在Kubernetes资源上附加对于系统或者用户有意义的标示性属性，方便对Kubernetes资源进行分组管理。 这些属性对不会直接对Kubernetes核心组件产生语义，不过可能间接地被Kubernetes核心组件处理产生效果。
|
||
|
||
Label key由两部分组成：可选的prefix和name，它们之间通过`/`连接。下面对它们的语法规则进行对比：
|
||
|
||
| | Prefix | Name |
|
||
| :------- | :-------- | :--------------- |
|
||
| 存在性 | 可选 | 必需 |
|
||
| 最大长度 | 253 | 63 |
|
||
| 可用字符 | DNS子域名 | 字母与数字 |
|
||
| 分割符 | `.` | `-`, `_`, `.` |
|
||
| 限制 | 以`/`结尾 | 以字母开头和结尾 |
|
||
|
||
Label可以让用户将他们自己的有组织目的的结构以一种松耦合的方式应用到系统的对象上，且不需要客户端存放这些对应关系（mappings）。
|
||
|
||
服务部署和批处理管道通常是多维的实体（例如多个分区或者部署，多个发布轨道，多层，每层多微服务）。管理通常需要跨越式的切割操作，这会打破有严格层级展示关系的封装，特别对那些是由基础设施而非用户决定的很死板的层级关系。
|
||
|
||
在习惯上以下Label都是比较常用的。
|
||
|
||
* "release" : "stable"， "release" : "canary"
|
||
* "environment" : "dev"，"environment" : "qa"，"environment" : "production"
|
||
* "tier" : "frontend"，"tier" : "backend"，"tier" : "cache"
|
||
* "partition" : "customerA"， "partition" : "customerB"
|
||
* "track" : "daily"， "track" : "weekly"
|
||
|
||
### 选择器
|
||
|
||
与Name和UID不同，标签不需要有唯一性。一般来说，我们期望许多对象具有相同的标签。通过标签选择器（Labels Selectors），客户端/用户能方便辨识出一组对象。标签选择器是Kubernetes中核心的组成部分。
|
||
|
||
Kubernetes API目前支持两种选择器：equality-based（基于相等）和set-based（基于集合）的。标签选择器可以由逗号分隔的多个requirements 组成。在多重需求的情况下，必须满足所有要求，因此逗号分隔符作为AND逻辑运算符。
|
||
|
||
* 一个为空的标签选择器（即有0个必须条件的选择器）会选择集合中的每一个对象。
|
||
* 一个null型标签选择器（仅对于可选的选择器字段才可能）不会返回任何对象。
|
||
|
||
> 注意：两个控制器的标签选择器不能在命名空间中重叠。
|
||
|
||
基于相等的或者不相等的条件允许用标签的keys和values进行过滤。匹配的对象必须满足所有指定的标签约束，尽管他们可能也有额外的标签。有三种运算符是允许的，“=”，“==”和“!=”。
|
||
|
||
* `=`：被选择的资源必须带label key，并且value必须相等。
|
||
* `==`：被选择的资源必须带label key，并且value必须相等。
|
||
* `!=`：被选择的资源不带label key，或者带label key，但是value不相等。
|
||
|
||
基于集合的标签条件允许用一组value来过滤key。支持三种操作符：`in`，`notin`和 `exists`(仅针对于key符号) 。
|
||
|
||
* `in`：被选择的资源必须带label key，并且value在集合范围内。
|
||
* `notin`：被选择的资源不带label key，或者带label key，但是value不在集合范围内。
|
||
* `exists`：被选择的资源必须带label key，不检查value。Label key前加`!`表示不存在，则被选择的资源必须不带label key。
|
||
|
||
Deployment和Service两种对象的Label选择器是使用map定义在json或者yaml文件中的，它们只支持Equality-based的条件。Job，Deployment，Replica Set，和Daemon Set，支持Set-based条件。注意，Deployment中的`matchLabels`属性只支持Equality-based条件，但`matchExpressions`属性支持Set-based条件。
|
||
|
||
> 不管是在`matchLabels`还是在`matchExpressions`中的选择器条件，都必须被同时满足才能够完成匹配。
|