深入理解Kubernetes核心概念与机制-优快云博客

本文链接：https://blog.youkuaiyun.com/niceHack/article/details/129179007

提示：总结k8s核心概念

参考：kubernetes权威指南（纪念版）

一、k8s入门

1.是什么？

首先k8s是基于容器技术的分布式架构方案，其次是完备的分布式系统支撑平台。
Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。
同时，Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。
因此，Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

2.为什么要使用它？

首先是可以精简团队，负责业务的同事可以专心业务逻辑，简化运维。
其次使用k8s便是在全面拥抱微服务架构，k8s从服务注册、发现、负载、健康、升级回滚、扩容缩容等提供了一整套基于容器的服务治理方案。
基于其强大的横向扩展能力，可以轻松享受云服务带来的便利。

3.和docker的联系和区别

容器引擎使用docker（已支持其他容器）
k8s中pod是由一个或多个容器构成
k8s为容器编排技术，可以理解为基于容器的操作系统。
想要理解k8s就必须先理解容器，理解镜像等概念。

4.简单环境准备和特别注意(stop firewalld)

(1) 关闭CentOS自带的防火墙服务：
$ systemctl disable firewalld
$ systemctl stop firewalld
(2) 安装etcd和Kubernetes软件（会自动安装Docker软件）：
$ yum install - y etcd kubernetes
(3) 按顺序启动所有的服务：
$ systemctl start etcd
$ systemctl start docker
$ systemctl start kube-apiserver
$ systemctl start kube-controller-manager
$ systemctl start kube-scheduler
$ systemctl start kubelet
$ systemctl start kube-proxy

以上步骤可以对k8s的几个进程有所掌握。

二、核心概念

1.Master

kubernetes-Api-server 管理和业务的唯一rest入口
kubernetes-controller manager 资源自动化控制中心
kubernetes-scheduler 负责资源（Pod）调度

2.Node

kubelet 与master协作，操作容器的生命周期,默认kubelet会向Master注册自己
kube-proxy 主要实现service的通信和负载均衡
docker engine 容器创建管理的基础

3.Pod

	POD存在的原因和意义：

1.引入业务无关井且不易死亡的 Pause 容器作为 Pod 的根容器，以它的状态代表整个容器组的状态，解决容器组状态问题。
2.容器组共享pause容器的ip和挂载的volume，pod内容器通信和文件共享问题。

	Pod：容器组，kubernetes管理的基础单位。

Pod 其实有两种类型：普通的 Pod 及静态 Pod (Static Pod），后者比较特殊，它并不存放在Kubernetes 的 etcd 存储里，而是存放在某个具体的 Node 上的一个具体文件中，并且只在此 Node上启动运行。

Kubernetes为每个Pod都分配了唯一的Ip地址，称之为Pod IP，一个Pod里的多个容器共享Pod Ip地址。
Pod 的IP加上这里的容器端口（containerPort），就组成了一个新的概念一－Endpoint，它代表着此 Pod 里的一个服务进程的对外通信地址。

Kubernetes 要求底层网络支持集群内任意两个 Pod 之间的 TCP/IP 直接通信，这通常采用虚拟二层网络技术来实现。

Event是一个事件的记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。

CPU 配额被定义为 100～300m，即占用 0.1 ～0.3 个 CPU。
Memory 配额也是一个绝对值，它的单位是内存字节数。64MiB

4.Label

	Label Selector 在Kubernetes中的重要使用场景有以下几处：

controller-manager进程通过RC中的标签选择器控制pod副本数量
kube-proxy进程通过service的标签选择器控制自动建立转发路由表，实现负载均衡
kube-scheduler进程，通过在node上定义的特殊标签，实现pod的定向调度特性

5.Replication Controller

6.Deployment

Deployment在内部使用了ReplicaSet来实现目的，无论从Deployment的作用与目的、它的Yaml定义，还是从它的具体命令行操作来看，我们都可以把它看作RC的一次升级，两者的相似度超过90%。

7.Horizontal Pod Autoscaler

	HorizontalPodAutoscaler（HPA）

1.CPUUtilizationPercentage，当pod中容器cpu平均利用率达到request的80%后会自动扩容。
2.应用程序自定义的度量指标，比如服务在每秒内的相应的请求数(TPS或QPS)。

8.StatefulSet

StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。
假设StatefulSet的名字叫kafka,，那么第l个Pod叫kafka-0，第2个叫 kafka-1 ，以此类推。
StatefulSet控制的 Pod 副本的启停顺序是受控的，操作第 n 个 Pod 时，前 n-1 个 Pod 己经是运行且准备好的状态。
StatefulSet里的 Pod 采用稳定的持久化存储卷，通过 PV/PVC 来实现，删除 Pod 时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。

9.Service

Pod 的 Endpoint 地址会随着 Pod 的销毁和重新创建而发生改变，因为新 Pod 的IP 地址与之前旧 Pod 的不同。而 Service 一旦被创建，Kubernetes就会自动为它分配一个可用的Cluster IP，而且在 Service 的整个生命周期内，它的 Cluster IP 不会发生改变。

Kubernetes 通过 Add-On 增值包的方式引入了 DNS 系统，把服务名作为 DNS 域名，这样一来，程序就可以直接使用服务名来建立通信连接了。

	核心概念：NodeIp - PodIp - ClusterIp

NodeIp: ifconfig主机物理地址
PodIp: kubectl get pods -A -owide | grep xxx 或者 kubectl -n xxx-ns get endpoints | grep xxx
Docker Engine 根据 dockerO 网桥的IP地址段进行分配的，通常是一个虚拟的二层网络,Kubernetes 要求位于不同 Node 上的Pod 能够彼此直接通信，就是通过 Pod Ip 所在的虚拟二层网络进行通信的，而真实的 TCP/IP 流量则是通过 Node Ip 所在的物理网卡流出的。
ClusterIp: kubectl get svc -A | grep xxx 或者 kubectl -n xxx-ns get svc xxx -o yaml
Cluster Ip无法被 Ping ，因为没有一个“实体网络对象”来响应。
Cluster Ip只能结合 Service Port 组成一个具体的通信端口，单独的 ClusterIp不具备TCP/IP通信的基础。
Service 的 Cluster IP 属于 Kubernetes 集群内部的地址，无法在集群外部直接使用这个地址，需要：kubectl -n xxx-ns edit svc xxx修改spec.type的值从ClusterIP修改为NodePort。
NodePort 的实现方式是在 Kubernetes 集群里的每个Node上为需要外部访问的 Service 开启一个对应的 TCP 监听端口。
但是目前需要在公有云上才可以实现负载均衡。

10.Volume(存储卷)

	volumes： 定义volume
	volumeMounts： 将定义的volume挂载到容器某个目录

kubernetes的volume是定义在pod上，被pod内的多个容器挂载在不同的目录，其生命周期和pod一致，与容器无关。
Kubernetes 的 Volume 还扩展出了一种非常有实用价值的功能，即容器配置文件集中化定义与管理，这是通过ConfigMap这个新的资源对象来实现的。

11.Persistent Volume

	Persistent Volume（PV）
	Persistent Volume Claim（PVC）
	
	PV 可以理解成 Kubernetes 集群中 的某个网络存储中对应的一块存储，它与 Volume 很类似，
	但有以下区别。
	1. PV 只能是网络存储，不属于任何 Node ，但可以在每个 Node 上访 问 。
	2. PV 并不是定义在 Pod 上的 ，而是独立于 Pod 之外定义。
	比较重要的是 PY 的 accessModes 属性，目前有以下类型 。
	ReadWriteOnce ： 读写权限、并且只能被单个Node挂载 。
	ReadOnlyMany ： 只读权限、允许被多个Node挂载 。
	ReadWriteMany ： 读写权限 、允许被多个Node挂载 。

12.Namespace

Namespace 在很多情况下用于实现多租户的资源隔离，Namespace通过将集群内部的资源对象“分配”到不同的Namespace中。

13.Annotation

与Label类似，也使用key/value键值对的形式进行定义。不同的是Label具有严格的命名规则，它定义的是Kubernetes对象的元数据(metadata)，用于labelSelector。而annotation则是用于任意定义的附加信息，用于外部工具的查找。

14.ConfigMap

	ConfigMap供容器使用的典型用法如下:
	(1)生成为容器内的环境变量。
	(2)设置容器启动命令的启动参数（需设置为环境变量）。
	(3)以Volume的形式挂载为容器内部的文件或目录。

	使用 ConfigMap 的限制条件如下。
	1. ConfigMap 必须在 Pod 之前创建 。
	2. ConfigMap 受 Namespace 限制，只有处于相同 Namespaces 中的 Pod 可以引用它 。
	3. ConfigMap 中的配额管理还未能实现 。
	4. kubelet 只支持可以被 API Server 管理的 Pod 使用 ConfigMap 。 kubelet 在本 Node 上通
	过－－manifest-url或--config 自动创建的静态 Pod 将无法引用 ConfigMap 。
	5. 在 Pod 对 ConfigMap 进行挂载（ volumeMount ）操作时，容器内部只能挂载为“目录”，无法挂载为“文件”

二、核心概念

1.kubectl工具

kubectl命令行的语法如下:
$ kubectl [command) [TYPE) [NAME) [flags)
其中，command、TYPE、NAME、flags的含义如下。
(1)command：子命令，用于操作Kubernetes集群资源对象的命令，例如create、delete、describe、get、apply等。
(2)TYPE：资源对象的类型，区分大小写，能以单数形式、复数形式或者简写形式表示。
例如以下3种TYPE是等价的。
$ kubectl get pod pod1
$ kubectl get pods pod1
$ kubectl get po pod1
(3)NAME：资源对象的名称，区分大小写。如果不指定名称，则系统将返回属于TYPE的全部对象的列表，例如$kubectl get pods将返回所有Pod的列表。
(4)flags:kubectl子命令的可选参数，例如使用"-s"指定apiserver的URL地址而不用默认值。

常用的输出格式示例如下:
(1)显示Pod的更多信息：
$ kubectl get pod -o wide
(2)以yaml格式显示Pod的详细信息：
$ kubectl get pod -o yaml
(3)以自定义列名显示Pod的信息：
$ kubectl get pod -o=custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
(4)基于文件的自定义列名输出：
$ kubectl get pods -o=custom-columns-file=template.txt

2.Pod

在这里插入图片描述

Pod的重启策略与控制方式息息相关，当前可用于管理Pod的控制器包括ReplicationController 、 Job 、 DaemonSet 及直接通过 kubelet 管理（静态Pod）。每种控制器对 Pod的重启策略要求如下。
1. RC 和 Daemon Set：必须设置为 Always ，需要保证该容器持续运行。
2. Job: OnFailure 或 Never，确保容器执行完成后不再重启。
3. kubelet ：在 Pod 失效时自动重启它，不论将 RestartPolicy设置为什么值，也不会对Pod进行健康检查。

Pod的健康检查：

LivenessProbe，判断容器是否存活（running），如果判断该容器不健康，则会kill该容器，根据重启策略处理。
ExecAction：在容器内部执行一个命令，如果该命令的返回码为0，则表明容器健康。
TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。
HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器状态健康。
initialDelaySeconds和timeoutSeconds两个参数单位为s，表示容器启动后检测的等待时间和超时时间。
ReadinessProbe，判断容器是否启动完成（ready），可以接收外部请求。EndpointController将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。

亲和性调度功能包括节点亲和性（NodeAffinity）和Pod亲和性（PodAffinity）两个维度的设置。
(具体的配置忽略)

Init Container （初始化容器）
在很多应用场景中，应用在启动之前都需要进行如下初始化操作。
1. 等待其他关联组件正确运行（例如数据库或某个后台服务〉。
2. 基于环境变量或配置模板生成配置文件。
3. 从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中。
4. 下载相关依赖包，或者对系统进行一些预配置操作。
通过initContainers配置进行声明。

滚动升级：
Deployment是如何完成Pod更新的呢？
我们可以使用kubectl describe deployments/nginx-deployment命令仔细观察Deployment的更
新过程。初始创建Deployment时，系统创建了一个ReplicaSet(nginx-deployment-4087004473),
井按用户的需求创建了3个Pod副本。当更新Deployment时，系统创建了一个新的ReplicaSet
(nginx-deployment-3599678771），并将其副本数扩展到l，然后将旧的ReplicaSet缩减为2。之
后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。最后，新的ReplicaSet
运行了3个新版本Pod副本，旧的ReplicaSet副本数则缩减为0。

多重更新（ Rollover）的情况下，下一次更新时候会将上一次创建的pod全部清理掉。
更新镜像：
kubectl -n maipu-bdwan edit deployments.apps xxx
查看之前的升级版本：
[root@aaa xxx]# kubectl -n maipu-bdwan rollout history deployment/xxx
deployment.apps/xxx
REVISION CHANGE-CAUSE
1

通过 kubectl rollout pause 命令暂停 Deployment 的更新操作：
$ kubectl rollout pause deployment/nginx-deployment
恢复这个 Deployment 的部署操作：
$ kubectl rollout resume deploy nginx-deployment
查看 Deployment 的事件信息，可以看到 Deployment 完成了更新：
# kubectl describe deployment/nginx-deployment

Pod 的扩容和缩容
手动:kubectl scale deployment nginx - dep l oyment – replicas 5
自动:Horizontal Pod Autoscaler ( HPA ）的控制器，用于实现基于CPU使用率进行自动Pod扩容和缩容的功能。
kubectl aut。scale depl。yment php-apache --min=l --max=lO --cpu-percent=SO
或者：通过yaml创建HPA，设置minReplicas、maxReplicas和targetCPUUtilizationPercentage参数

3.Service

Service是Kubemetes最核心的概念，通过创建Service，可以为一组具有相同功能的容器应
用提供一个统一的入口地址，井且将请求负载分发到后端的各个容器应用上。
重点：Service的负载均衡、外网访问、DNS服务的搭建、Ingress7层路由机制等。

总结

在学习k8s前需要对容器、镜像等概念比较清楚，因为k8s是基于容器的分布式，同时很多kubectl命令实际上和docker的命令是如出一辙的。然后对k8s的基础组件有所掌握，比如Master包括spi-server、controller-manage,scheduler，Node中主要包含进程kubelet和kube-proxy进程，在理解这几个组件是如何配合的。其次需要理解Pod、Service、Deployment等核心概念，理清NodeIp、PodIp、ClusterIp三个ip的概念以及endpoint。

附录

kubectl可操作的资源类型一览表：

序号	资源类型	缩写	说明
1	clusters
2	componentstatuses	CS
3	configmaps	cm
4	daemonsets	ds
5	deployments	deploy
6	endpoints	ep
7	events	ev
8	horizontalpodautoscalers	hpa
9	ingresses	ing
10	Jobs
11	limitranges	limits
12	nodes	no
13	namespaces	ns
14	networkpolicies
15	nodes	no
16	statefulsets
17	persistentvolumeclaims	pvc
18	persistentvolumes	pv
19	pods	po
20	podsecuritypolicies	psp
21	podtemplates
22	replicasets	rs	升级版RC，支持基于集合的标签选择
23	replicationcontrollers	rc	RC将逐渐被RS和Deployment所取代
24	resourcequotas	quota
25	cronjob
26	secrets
27	serviceaccounts
28	services	svc
29	storageclasses	sc
30	thirdpartyresources