kubernetes 思维导图模板_ProcessOn思维导图、流程图

资源对象

Spec

期望的状态

Staus

观测的状态

Metadata

Labels

标识型的kv元数据

用于筛选资源

先于普通container启动执行，直到所有initcontainer执行成功后，普通container才会被启动

唯一的组合资源的方法

可以用selector来查询

Annotations

存储资源的非标识性信息

扩展资源的spec/status

OwnerReference

所有者即集合类资源

pod的集合：replicaset、statefulset

集合类资源的控制器创建了归属资源

replicaset控制器创建pod

方便反向查找创建资源的对象

方便进行级联删除

InitContainer

pod中多个initcontainer按次序依次启动执行，pod中多个普通container是并行启动

initcontainer执行成功后就结束退出了，普通容器可能会一直执行或者重启

示例

Pod

生命周期

status

Pending：Pod 的配置已经被 API Server 存储到 etcd 中，但是此Pod因为某种原因不能被创建

Running：Pod 已经被调度成功并且绑定到了某个节点上，容器创建成功并开始运行

Succeeded：Pod 都正常运行完毕并已退出，这种状态一般在一次性任务中比较常见

Faild：Pod 里至少有一个容器运行不正常（非0状态退出），需要查找Pod失败原因

Unknown：Pod 的状态不能持续的被 kubelet 汇报给 API Server，可能是主节点也 kubelet通信问题

conditions

PodScheduled Pod 是否已经被调度，即给他分配了物理节点

ContainersReady 容器是否已经处于 Ready 状态

Ready Pod 是否应 Running 并且能够对外提供服务

Initialized 是否完成了容器初始化操作

Unschedulable 可能资源不足导致调度失败

容器探针

livenessProbe

指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success

readinessProbe

指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success

handler

ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的

TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。

hook

Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中

类型

exec：执行一段命令

HTTP：发送HTTP请求

示例

Preset

用来在 Pod 创建的时候向 Pod 中注入某些特定信息。该信息可以包括 secret、volume、volume mount 和环境变量

控制器

Deployment

操作

更新镜像

kubectl set image deployment.v1.apps.nginx-deployment nginx=nginx:1.9.1

回滚上一版本

kubectl rollout undo deployment/nginx-deployment

回滚指定版本

kubectl rollout undo deployment/nginx-deployment --to-revisions=2

查询版本

kubectl rollout history deployment/nginx-deployment

查看状态

kubectl rollout status deployment/nginx-deployment

扩缩容

kubectl scale deploy nginx-deployment --replicas=10

暂停

kubectl rollout pause deploy nginx-deployment

恢复

kubectl rollout resume deploy nginx-deployment

更新资源

kubectl set resources deploy nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

管理模式

只负责管理不同版本的replicaset，由relicaset管理pod副本数

每个replicaset对应了deployment的一个版本

一个replicaset下的pod都是相同的版本

spec字段

MinReadySeconds

判断pod available的最新ready时间

revisionHistoryLimit

保留历史的数量，默认为10

paused

标识只做数量维持、不做新的发布

progressDeadlineSeconds

判断status为failed的最大时间

定义

定义一组pod的期望数量

配置pod发布方式，保证更新过程中不可用的pod数量在限定范围内

如果发布有问题，支持一键回滚

示例

Job

定义

创建一个或多个pod确保指定数量的pod可以成功的运行终止

跟踪pod状态，根据配置及时重试失败的pod

确定依赖关系，保证上一个任务运行完毕后再运行下一个任务

控制任务并行度，并根据配置确保pod队列大小

管理模式

Job Controller负责根据配置创建pod

Job Controller跟踪job状态，根据配置及时重试pod或者继续创建

Job Controller会自动添加label来跟踪对应的pod，并根据配置并行或者串行创建pod

示例

DaemonSet

定义

保证集群内每一个节点运行一组相同的pod

跟踪集群节点状态，保证新加入的节点自动创建对应的pod

跟踪集群节点状态，保证移除的节点删除对应的pod

跟踪pod状态，保证每个节点pod处于运行状态

更新策略

RollingUpdate：老的pod会被先删除，然后再去创建新的pod

OnDelete：只有手动的删除某一个对应的pod，此节点才会被更新

管理模式

DaemonSet Controller负责根据配置创建pod

DaemonSet Controller跟踪job状态，根据配置及时重试pod或者继续创建

DaemonSet Controller会自动添加affinity&label来跟踪对应的pod，并根据配置在每个节点或者适合的部分节点创建pod

指定节点

nodeSelector：只调度到匹配指定label的Node上

nodeAffinity：功能更丰富的Node选择器，比如支持集合操作

podAffinity：调度到满足条件的Pod所在的Node上

示例

Service

类型

ClusterIP

ExternalName

NodePort

LoadBalancer

StatefulSet

定义

StatefulSet 中的 Pod 都是有序号的，从 0 开始一直到定义的 replica 数量减一

每个 Pod 都有独立的网络标识：一个 hostname、一块独立的 pvc 以及 pv 存储

扩缩容策略

OrderedReady，扩缩容就严格按照 Order 顺序来执行

Parallel，并行扩缩容，不需要等前面的 Pod 都 Ready 或者删除后再处理下一个

示例

配置管理

可变配置

ConfigMap

大小限制1mb

pod只能引用相同namespace的ConfigMap

pod引用的ConfigMap不存在时，无法创建成功

manifest创建的static pod不能使用ConfigMap

敏感信息

Secret

采用base-64编码保存

类型

Opaque

kubernetes.io/service-account-token

kubernetes.io/dockerconfigjson

身份认证

ServiceAccount

用于解决pod在集群中的身份认证问题

资源配置

Spec.Containers[].Resources.limits/requests

cpu 单位millicore

memory 单位Byte

ephemeral-storage（临时存储）单位Byte

服务质量分类

guaranteed

内存和cpu限制和请求必须设置，并且必须是一样的

burstable

至少有一个内存或者cpu限制和请求

besteffort

安全管控

Spec.Containers[].SecurityContext

前置检验

Spec.InitContainers

存储

类型

本地存储

emptydir/hostpath

网路存储

in-tree：awsElaticBlockStore

out-of-tree：csi等网络存储

Projected Volume：secret/configmap

PVC与PV体系

PV、PVC

定义

PVC 是在 K8s 中一种抽象的存储卷类型，代表了某个具体类型存储的数据卷表达

PV 在 K8s 中代表一个具体存储类型的卷，其对象中定义了具体存储类型和卷参数

关系

PVC 和 PV 总是成对出现的，PVC 必须与 PV 绑定后才能被应用（Pod）消费；

PVC 和 PV 是一一绑定关系，不存在一个 PV 被多个 PVC 绑定，或者一个 PVC 绑定多个 PV 的情况；

PVC 是应用层面的存储概念，是属于具体的名词空间的；

PV 是存储层面的存储概念，是集群级别的，不属于某个名词空间；PV 常由专门的存储运维人员负责管理；

消费关系上：Pod 消费 PVC，PVC 消费 PV，而 PV 定义了具体的存储介质

绑定规则

VolumeMode：被消费 PV 的 VolumeMode 需要和 PVC 一致；

AccessMode：被消费 PV 的 AccessMode 需要和 PVC 一致；

StorageClassName：如果 PVC 定义了此参数，PV 必须有相关的参数定义才能进行绑定；

LabelSelector：通过 label 匹配的方式从 PV 列表中选择合适的 PV 绑定；

storage：被消费 PV 的 capacity 必须大于或者等于 PVC 的存储容量需求才能被绑定

如果同时有多个 PV 满足需求，则需要从 PV 中选择一个更合适的进行绑定；通常选择容量最小的，如果容量最小的也有多个，则随机选择。如果没有满足上述需求的 PV 存储，则 PVC 会处于 Pending 状态，等待有合适的 PV 出现了再进行绑定

spec字段

AccessModes

ReadWriteOnce 只允许单node访问

ReadOnlyMany 允许多个node只读访问

ReadWriteMany 允许多个node读写访问

PersistentVolumeReclaimPolicy

Delete VC 被删除之后，PV 也会被删除

Retain 保留之后，后面这个 PV 需要管理员来手动处理

StorageClassName

动态 Provisioning 时必须指定的一个字段，就是说我们要指定到底用哪一个模板文件来生成 PV

csi 使用存储流程

用户提交PVC，由 csi-provisioner创建存储，并生成 PV 对象，之后 PV controller 将 PVC 及生成的 PV 对象做 bound

户在提交 pod yaml 的时候，首先会被调度选中某一个合适的 node，等 pod 的运行 node 被选出来之后，会被 AD Controller watch 到 pod 选中的 node，它会去查找 pod 中使用了哪些 PV。然后它会生成一个内部的对象叫 VolumeAttachment 对象，从而去触发 csi-attacher去调用 csi-controller-server 去做真正的 attache 操作，attach 操作调到云存储厂商 OpenAPI。这个 attach 操作就是将存储 attach到 pod 将会运行的 node 上面

创建 pod 的过程中，首先要去做一个 mount，这里的 mount 操作是为了将已经 attach 到这个 node 上面那块盘，进一步 mount 到 pod 可以使用的一个具体路径，之后 kubelet 才开始创建并启动容器

示例

静态、动态存储卷

定义

静态：一般先由集群管理员分析集群中存储需求，并预先分配一些存储介质，同时创建对应的 PV 对象，创建好的 PV 对象等待 PVC 来消费

动态：由集群管理员配置好后端的存储池，并创建相应的模板（storageclass），等到有 PVC 需要消费 PV 的时候，根据 PVC 定义的需求，并参考 storageclass 的存储细节，由 Provisioner 插件动态创建一个 PV

动态创建流程

当用户声明一个 PVC 时，当 PVC 在集群中找不到匹配的 PV

PVC根据 StorageClassName 的定义触发相应的 Provisioner 插件创建合适的 PV

PV 创建完成后，Provisioner 实现与 PVC 的绑定

应用监控

健康状态

探测方式

httpGet

Exec

tcpSocket

探测结果

Success

Failure

Unknown

重启策略

Always

OnFailure

Never

其他参数

initialDelaySeconds 延迟多久检查

periodSeconds 检查间隔

timeoutSeconds 探测超时

successThreashold 探测失败后再次判断成功的阈值

failureThreshold 探测失败的重试次数

Liveness

判断容器是否存活，pod是否为running

检测失败会杀掉pod，并根据配置的策略判断是否重启

支持重新拉起的应用

Readiness

判断容器是否启动完成，pod是否为ready

检测失败会将pod从endpoint中移除

启动后无法立即对外服务的应用

类型

资源监控

性能监控

安全监控

事件监控

容器网络

方案划分

Underlay

它与 Host 网络是同层的，从外在可见的一个特征就是它是不是使用了 Host 网络同样的网段、输入输出基础设备、容器的 IP 地址是不是需要与 Host 网络取得协同（来自同一个中心分配或统一划分）

Overlay

它不需要从 Host 网络的 IPM 的管理的组件去申请 IP，一般来说，它只需要跟 Host 网络不冲突，这个 IP 可以自由分配的

方案实现

flannel

backend

用户态的 udp，这种是最早期的实现；

内核的 Vxlan，Vxlan 的性能会比较好一点，但是它对内核的版本是有要求的，需要内核支持 Vxlan 的特性功能；

如果你的集群规模不够大，又处于同一个二层域，也可以选择采用 host-gw 的方式。这种方式的 backend 基本上是由一段广播路由规则来启动的，性能比较高。

Network Policy

采用各种选择器（标签或 namespace），找到一组 pod，或者找到相当于通讯的两端，然后通过流的特征描述来决定它们之间是不是可以联通，可以理解为一个白名单的机制

使用前提

apiserver开启extensions/v1beta1/networkpolicies

我们选用的网络插件需要支持 Network Policy，入Calico、Weave Net

示例

CNI

配置流程

在每个结点上配置 CNI 配置文件 (/etc/cni/net.d/xxnet.conf)，其中 xxnet.conf 是某一个网络配置文件的名称

安装 CNI 配置文件中所对应的二进制插件

在这个节点上创建 Pod 之后，再由 CNI 插件进入 Pod 的网络空间去配置 Pod 的网络

模式

Overlay

典型特征是容器独立于主机的IP段，这个IP段进行跨主机网络通信时是通过在主机之间创建隧道的方式，将整个容器网段的包全都封装成底层的物理网络中主机之间的包。该方式的好处在于它不依赖于底层网络

路由模式

主机和容器也分属不同的网段，它与 Overlay 模式的主要区别在于它的跨主机通信是通过路由打通，无需在不同主机之间做一个隧道封包。但路由打通就需要部分依赖于底层网络，比如说要求底层网络有二层可达的一个能力

Underlay

容器和宿主机位于同一层网络，两者拥有相同的地位。容器之间网络的打通主要依靠于底层网络。因此该模式是强依赖于底层能力的

评估

环境限制

虚拟化环境（例如 OpenStack）中的网络限制较多，比如不允许机器之间直接通过二层协议访问，必须要带有 IP 地址这种三层的才能去做转发，限制某一个机器只能使用某些 IP 等。在这种被做了强限制的底层网络中，只能去选择 Overlay 的插件，常见的有 Flannel-vxlan, Calico-ipip, Weave 等等；

物理机环境中底层网络的限制较少，比如说我们在同一个交换机下面直接做一个二层的通信。对于这种集群环境，我们可以选择 Underlay 或者路由模式的插件。Underlay 意味着我们可以直接在一个物理机上插多个网卡或者是在一些网卡上做硬件虚拟化；路由模式就是依赖于 Linux 的路由协议做一个打通。这样就避免了像 vxlan 的封包方式导致的性能降低。这种环境下我们可选的插件包括 clico-bgp, flannel-hostgw, sriov 等等；

公有云环境也是虚拟化，因此底层限制也会较多。但每个公有云都会考虑适配容器，提升容器的性能，因此每家公有云可能都提供了一些 API 去配置一些额外的网卡或者路由这种能力。在公有云上，我们要尽量选择公有云厂商提供的 CNI 插件以达到兼容性和性能上的最优。比如 Aliyun 就提供了一个高性能的 Terway 插件

功能需求

安全需求

支持 NetworkPolicy 比如 Calico, Weave

是否需要集群外的资源与集群内的资源互联互通

可以选择 Underlay 的网络，比如 sriov 这种就是 Pod 和以前的虚拟机或者物理机在同一层。我们也可以使用 calico-bgp，此时它们虽然不在同一网段，但可以通过它去跟原有的路由器做一些 BGP 路由的一个发布，这样也可以打通虚拟机与容器

K8s 的服务发现与负载均衡的能力

很多 Underlay 模式的插件，在 Pod 中的网卡是直接用的 Underlay 的硬件，或者通过硬件虚拟化插到容器中的，这个时候它的流量无法走到宿主机所在的命名空间，因此也无法应用 kube-proxy 在宿主机配置的规则

性能需求

Pod 的创建速度

需要紧急大规模扩容时，Overlay 和路由模式创建速度是很快的，因为它是在机器里面又做了虚拟化，所以只需要调用内核接口就可以完成这些操作。但对于 Underlay 模式，由于需要创建一些底层的网络资源，所以整个 Pod 的创建速度相对会慢一些

Pod 的网络性能

Overlay 模式的性能较差，因为它在节点上又做了一层虚拟化，还需要去封包，封包又会带来一些包头的损失、CPU 的消耗等，如果大家对网络性能的要求比较高，比如说机器学习、大数据这些场景就不适合使用 Overlay 模式。这种情形下我们通常选择 Underlay 或者路由模式的 CNI 插件

CNI 插件开发

给 Pod 准备一个网卡，通常我们会用一个 “veth” 这种虚拟网卡，一端放到 Pod 的网络空间，一端放到主机的网络空间，这样就实现了 Pod 与主机这两个命名空间的打通

给 Pod 分配 IP 地址，这个 IP 地址有一个要求， IP 地址在集群里需要是唯一的。

配置 Pod 的 IP 和路由
1、将分配到的 IP 地址配置给 Pod 的虚拟网卡；
2、在 Pod 的网卡上配置集群网段的路由
3、在宿主机上配置到 Pod 的 IP 地址的路由

给 Pod 连上网络，一般我们是在 CNI Daemon 进程中去做这些网络打通的事情。通常来说是这样一个步骤：
1、 CNI 在每个节点上运行的 Daemon 进程会学习到集群所有 Pod 的 IP 地址及其所在节点信息。
2、拿到 Pod 以及 Node 的相关信息之后，再去配置网络进行打通

CRI

定义

容器运行时的操作抽象出一个接口，将 Kubelet 代码与具体的容器运行时的实现代码解耦开，只要实现了这样一套接口，就能接入到 Kubernetes 的体系中

CRD

示例

第三方应用

OpenKruise

CloneSet

提供了更加高效、确定可控的应用管理和部署能力，支持优雅原地升级、指定删除、发布顺序可配置、并行/灰度发布等丰富的策略，可以满足更多样化的应用场景

示例

Advanced StatefulSet

基于原生 StatefulSet 之上的增强版本，默认行为与原生完全一致，在此之外提供了原地升级、并行发布（最大不可用）、发布暂停等功能

SidecarSet

对 sidecar 容器做统一管理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器

示例

UnitedDeployment

通过多个 subset workload 将应用部署到多个可用区

示例

BroadcastJob

配置一个 job，在集群中所有满足条件的 Node 上都跑一个 Pod 任务

CompletionPolicy

Always 策略意味着 job 最终会完成，不管是执行成功还是失败了

ActiveDeadlineSeconds：指定一个超时时间，如果 BroadcastJob 开始运行超过了这个时间，所有还在跑着的 job 都会被停止、并标记为失败。

BackoffLimit：指定一个重试次数，超过这个次数后才标记 job 失败，默认没有限制。目前，Pod 实际的重试次数是看 Pod status 中上报所有容器的 ContainerStatus.RestartCount 重启次数。如果这个重启次数超过了 BackoffLimit，这个 job 就会被标记为失败、并把运行的 Pod 删除掉。

TTLSecondsAfterFinished 限制了 BroadcastJob 在完成之后的存活时间，默认没有限制。比如设置了 TTLSecondsAfterFinished 为 10s，那么当 job 结束后超过了 10s，控制器就会把 job 和下面的所有 Pod 删掉。

Never 策略意味着 BroadcastJob 永远都不会结束（标记为 Succeeded 或 Failed），即使当前 job 下面的 Pod 都已经执行成功了

示例

核心功能

原地升级

原地升级是一种可以避免删除、新建 Pod 的升级镜像能力。它比原生 Deployment/StatefulSet 的重建 Pod 升级更快、更高效，并且避免对 Pod 中其他不需要更新的容器造成干扰。

Sidecar 管理

支持在一个单独的 CR 中定义 sidecar 容器，OpenKruise 能够帮你把这些 Sidecar 容器注入到所有符合条件的 Pod 中。这个过程和 Istio 的注入很相似，但是你可以管理任意你关心的 Sidecar。

跨多可用区部署

定义一个跨多个可用区的全局 workload，容器，OpenKruise 会帮你在每个可用区创建一个对应的下属 workload。你可以统一管理他们的副本数、版本、甚至针对不同可用区采用不同的发布策略。

部署

下载安装包

wget -c https://sealyun.oss-cn-beijing.aliyuncs.com/d551b0b9e67e0416d0f9dce870a16665-1.18.0/kube1.18.0.tar.gz

安装集群

sealos init --passwd 123456 \
--master 192.168.0.2 --master 192.168.0.3 --master 192.168.0.4 \
--node 192.168.0.5 \
--pkg-url /root/kube1.18.0.tar.gz \
--version v1.18.0

集群操作

增加master

sealos join --master 192.168.0.6 --master 192.168.0.7
sealos join --master 192.168.0.6-192.168.0.9 # 或者多个连续IP

删除master

sealos clean --master 192.168.0.6 --master 192.168.0.7
sealos clean --master 192.168.0.6-192.168.0.9 # 或者多个连续IP

增加node

sealos join --node 192.168.0.6 --node 192.168.0.7
sealos join --node 192.168.0.6-192.168.0.9 # 或者多个连续IP

删除node

sealos clean --node 192.168.0.6 --node 192.168.0.7
sealos clean --node 192.168.0.6-192.168.0.9 # 或者多个连续IP

清理集群

sealos clean

觉得不错，帮忙点个赞
赠人玫瑰，手留余香