K8S中专业名词

目录

• 1、pod
  • 网络
  • 存储
• 2、labels
• 3、namespace
• 4、Replication Controller / Replica Set（副本控制器）
  • Replication Controller 的三部分
  • 作用
  • ReplicaSet 和 Replication Controller 的比较
• 5、Node
  • node 状态
• 6、Services
  • Service 在 K8s 中有以下四种类型
    • 1、ClusterIp
    • 2、NodePort
    • 3、 LoadBalancer
    • 4、ExternalName
• 7、Volumes
• 8、Deployment
• 9、Secret
• 10、StatefulSet
• 11、Ingress
  • Ingress 和 Ingress-Controller
• 12、ConfigMap
• Reference

1、pod

Pod 是 k8s 系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在 k8s 上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展 Pod 对象功能的

一个 Pod 封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。

网络

每个 Pod 被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。当Pod中的容器与Pod 外部通信时，他们必须协调如何使用共享网络资源（如端口）

存储

Pod可以指定一组共享存储 volumes。Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。volumes 还用于Pod中的数据持久化，以防其中一个容器需要重新启动而丢失数据。

kubelet 创建 Pod 时，会先创建一个基础容器 pause，Pod 里面所有的容器共享一个网络名称空间和文件系统。挂载卷的工作就是由基础容器pause来完成的。

一个 pod 包含一组容器，但一个 pod 不会跨越多个工作节点

• pod相当于逻辑主机，每个pod都有自己的 ip 地址
• pod内的容器共享相同的 ip 和端口空间
• 默认情况下，每个容器的文件系统与其他容器完全隔离
• 可以理解为：容器组，同时pod相当于逻辑主机，进入pod后仿佛进入一个 linux 主机，命令都可用（linux系统下），该“主机”内又有很多容器，进入后又仿佛是又进了一个 linux 主机。

2、labels

Labels：对 k8s 中各种资源进行分类、分组，

标签其实就一对 key/value ，被关联到对象上

一个标签可以对应多个资源，一个资源也可以有多个标签，它们是多对多的关系，但是key值必须是唯一的

一个资源拥有多个标签，可以实现不同维度的管理。

可以使用标签选择器来指定能使用哪些标签。

3、namespace

namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个 namespace 的（默认是default），而 node, persistentVolumes 等则不属于任何 namespace。

Namespace 常用来隔离不同的用户，比如 Kubernetes 自带的服务一般运行在 kube-system namespace 中。

4、Replication Controller / Replica Set（副本控制器）

Replication Controller 会持续监控正在运行的pod列表， 并保证相应 ” 类型” 的 pod 的数目与期望相符（多了删除，少了新增）。所谓的类型就是通过标签选择器监控模板中指定标签的 pod 的数量。

在新版本的 k8s 中的副本控制器为 Replica Set 完全替代了 Replication Controller。在 kubectl 命令中 Replication Controller 可简写为 rc ，Replica Set 为 rs。

Replication Controller 的三部分

​ • label selector ( 标签选择器）， 用于确定 Replication Controller 作用域中有哪些 pod

​ • replica count (副本个数）， 指定应运行的pod 数量

​ • pod template (pod模板）， 用于创建新的pod 副本

作用

1、人为删除、增加pod后，副本控制器就会根据模板中定义的数量通过创建/删除来维持应有的数量，或者pod 异常丢失停止都会根据模板创建新的pod

2、集群节点发生故障时， 它将为故障节 点 上运行的所有 pod (即受Replication Controller 控制的节点上的那些 pod) 创建替代副本。

3、根据使用需求它能轻松实现 pod的水平伸缩,手动和自动都可以。

ReplicaSet 和 Replication Controller 的比较

ReplicaSet 的行为与 ReplicationController 完全相同， 但pod 选择器的表达能力更强。 虽然 ReplicationController 的标签选择器只允许包含某个标签的匹配 pod, 但 ReplicaSet 的选择器还允许匹配缺少某个标签的 pod, 或包含特定标签名的 pod, 不管其值如何。

可以理解为 ReplicaSet 可以同时匹配多个标签，而 ReplicationController 则不行，一次只能匹配一个

5、Node

Node 是 Kubernetes 中的工作节点，最开始被称为 minion。一个 Node 可以是VM或物理机。每个Node（节点）具有运行 pod 的一些必要服务，并由 Master 组件进行管理，Node 节点上的服务包括 Docker、kubelet 和 kube-proxy。

Pod 总是运行在 Node 之上。Node 是 Kubernetes 中的一个工作机器，通常是一个虚拟机或者物理机。每个 Node 被 Master 管理。一个节点能有多个 pod,同时Kubernetes master 在集群之上自动调度 pod。Master 的自动调度会考虑到每个 Node 上的可用资源。

每个Kubernetes Node 至少运行：

• Kubelet,一个负责Kubernetes Master和Node之间通讯的进程；它管理着运行在机器上Pods和Containers
• 容器运行时(比如Docker,rkt),负责从registry拉取容器镜像，取出容器，运行应用。

node 状态

• Addresses
  • HostName：可以通过 kubelet 中 --hostname-override 参数覆盖。
  • ExternalIP：可以被集群外部路由访问到的 IP 地址。
  • InternalIP：只能在集群内进行路由的节点的 IP 地址。
• Condition：conditions字段描述所有Running节点的状态。
  • OutOfDisk：True：如果节点上没有足够的可用空间来添加新的pod；否则为：False
  • Ready：True：如果节点是健康的并准备好接收pod；False：如果节点不健康并且不接受pod；Unknown：如果节点控制器在过去40秒内没有收到node的状态报告。
  • MemoryPressure：True：如果节点存储器上内存过低; 否则为：False。
  • DiskPressure：True：如果磁盘容量存在压力 - 也就是说磁盘容量低；否则为：False。
• Capacity：描述节点上可用的资源：CPU、内存和可以调度到节点上的最大pod数。
• Info：关于节点的一些基础信息，如内核版本、Kubernetes 版本（kubelet和kube-proxy版本）、Docker版本（如果有使用）、OS名称等。信息由Kubelet从节点收集。

6、Services

Kubernetes Service定义了这样一种抽象： Service 是一种可以访问 Pod 逻辑分组的策略， Service 通常是通过 Label Selector 访问 Pod 组。

Services 主要是提供负载均衡和服务自动发现

当 Pod 宕机后重新生成时，其 IP 等状态信息可能会变动，Service会根据 Pod 的 Label 对这些状态信息进行监控和变更，保证上游服务不受 Pod 的变动而影响

Service 在 K8s 中有以下四种类型

1、ClusterIp

默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP

2、NodePort

在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过: NodePort 来访问该服务。

3、 LoadBalancer

在 NodePort 的基础上，借助 Cloud Provider 创建一个外部负载均衡器，并将请求转发到 NodePort

4、ExternalName

把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持

7、Volumes

在容器中的文件在磁盘上是临时存放的，当容器关闭时这些临时文件也会被一并清除。这给容器中运行的特殊应用程序带来一些问题。

首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建。

其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。

Kubernetes 抽象出 Volumes 对象来解决这两个问题。（持久化）

Volume是 k8s 抽象出来的对象，用于解决Pod中的容器运行时，文件存放的问题以及多容器数据共享的问题。Kubernetes 的卷具有明确的生命周期——与包裹它

Pod 相同。卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，当一个 Pod 不再存在时，卷也将不再存在。

Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。 特定的卷类型可以决定

这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。使用卷时, Pod 声明中需要提供卷的类型 (.spec.volumes 字段)和卷挂载的位置 、

(.spec.containers.volumeMounts 字段)。

Kubernete 支持如下类型的volume

• emptyDir

• hostPath

• gcePersistentDisk

• awsElasticBlockStore

• nfs

• iscsi

• glusterfs

• rbd

• gitRepo

• secret

• persistentVolumeClaim

8、Deployment

Deployment是 k8s 中用来管理发布的控制器，在开发的过程中使用非常频繁

这种控制器并不直接管理pod，而是通过管理 replicaset 来间接管理pod

主要功能

• 支持 replicaset 的所有功能
• 支持发布的停止、继续
• 支持版本的滚动更新和版本回退

9、Secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用

Secret有三种类型：

• Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
• Opaque：base64编码格式的 Secret，用来存储密码、密钥等；
• kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息

10、StatefulSet

StatefulSet 是为了解决有状态服务的问题（对应Deployments和 ReplicaSets 是为无状态服务而设计），其应用场景包括

• 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于PVC来实现
• 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有Cluster IP的 Service）来实现
• 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
• 有序收缩，有序删除（即从N-1到0）

从上面的应用场景可以发现，StatefulSet 由以下几个部分组成：

• 用于定义网络标志（DNS domain）的 Headless Service
• 用于创建 PersistentVolumes 的 volumeClaimTemplates
• 定义具体应用的 StatefulSet

11、Ingress

k8s 对外暴露服务（service）主要有三种方式：ClusterIP、NodePort 与 LoadBalance，这几种方式都是在 service 的维度提供的，service的作用体现在两个方

面，对集群内部，它不断跟踪pod的变化，更新 endpoint 中对应 pod 的对象，提供了 ip 不断变化的 pod 的服务发现机制，对集群外部，他类似负载均衡器，可

以在集群内外部对 pod 进行访问。但是，单独用 service 暴露服务的方式，在实际生产环境中不太合适：

• ClusterIP 的方式只能在集群内部访问。

• NodePort 方式的话，测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort 的端口管理是灾难。

• LoadBalance 方式受限于云平台，且通常在云平台部署 ELB 还需要额外的费用。

Ingress可以很好的解决这些问题，Ingress可以简单理解为 service 的service，通过独立的 ingress 对象来制定请求转发的规则，把请求路由到一个或多个 service

中。这样就把服务与请求规则解耦了，可以从业务维度统一考虑业务的暴露，而不用为每个 service 单独考虑。

如现在集群有 api、文件存储、前端3个 service，可以通过一个 Ingress 对象来实现图中的请求转发：

Ingress 和 Ingress-Controller

• Ingress 对象

  指的是 k8s 中的一个 api 对象，一般用 yaml 配置。作用是定义请求如何转发到service的规则，可以理解为配置模板。

• Ingress-controller

  具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。

12、ConfigMap

ConfigMap 是一种 API 对象，用来将非加密数据保存到键值对中。可以用作环境变量、命令行参数或者存储卷中的配置文件。

ConfigMap 可以将环境变量配置信息和容器镜像解耦，便于应用配置的修改。如果需要存储加密信息时可以使用 Secret 对象。

Reference

https://blog.csdn.net/qq_33712668/article/details/107781653

https://www.cnblogs.com/fanggege/p/12124982.html

https://blog.csdn.net/weixin_41927873/article/details/118971880

https://baijiahao.baidu.com/s?id=1681303264708121640&wfr=spider&for=pc

https://blog.csdn.net/woshizhangliang999/article/details/109172005

https://blog.51cto.com/u_15079076/4140208

https://segmentfault.com/a/1190000019908991