k8s从入门到精通

最新推荐文章于 2024-04-24 15:24:22 发布

seeyoutlb

最新推荐文章于 2024-04-24 15:24:22 发布

阅读量1.2k

点赞数 15

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/User_bie/article/details/134784544

版权

文章目录

目标
一、核心概念

目标

1.深入理解k8s各大资源对象及最佳实践

2.熟练运用k8s各项调度策略

3.掌握k8s网络原理及应用

4. 数量掌握pod控制器及运用场景

5.熟练掌握k8s微服务DevOps实战

一、核心概念

1.认识k8s

1.1 什么是k8s

概念：是一个开源的，管理云平台中多个主机上的容器化应用；

1.2 k8s解决了什么问题

1.应用部署的三大阶段
a.传统部署：
	缺点：应用之间环境不隔离 ↓

在这里插入图片描述

b.虚拟化部署 
	缺点：虚拟机资源浪费 ↓

在这里插入图片描述

c.容器化部署
	解决：环境隔离、资源浪费问题 ↓

在这里插入图片描述

2.k8s特点
2.1 自我修复
2.2 弹性伸缩
2.3 自动部署和回滚
2.4 服务发现和负载均衡
	使用k8s后可以需要nginx
2.5 机密和配置管理
2.6 存储编排
	抽象虚拟磁盘，容器访问虚拟磁盘，虚拟磁盘自动映射到物理磁盘进行访问
2.7 批处理

1.3 企业容器调度平台

1.3.1 apache mesos

优势：早于docker、5w+电脑控制
缺点：面相机器设计

1.3.2 docker swarm

优势：与docker无缝集成，学习成本低
缺点：官方抛弃

1.3.3 k8s

优势：容器调度的标准

2.集群架构与组件

k8s调度架构图 ↓

2.1 组件

2.1.1 控制面板：5个（master节点上）

在这里插入图片描述

a.kube-apiserver

接口服务：基于REST风格开放k8s接口的服务

b.kube-controller-manager

控制器管理器：管理各个类型的控制器
	包括：节点控制器、任务控制器、端点分片控制器、服务账号控制器登

c.cloud-controller-manager

云控制器管理器：第三方云平台提供的控制器api对接管理功能

d.kube-scheduler

调度器：负责将pod基于一定算法将其调用到更合适的节点上

e.etcd

理解为k8s的数据库，键值存储的分布式数据库；基于raft算法实现高可用

2.1.2 节点组件:至少3个（slave节点上）

在这里插入图片描述

a.kubelet

负责pod的生命周期、存储

b.kube-proxy

网络代理：负责service的服务发现及对应的负载均衡（4层负载 基于iptables实现）

*后面会有替代方案

c.container runtime

容器运行时环境：docker、containerd、CRI-O

2.1.3 附加组件：6个

a.kube-dns

为负责为整个k8s集群提供DNS服务

b.ingress controller

为服务提供外网入口；外部网络访问到k8s的情况

c.prometheus

提供资源监控

d.dashboard

控制台界面

e.federation

提供跨可用区的集群；理解为集群间的调度

f.fluentd-elasticsearsh

提供集群日志采集、存储与查询

2.2 分层架构

2.2.1 生态系统（怎么调用）

2.2.2 接口层

2.2.3 管理层

系统度量（如基础设施、容器和网络的度量）、自动化（如自动扩展、动态provision等）及策略管理（RBAC、Quota、PSP、NetworkPolicy等）

2.2.4 应用层

部署（无状态/有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
pod所在层

2.2.5 核心层

k8s最核心功能：对外提供API构建高层的应用、对内提供插件式应用执行环境

3.核心概念

3.1 服务的分类

3.1.1 无状态

代表应用：nginx、tomcat
优点：对客户端透明、无依赖关系、可以高效实现扩缩容和迁移
缺点：不能存储数据，需要额外的数据服务支持

3.1.2 有状态

代表应用：mysql、redis
优点：可以独立存储数据、实现数据管理
缺点：集群环境下需要实现主从、数据同步、备份、水平扩容复杂

3.2 资源和对象

3.2.1 资源的分类（3类代表）

在这里插入图片描述

3.2.1.1 元数据型

集群资源之上的资源：对资源的元数据描述，每一个资源都可以使用元空间的数据。
1.Horizontal Pod Autoscaler (HPA)：pod 水平自动伸缩；例子，通过java应用开放接口，k8s调用，判断后自动扩容缩容
（比如1000个用户运行几个实例，100个用户运行几个实例）
2.PodTemplate：Pod模版
3.LimitRange：通过request（最少需要多少资源）和limit（最多可以用多少资源）对集群内资源进行限制

3.2.1.2 集群级

k8s集群下的所有资源都可以共享该资源。
1.Namespace：命名空间
2.Node：服务器的概念
3.ClusterRole：集群角色，对集群权限进行管理
4.ClusterRoleBinding：用户认证，角色鉴权；让资源绑定对应角色:把
	role/clusterRole绑定到k8s集群

3.2.1.3 命名空间级（重点使用）

Pod：容器组；
强依赖紧耦合的多个容器可以放在一个pod；
其他情况都应该一个容器一个pod

为什么需要pod？
每个pod中默认会有一个pause容器，这个pause容器的是pod中容器通讯的桥梁

pod结构组成↓
在这里插入图片描述

控制器↓
在这里插入图片描述

集群资源之下的资源：多个命名空间的资源无法相互访问。
1.工作负载型：
	1.1 Pod的副本（replicas）：
	 	弹性扩缩容都是基于replicas实现
	1.2 Pod的控制器：(控制器是特殊的pod，在其基础上进行了封装）
		1.2.1 适用于无状态服务
			1.ReplicationController(RC): v1.1以后就被RS替代了
				作用：帮助我们动态更新pod副本数
				缺点：需要与pod模版进行绑定，绑定不方便
			2.ReplicasSet(RS):
				优点：相比RC，加入了label和selector的机制
				为pod打上label标签，通过selector可以选择读那些pod生效
				缺点：只支持扩缩容
			3.Deployment（重点）: 对RS更高层次封装，提供了更丰富的部署相关的功能
				优点：自动创建rs、自动创建pod、自动滚动升级和回滚、平滑扩缩容、暂停
				（5-6次改完后再升恢复，然后会自动升级）和恢复
		1.2.2 适用于有状态服务
			1.StatefulSet: （由Headless service与volumeClaimTemplate组成）
			作用：专门针对于有状态服务进行部署的控制器
			特点：1.持久化存储、2.稳定的网络标志、3.有序部署和扩展、4.有序收缩和删除
		1.2.3 守护进程
			1.DaemonSet: 根据label和selector将所有匹配到的pod 部署一个守护进程
			场景：日志收集、系统监控、系统程序
			
		1.2.4 任务/定时任务：执行完直接销毁
			1.Job:
			2.CronJob: 
2.服务发现
	2.1 Service: 实现东西流量
		k8s集群内网络通信（4层负载）：节点与节点、pod与pod之间；
	2.2 Ingress：实现南北流量
		k8s内部服务暴露给外网访问的服务：
		实现方案：ingress-nginx 反向代理和负载均衡（7层负载）
3.存储：pod内数据与外部共享
	3.1 volume：共享pod中的数据挂在到node
	3.2 CSI: 容器存储接口，volume插件实现和这个接口就可以
4.特殊类型配置：pod内配置与外部关联
	4.1 ConfigMap：k-v 配置
	4.2 Secret：多了加密
	4.3 DownwardAPI：pod数据共享到容器内
		1.通过环境变量
		2.通过volume挂载
5.其他
	5.1 Role：定义命名空间一组权限
	5.2 RoleBindiing：把role/clusterRole绑定到命名空间

-------------------------------------无状态控制器:start ↓-------------------------------------

Pod控制器：ReplicationController（RC） ↓
在这里插入图片描述

Pod控制器：ReplicasSet(RS) ↓

在这里插入图片描述
Pod控制器：Deployment ↓

-------------------------------------无状态控制器:end ↑-------------------------------------

-------------------------------------有状态控制器:start ↓-------------------------------------
StatefulSet:有状态
在这里插入图片描述

-------------------------------------有状态控制器:end ↑-------------------------------------

------------------------------------- DaemonSet：守护进程 ↓-------------------------------------
在这里插入图片描述
------------------------------------- DaemonSet：守护进程 ↑-------------------------------------

---------------------------------------------Service/Ingress↓-----------------------------------
东西流量/南北流量

在这里插入图片描述

---------------------------------------------Service/Ingress↑-----------------------------------

3.2.2 资源清单（json/yml配置文件）

此处是k8s常用yaml配置及说明

3.3 对象规约和状态

3.3.1 规约

yaml里面中spec描述：它描述了一个对象的期望状态

3.3.2 状态

表示对象的实际状态：由k8s自己维护，k8s会通过一系列控制器使得对象实际状态接近期望状态

4. 微服务k8s环境演示

二.深入k8s 实战进阶

1. 搭建k8s集群

1.1 搭建方案

1.minkube
2.kubeadm（推荐）
3.二进制安装
	1.操作系统：CentOS 7
		https://blog.csdn.net/User_bie/article/details/123595578
	2.安装docker：20+
		https://blog.csdn.net/User_bie/article/details/134881413
	3.k8s:1.23.6
		
4.命令行工具

kubeadm安装 ↓
在这里插入图片描述

传送门：k8s集群搭建

1.2 命令行工具kubectl

官网传送门：kubectl命令行命令

常用命令：如下
在这里插入图片描述

1.2.1 自动补全

1.2.2 任意节点使用kubectl

#1.将maste节点中的/etc/kubernetes/admin.conf拷贝到其他节点的目录中/etc/kubernetes/
# master执行
scp /etc/kubernetes/admin.conf root@[替换成节点名或节点ip地址]:/etc/kubernetes/
# 1.1.1 通过node名拷贝
[root@k8s-master .kube]# kubectl get no
NAME         STATUS   ROLES                  AGE     VERSION
k8s-master   Ready    control-plane,master   6d15h   v1.23.6
k8s-node1    Ready    <none>                 6d15h   v1.23.6
k8s-node2    Ready    <none>                 6d15h   v1.23.6

[root@k8s-master .kube]# scp /etc/kubernetes/admin.conf root@k8s-node1:/etc/kubernetes/

#操作：输入密码、输入os的密码、ls查看是否拷贝成功

# 1.1.2 IP拷贝
[root@k8s-master .kube]# scp /etc/kubernetes/admin.conf root@192.168.190.131:/etc/kubernetes/

#操作：输入密码、输入os的密码、ls查看是否拷贝成功

#2.对应的node节点上配置环境变量
[root@k8s-node1 kubernetes]# echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
[root@k8s-node1 kubernetes]# source ~/.bash_profile

#3.测试：ok ↓
[root@k8s-node1 kubernetes]# kubectl get no
NAME         STATUS   ROLES                  AGE     VERSION
k8s-master   Ready    control-plane,master   6d15h   v1.23.6
k8s-node1    Ready    <none>                 6d15h   v1.23.6
k8s-node2    Ready    <none>                 6d15h   v1.23.6

1.2.3 资源操作

创建资源↓

$ kubectl create -f ./my-manifest.yaml           # 创建资源
$ kubectl create -f ./my1.yaml -f ./my2.yaml     # 使用多个文件创建资源
$ kubectl create -f ./dir                        # 使用目录下的所有清单文件来创建资源
$ kubectl create -f https://git.io/vPieo         # 使用 url 来创建资源
$ kubectl run nginx --image=nginx                # 启动一个 nginx 实例
$ kubectl explain pods,svc                       # 获取 pod 和 svc 的文档

显示和查找资源↓

# Get commands with basic output
$ kubectl get services                          # 列出所有 namespace 中的所有 service
$ kubectl get pods --all-namespaces             # 列出所有 namespace 中的所有 pod
$ kubectl get pods -o wide                      # 列出所有 pod 并显示详细信息
$ kubectl get deployment my-dep                 # 列出指定 deployment
$ kubectl get pods --include-uninitialized      # 列出该 namespace 中的所有 pod 包括未初始化的

# 使用详细输出来描述命令
$ kubectl describe nodes my-node
$ kubectl describe pods my-pod

$ kubectl get services --sort-by=.metadata.name # List Services Sorted by Name

# 根据重启次数排序列出 pod
$ kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# 获取所有具有 app=cassandra 的 pod 中的 version 标签
$ kubectl get pods --selector=app=cassandra rc -o \
  jsonpath='{.items[*].metadata.labels.version}'

# 获取所有节点的 ExternalIP
$ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# 列出属于某个 PC 的 Pod 的名字
# “jq”命令用于转换复杂的 jsonpath，参考 https://stedolan.github.io/jq/
$ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
$ echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# 查看哪些节点已就绪
$ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# 列出当前 Pod 中使用的 Secret
$ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

更新资源↓

$ kubectl rolling-update frontend-v1 -f frontend-v2.json           # 滚动更新 pod frontend-v1
$ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # 更新资源名称并更新镜像
$ kubectl rolling-update frontend --image=image:v2                 # 更新 frontend pod 中的镜像
$ kubectl rolling-update frontend-v1 frontend-v2 --rollback        # 退出已存在的进行中的滚动更新
$ cat pod.json | kubectl replace -f -                              # 基于 stdin 输入的 JSON 替换 pod

# 强制替换，删除后重新创建资源。会导致服务中断。
$ kubectl replace --force -f ./pod.json

# 为 nginx RC 创建服务，启用本地 80 端口连接到容器上的 8000 端口
$ kubectl expose rc nginx --port=80 --target-port=8000

# 更新单容器 pod 的镜像版本（tag）到 v4
$ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

$ kubectl label pods my-pod new-label=awesome                      # 添加标签
$ kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # 添加注解
$ kubectl autoscale deployment foo --min=2 --max=10                # 自动扩展 deployment “foo”

修补资源↓

$ kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新节点

# 更新容器镜像； spec.containers[*].name 是必须的，因为这是合并的关键字
$ kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# 使用具有位置数组的 json 补丁更新容器镜像
$ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# 使用具有位置数组的 json 补丁禁用 deployment 的 livenessProbe
$ kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

编辑资源↓

$ kubectl edit svc/docker-registry                      # 编辑名为 docker-registry 的 service
$ KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # 使用其它编辑器

scale资源↓

$ kubectl scale --replicas=3 rs/foo                                 # Scale a replicaset named 'foo' to 3
$ kubectl scale --replicas=3 -f foo.yaml                            # Scale a resource specified in "foo.yaml" to 3
$ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # If the deployment named mysql's current size is 2, scale mysql to 3
$ kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Scale multiple replication controllers

删除资源↓

$ kubectl delete -f ./pod.json                                              # 删除 pod.json 文件中定义的类型和名称的 pod
$ kubectl delete pod,service baz foo                                        # 删除名为“baz”的 pod 和名为“foo”的 service
$ kubectl delete pods,services -l name=myLabel                              # 删除具有 name=myLabel 标签的 pod 和 serivce
$ kubectl delete pods,services -l name=myLabel --include-uninitialized      # 删除具有 name=myLabel 标签的 pod 和 service，包括尚未初始化的
$ kubectl -n my-ns delete po,svc --all                                      # 删除 my-ns namespace 下的所有 pod 和 serivce，包括尚未初始化的

1.2.4 Pod与集群

与运行的pod交互 ↓

$ kubectl logs my-pod                                 # dump 输出 pod 的日志（stdout）
$ kubectl logs my-pod -c my-container                 # dump 输出 pod 中容器的日志（stdout，pod 中有多个容器的情况下使用）
$ kubectl logs -f my-pod                              # 流式输出 pod 的日志（stdout）
$ kubectl logs -f my-pod -c my-container              # 流式输出 pod 中容器的日志（stdout，pod 中有多个容器的情况下使用）
$ kubectl run -i --tty busybox --image=busybox -- sh  # 交互式 shell 的方式运行 pod
$ kubectl attach my-pod -i                            # 连接到运行中的容器
$ kubectl port-forward my-pod 5000:6000               # 转发 pod 中的 6000 端口到本地的 5000 端口
$ kubectl exec my-pod -- ls /                         # 在已存在的容器中执行命令（只有一个容器的情况下）
$ kubectl exec my-pod -c my-container -- ls /         # 在已存在的容器中执行命令（pod 中有多个容器的情况下）
$ kubectl top pod POD_NAME --containers               # 显示指定 pod 和容器的指标度量

与节点和集群交互 ↓

$ kubectl cordon my-node                                                # 标记 my-node 不可调度
$ kubectl drain my-node                                                 # 清空 my-node 以待维护
$ kubectl uncordon my-node                                              # 标记 my-node 可调度
$ kubectl top node my-node                                              # 显示 my-node 的指标度量
$ kubectl cluster-info                                                  # 显示 master 和服务的地址
$ kubectl cluster-info dump                                             # 将当前集群状态输出到 stdout                                    
$ kubectl cluster-info dump --output-directory=/path/to/cluster-state   # 将当前集群状态输出到 /path/to/cluster-state

# 如果该键和影响的污点（taint）已存在，则使用指定的值替换
$ kubectl taint nodes foo dedicated=special-user:NoSchedule

1.2.5 资源类型与别名

资源类型	缩写别名
clusters
componentstatuses	cs
configmaps	cm
daemonsets	ds
deployments	deploy
endpoints	ep
event	ev
horizontalpodautoscalers	hpa
ingresses	ing
jobs
limitranges	limits
`namespaces`	`ns`
networkpolicies
`nodes`	`no`
statefulsets
persistentvolumeclaims	pvc
persistentvolumes	pv
`pods`	`po`
podsecuritypolicies	psp
podtemplates
replicasets	rs
replicationcontrollers	rc
resourcequotas	quota
cronjob
secrets
serviceaccount	sa
`services`	`svc`
storageclasses
thirdpartyresources

1.2.6 格式化输出

输出方式	命令
输出 json 格式	-o json
仅打印资源名称	-o name
以纯文本格式输出	-o wide
输出 yaml 格式	-o yaml

1.3 API描述（编写配置文件时会用到）

官网传送门：k8s api文档

1.3.1 版本

alpha版本：不推荐

最新且不稳定的版本

包含 alpha 名称的版本（例如v1alpha1）。
该软件可能包含错误。启用一个功能可能会导致 bug。默认情况下，功能可能会被禁用。
随时可能会丢弃对该功能的支持，恕不另行通知。
API 可能在以后的软件版本中以不兼容的方式更改，恕不另行通知。
该软件建议仅在短期测试集群中使用，因为错误的风险增加和缺乏长期支持。

beta版本

包含 beta 名称的版本（例如 v2beta3）。
该软件经过很好的测试。启用功能被认为是安全的。默认情况下功能是开启的。
细节可能会改变，但功能在后续版本不会被删除
对象的模式或语义在随后的 beta 版本或 Stable 版本中可能以不兼容的方式发生变化。如果这种情况发生时，官方会提供迁移操作指南。这可能需要删除、编辑和重新创建API对象。
该版本在后续可能会更改一些不兼容地方，所以建议用于非关键业务，如果你有多个可以独立升级的集群，你也可以放宽此限制。
大家使用过的 Beta 版本后，可以多给社区反馈，如果此版本在后续更新后将不会有太大变化。

stable版本: 推荐使用

该版本名称命名方式：vX 这里 X 是一个整数。
Stable 版本的功能特性，将出现在后续发布的软件版本中。

1.3.2 访问控制

1.认证
2.授权

1.3.3 废弃api说明

英文文档：k8s官网废弃api说明
中文文档： k8s官网废弃api说明

2. 深入pod

官网传送门 pod yaml配置文件
pod资源描述：

2.1. Pod配置文件

deploy与service删除

操作	命令	描述
查看deploy	kubectl get deploy
删除deploy	kubectl delete deploy nginx	删除后pod也会被删除
查看services	kubectl get svc
删除services	kubectl delete svc nginx
创建po	kubectl create -f nginx-demo.yaml	通过yaml文件创建po

Pod资源清单：k8s Pod常用资源清单

官网Pod配置文件模版

apiVersion: v1 	# api文档版本
kind: Pod  	# 资源对象类型，也可以配置为Deployment/Statefulset这一类对象
metadata:	# pod相关的元数据，用于描述pod的数据
  name: memory-demo		#pod名称
  namespace: mem-example	# 命名空间
  labels:  	# 定义pod的标签,label的kv都是自定义
  	type: app	# 自定义labe标签，名字为type，值为app
  	version: v1.14 	# 自定义labe标签，名字为version，值为v1.14
  	
spec:	#期望pod安装整理的描述进行创建
  containers:	#对于pod中的容器描述
  - name: memory-demo-ctr	# 容器的名字
    image: polinux/stress	# 容器的镜像
    imagePullPolicy: ifNotPresent # 镜像拉取策略 有3中；见上述文件描述
    resources:
      requests:	 # 最少需要多少资源
        memory: "100Mi"
      limits:	 # 最多需要多少资源
        memory: "200Mi"
    command: ["stress"]	# 指定容器启动时 执行的命令
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]	# 定义启动时的参数

nginx pod例子1 ↓

apiVersion: v1 # api 文档版本
kind: Pod  # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-demo # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露什么端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: '-Xms128m -Xmx128m' # 环境变量的值
    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制 cpu 最少使用 0.1 个核心
        memory: 128Mi # 限制内存最少使用 128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制 cpu 最多使用 0.2 个核心
        memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

2.2. 探针

2.2.1 类型

StartupProbe

k8s 1.16 版本新增的探针，用于判断应用程序是否已经启动了。

当配置了 startupProbe 后，会先禁用其他探针，直到 startupProbe 成功后，其他探针才会继续。

作用：由于有时候不能准确预估应用一定是多长时间启动成功，因此配置另外两种方式不方便配置初始化时长来检测，
而配置了 statupProbe 后，只有在应用启动成功了，才会执行另外两种探针，可以更加方便的结合使用另外两种探针使用。

startupProbe:
  httpGet:
    path: /api/startup
    port: 80

LivenessProbe

用于探测容器中的应用是否运行，如果探测失败，kubelet 会根据配置的重启策略进行重启，
若没有配置，默认就认为容器启动成功，不会执行重启策略。

livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 60
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5

readlinessProbe

用于探测容器内的程序是否健康，它的返回值如果返回 success，
那么就认为该容器已经完全启动，并且该容器是可以接收外部流量的。

readinessProbe:
  failureThreshold: 3 # 错误次数
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP
  periodSeconds: 10 # 间隔时间
  successThreshold: 1
  timeoutSeconds: 1

2.2. 探针方式

ExecAction

在容器内部执行一个命令，如果返回值为 0，则任务容器时健康的。

livenessProbe:
  exec:
    command:
      - cat
      - /health

TCPSocketAction

通过 tcp 连接监测容器内端口是否开放，如果开放则证明该容器健康

livenessProbe:
 tcpSocket:
   port: 80

HttpGetAction

生产环境用的较多的方式，发送 HTTP 请求到容器内的应用程序，如果接口返回的状态码在 200~400 之间，则认为容器健康。

livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
    httpHeaders:
      - name: xxx
        value: xxx

2.3. 参数配置

initialDelaySeconds: 60 # 初始化时间
timeoutSeconds: 2 # 超时时间
periodSeconds: 5 # 监测间隔时间
successThreshold: 1 # 检查 1 次成功就表示成功
failureThreshold: 2 # 监测失败 2 次就表示失败

2.4. 探针的使用

1.StartupProbe 启动探针使用

# 查看deploy 
[root@k8s-master ~]# kubectl get deploy -n kube-system
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
calico-kube-controllers   1/1     1            1           6d22h
coredns                   2/2     2            2           7d23h

# 编辑deploy 
[root@k8s-master ~]# kubectl edit deploy -n kube-system coredns

# 编辑po:不允许修改po的文件
[root@k8s-master ~]# kubectl edit po -n kube-system coredns

# 删除po:
[root@k8s-master ~]# kubectl delete po nginx-demo

eg:nginx练习startupProb


apiVersion: v1 # api 文档版本
kind: Pod  # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-po # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    startupProbe:
      #httpGet:  #探测方式 基于http请求
       # path: /index.html     #http请求路径
       # port: 80 #http请求端口
      #tcpSocket:  #探测方式 基于tcp socket请求
        #port: 80 #http请求端口
      exec:
        command:
        - sh
        - -c
        - "echo 'success'"
      failureThreshold: 5   # 失败5次才算真正失败
      periodSeconds: 10     # 间隔检测时间
      successThreshold: 1   # 多少次检测成功为成功
      timeoutSeconds: 5 #请求超时时间
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露什么端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: '-Xms128m -Xmx128m' # 环境变量的值
    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制 cpu 最少使用 0.1 个核心
        memory: 128Mi # 限制内存最少使用 128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制 cpu 最多使用 0.2 个核心
        memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

2.liveness 是否存活探针的使用
eg:nginx练习LivenessProbe


apiVersion: v1 # api 文档版本
kind: Pod  # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-po-l # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    startupProbe:
      #httpGet:  #探测方式 基于http请求
       # path: /index.html     #http请求路径
       # port: 80 #http请求端口
      #tcpSocket:  #探测方式 基于tcp socket请求
        #port: 80 #http请求端口
      exec:
        command:
        - sh
        - -c
        - "echo 'success'"
      failureThreshold: 5   # 失败5次才算真正失败
      periodSeconds: 10     # 间隔检测时间
      successThreshold: 1   # 多少次检测成功为成功
      timeoutSeconds: 5 #请求超时时间
    livenessProbe:
      httpGet:  #探测方式 基于http请求
        path: /index.html     #http请求路径
        port: 80 #http请求端口
      #tcpSocket:  #探测方式 基于tcp socket请求
        #port: 80 #http请求端口
      failureThreshold: 5   # 失败5次才算真正失败
      periodSeconds: 10     # 间隔检测时间
      successThreshold: 1   # 多少次检测成功为成功
      timeoutSeconds: 5 #请求超时时间
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露什么端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: '-Xms128m -Xmx128m' # 环境变量的值
    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制 cpu 最少使用 0.1 个核心
        memory: 128Mi # 限制内存最少使用 128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制 cpu 最多使用 0.2 个核心
        memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

3.Readiness 就绪探针的使用
eg:nginx练习readinessProbe

apiVersion: v1 # api 文档版本
kind: Pod  # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-po-l # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    startupProbe:
      #httpGet:  #探测方式 基于http请求
       # path: /index.html     #http请求路径
       # port: 80 #http请求端口
      #tcpSocket:  #探测方式 基于tcp socket请求
        #port: 80 #http请求端口
      exec:
        command:
        - sh
        - -c
        - "echo 'success'"
      failureThreshold: 5   # 失败5次才算真正失败
      periodSeconds: 10     # 间隔检测时间
      successThreshold: 1   # 多少次检测成功为成功
      timeoutSeconds: 5 #请求超时时间
    readinessProbe:
      httpGet:  #探测方式 基于http请求
        path: /index.html     #http请求路径
        port: 80 #http请求端口
      #tcpSocket:  #探测方式 基于tcp socket请求
        #port: 80 #http请求端口
      failureThreshold: 5   # 失败5次才算真正失败
      periodSeconds: 10     # 间隔检测时间
      successThreshold: 1   # 多少次检测成功为成功
      timeoutSeconds: 5 #请求超时时间
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露什么端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: '-Xms128m -Xmx128m' # 环境变量的值
    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制 cpu 最少使用 0.1 个核心
        memory: 128Mi # 限制内存最少使用 128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制 cpu 最多使用 0.2 个核心
        memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

2.3. 生命周期

描述：

lifecycle:
  postStart: # 容创建完成后执行的动作，不能保证该操作一定在容器的 command 之前执行，一般不使用
    exec: # 可以是 exec / httpGet / tcpSocket
      command:
        - sh
        - -c
        - 'mkdir /data'
  preStop: # 在容器停止前执行的动作
    httpGet: # 发送一个 http 请求
      path: /
      port: 80
    exec: # 执行一个命令
      command:
        - sh
        - -c
        - sleep 9

在这里插入图片描述
1.pod退出流程：
删除操作如下

Endpoint删除pod的ip地址
pod变成terminating状态：

变为删除中的状态后，会给 pod 一个宽限期，让 pod 去执行一些清理或销毁操作。
配置参数：
# 作用与 pod 中的所有容器
terminationGracePeriodSeconds: 30
containers:
- xxx

执行preStop指令

2.preStop应用
描述：

如果应用销毁操作耗时需要比较长，可以在 preStop 按照如下方式进行配置

preStop:
  exec:
    command:
      - sh
      - -c
      - 'sleep 20; kill pgrep java'

但是需要注意，由于 k8s 默认给 pod 的停止宽限时间为 30s，如果我们停止操作会超过 30s 时，
不要光设置 sleep 50，还要将 terminationGracePeriodSeconds: 30 也更新成更长的时间，
否则 k8s 最多只会在这个时间的基础上再宽限几秒，不会真正等待 50s

注册中心下线
数据清理
数据销毁

3. 资源调度

3.1 Label和Selector

标签（Label）
配置文件：在各类资源的 metadata.labels 中进行配置

kubectl方式：

#1.临时创建：
kubectl label po <资源名称> app=hello
#2.修改已经存在的标签：
kubectl label po <资源名称> app=hello2 --overwrite
#3.查看label：
#3.1 selector 按照 label 单值查找节点: 
kubectl get po -A -l app=hello
#3.2 查看所有节点的 labels: 
kubectl get po --show-labels

选择器（Selector）
配置文件：在各对象的配置 spec.selector 或其他可以写 selector 的属性中编写
kubectl方式：

# 匹配单个值，查找 app=hello 的 pod
kubectl get po -A -l app=hello

# 匹配多个值
kubectl get po -A -l 'k8s-app in (metrics-server, kubernetes-dashboard)'
或 

# 查找 version!=1 and app=nginx 的 pod 信息
kubectl get po -l version!=1,app=nginx

# 不等值 + 语句
kubectl get po -A -l version!=1,'app in (busybox, nginx)'

3.2 Deployment

3.2.1 功能

1.创建

创建一个 deployment
kubectl create deploy nginx-deploy --image=nginx:1.7.9

或执行
kubectl create -f xxx.yaml --record
--record 会在 annotation 中记录当前命令创建或升级了资源，后续可以查看做过哪些变动操作。

查看部署信息
kubectl get deployments

查看 rs
kubectl get rs

查看 pod 以及展示标签，可以看到是关联的那个 rs
kubectl get pods --show-labels

2.滚动更新

只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作

修改 nginx 版本号
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

或者通过 kubectl edit deployment/nginx-deployment 进行修改

查看滚动更新的过程
kubectl rollout status deploy <deployment_name>

查看部署描述，最后展示发生的事件列表也可以看到滚动更新过程
kubectl describe deploy <deployment_name>

通过 kubectl get deployments 获取部署信息，UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目

通过 kubectl get rs 可以看到增加了一个新的 rs

通过 kubectl get pods 可以看到所有 pod 关联的 rs 变成了新的

多个滚动更新并行

假设当前有 5 个 nginx:1.7.9 版本，你想将版本更新为 1.9.1，当更新成功第三个以后，
你马上又将期望更新的版本改为 1.9.2，那么此时会立马删除之前的三个，并且立马开启更新 1.9.2 的任务

3.回滚 :

有时候你可能想回退一个Deployment，例如，当Deployment不稳定时，比如一直crash looping。

默认情况下，kubernetes会在系统中保存前两次的Deployment的rollout历史记录，以便你可以随时会退（你可以修改revision history limit来更改保存的revision数）。


案例：
更新 deployment 时参数不小心写错，如 nginx:1.9.1 写成了 nginx:1.91
kubectl set image deployment/nginx-deploy nginx=nginx:1.91

监控滚动升级状态，由于镜像名称错误，下载镜像失败，因此更新过程会卡住
kubectl rollout status deployments nginx-deploy

结束监听后，获取 rs 信息，我们可以看到新增的 rs 副本数是 2 个
kubectl get rs

通过 kubectl get pods 获取 pods 信息，我们可以看到关联到新的 rs 的 pod，状态处于 ImagePullBackOff 状态

为了修复这个问题，我们需要找到需要回退的 revision 进行回退
通过 kubectl rollout history deployment/nginx-deploy 可以获取 revison 的列表

通过 kubectl rollout history deployment/nginx-deploy --revision=2 可以查看详细信息

确认要回退的版本后，可以通过 kubectl rollout undo deployment/nginx-deploy 可以回退到上一个版本

也可以回退到指定的 revision
kubectl rollout undo deployment/nginx-deploy --to-revision=2

再次通过 kubectl get deployment 和 kubectl describe deployment 可以看到，我们的版本已经回退到对应的 revison 上了

可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison，如果设置为 0，则不允许 deployment 回退了。

4.扩缩容

通过 kube scale 命令可以进行自动扩容/缩容，以及通过 kube edit 编辑 replcas 也可以实现扩容/缩容

扩容与缩容只是直接创建副本数，没有更新 pod template 因此不会创建新的 rs

5.暂停与恢复

由于每次对 pod template 中的信息发生修改后，都会触发更新 deployment 操作，那么此时如果频繁修改信息，就会产生多次更新，而实际上只需要执行最后一次更新即可，当出现此类情况时我们就可以暂停 deployment 的 rollout

通过 kubectl rollout pause deployment <name> 就可以实现暂停，直到你下次恢复后才会继续进行滚动更新

尝试对容器进行修改，然后查看是否发生更新操作了
kubectl set image deploy <name> nginx=nginx:1.17.9
kubectl get po 

通过以上操作可以看到实际并没有发生修改，此时我们再次进行修改一些属性，如限制 nginx 容器的最大cpu为 0.2 核，最大内存为 128M，最小内存为 64M，最小 cpu 为 0.1 核
kubectl set resources deploy <deploy_name> -c <container_name> --limits=cpu=200m,memory=128Mi --requests=cpu100m,memory=64Mi

通过格式化输出 kubectl get deploy <name> -oyaml，可以看到配置确实发生了修改，再通过 kubectl get po 可以看到 pod 没有被更新

那么此时我们再恢复 rollout，通过命令 kubectl rollout deploy <name>

恢复后，我们再次查看 rs 和 po 信息，我们可以看到就开始进行滚动更新操作了
kubectl get rs
kubectl get po

3.2.2 配置文件

获取某个deploy的yaml配置文件

 kubectl get deploy nginx-deploy -o yaml

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key: value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: default # 所在的命名空间
spec:
  replicas: 1 # 期望副本数
  revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
  selector: # 选择器，用于找到匹配的 RS
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时，更新的个数最多可以超过期望副本数的个数/比例
      maxUnavailable: 25% # 进行滚动更新时，最大不可用比例更新比例，表示在所有副本数中，最多可以有多少个不更新成功
    type: RollingUpdate # 更新类型，采用滚动更新
  template: # pod 模板
    metadata: # pod 的元信息
      labels: # pod 的标签
        app: nginx-deploy
    spec: # pod 期望信息
      containers: # pod 的容器
      - image: nginx:1.7.9 # 镜像
        imagePullPolicy: IfNotPresent # 拉取策略
        name: nginx # 容器名称
      restartPolicy: Always # 重启策略
      terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间

3.3 StatefulSet: 有状态pod

3.3.1 功能

1.创建

kubectl create -f web.yaml

# 查看 service 和 statefulset => sts
kubectl get service nginx
kubectl get statefulset web

# 查看 PVC 信息
kubectl get pvc

# 查看创建的 pod，这些 pod 是有序的
kubectl get pods -l app=nginx

# 查看这些 pod 的 dns
# 运行一个 pod，基础镜像为 busybox 工具包，利用里面的 nslookup 可以看到 dns 信息
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
nslookup web-0.nginx

2.扩缩容

# 扩容
$ kubectl scale statefulset web --replicas=5

# 缩容
$ kubectl patch statefulset web -p '{"spec":{"replicas":3}}'

3.镜像更新

# 镜像更新（目前还不支持直接更新 image，需要 patch 来间接实现）

kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.9.1"}]'

3.1 RollingUpdate 及灰度发布

RollingUpdate

StatefulSet  也可以采用滚动更新策略，同样是修改 pod template 属性后会触发更新，
但是由于 pod 是有序的，在 StatefulSet 中更新时是基于 pod 的顺序倒序更新的

灰度发布

利用滚动更新中的 partition 属性，可以实现简易的灰度发布的效果

例如我们有 5 个 pod，如果当前 partition 设置为 3，那么此时滚动更新时，只会更新那些 序号 >= 3 的 pod

利用该机制，我们可以通过控制 partition 的值，来决定只更新其中一部分 pod，确认没有问题后再主键增大更新的 pod 数量，最终实现全部 pod 更新

3.2 OnDelete

只有在 pod 被删除时会进行更新操作

4.删除

# 删除 StatefulSet 和 Headless Service
# 级联删除：删除 statefulset 时会同时删除 pods
kubectl delete statefulset web
# 非级联删除：删除 statefulset 时不会删除 pods，删除 sts 后，pods 就没人管了，此时再删除 pod 不会重建的
kubectl delete sts web --cascade=false
# 删除 service
kubectl delete service nginx

5.删除pvc

# StatefulSet删除后PVC还会保留着，数据不再使用的话也需要删除
$ kubectl delete pvc www-web-0 www-web-1

3.3.2 配置文件

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

3.4 DaemonSet

3.4.1 配置文件

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  template:
    metadata:
      labels:
        app: logging
        id: fluentd
      name: fluentd
    spec:
      containers:
      - name: fluentd-es
        image: agilestacks/fluentd-elasticsearch:v1.3.0
        env:
         - name: FLUENTD_ARGS
           value: -qq
        volumeMounts:
         - name: containers
           mountPath: /var/lib/docker/containers
         - name: varlog
           mountPath: /varlog
      volumes:
         - hostPath:
             path: /var/lib/docker/containers
           name: containers
         - hostPath:
             path: /var/log
           name: varlog

3.4.2 指定Node节点

DaemonSet 会忽略 Node 的 unschedulable 状态，有两种方式来指定 Pod 只运行在指定的 Node 节点上：
nodeSelector：只调度到匹配指定 label 的 Node 上
nodeAffinity：功能更丰富的 Node 选择器，比如支持集合操作
podAffinity：调度到满足条件的 Pod 所在的 Node 上

1.nodeSelector

先为 Node 打上标签
kubectl label nodes k8s-node1 svc_type=microsvc
然后再 daemonset 配置中设置 nodeSelector

spec:
  template:
    spec:
      nodeSelector:
        svc_type: microsvc

2.nodeAffinity

nodeAffinity 目前支持两种：requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution，分别代表必须满足条件和优选条件。

比如下面的例子代表调度到包含标签 wolfcode.cn/framework-name 并且值为 spring 或 springboot 的 Node 上，并且优选还带有标签 another-node-label-key=another-node-label-value 的Node。

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: wolfcode.cn/framework-name
            operator: In
            values:
            - spring
            - springboot
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: pauseyyf/pause

3.podAffinity

podAffinity 基于 Pod 的标签来选择 Node，仅调度到满足条件Pod 所在的 Node 上，支持 podAffinity 和 podAntiAffinity。这个功能比较绕，以下面的例子为例：
如果一个 “Node 所在空间中包含至少一个带有 auth=oauth2 标签且运行中的 Pod”，那么可以调度到该 Node
不调度到 “包含至少一个带有 auth=jwt 标签且运行中 Pod”的 Node 上

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: auth
            operator: In
            values:
            - oauth2
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: auth
              operator: In
              values:
              - jwt
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: pauseyyf/pause

3.4.3 滚动更新

不建议使用 RollingUpdate，建议使用 OnDelete 模式，这样避免频繁更新 ds

3.5 HPA 自动扩/缩容

3.5.1 开启指标服务

# 下载 metrics-server 组件配置文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml

# 修改镜像地址为国内的地址
sed -i 's/k8s.gcr.io\/metrics-server/registry.cn-hangzhou.aliyuncs.com\/google_containers/g' metrics-server-components.yaml

# 修改容器的 tls 配置，不验证 tls，在 containers 的 args 参数中增加 --kubelet-insecure-tls 参数

# 安装组件
kubectl apply -f metrics-server-components.yaml

# 查看 pod 状态
kubectl get pods --all-namespaces | grep metrics

3.5.2 CPU、内存指标监控

实现 cpu 或内存的监控，首先有个前提条件是该对象必须配置了 resources.requests.cpu 或 resources.requests.memory 才可以，可以配置当 cpu/memory 达到上述配置的百分比后进行扩容或缩容

创建一个 HPA：
1.先准备一个好一个有做资源限制的 deployment
2.执行命令 kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5
3.通过 kubectl get hpa 可以获取 HPA 信息

测试：找到对应服务的 service，编写循环测试脚本提升内存与 cpu 负载
while true; do wget -q -O- http://<ip:port> > /dev/null ; done

可以通过多台机器执行上述命令，增加负载，当超过负载后可以查看 pods 的扩容情况 kubectl get pods

查看 pods 资源使用情况
kubectl top pods

扩容测试完成后，再关闭循环执行的指令，让 cpu 占用率降下来，然后过 5 分钟后查看自动缩容情况

3.5.3 自定义matrics

控制管理器开启–horizontal-pod-autoscaler-use-rest-clients
控制管理器的–apiserver指向API Server Aggregator
在API Server Aggregator中注册自定义的metrics API

4. 服务发布

4.1 Service：东西流量

负责东西流量（同层级/内部服务网络通信）的通信

1.Service 定义
配置文件↓

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx-svc
spec:
  ports:
  - name: http # service 端口配置的名称
    protocol: TCP # 端口绑定的协议，支持 TCP、UDP、SCTP，默认为 TCP
    port: 80 # service 自己的端口
    targetPort: 9527 # 目标 pod 的端口
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  selector: # 选中当前 service 匹配哪些 pod，对哪些 pod 的东西流量进行代理
    app: nginx

1.1 命令操作

# 创建 service
kubectl create -f nginx-svc.yaml

# 查看 service 信息，通过 service 的 cluster ip 进行访问
kubectl get svc 

# 查看 pod 信息，通过 pod 的 ip 进行访问
kubectl get po -owide

# 创建其他 pod 通过 service name 进行访问（推荐）
kubectl exec -it busybox -- sh
curl http://nginx-svc

# 默认在当前 namespace 中访问，如果需要跨 namespace 访问 pod，则在 service name 后面加上 .<namespace> 即可
curl http://nginx-svc.default

1.2 Endpoint

2.代理k8s外部服务
实现方式：

1.编写 service 配置文件时，不指定 selector 属性
2.自己创建 endpoint

endpoint配置：

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: wolfcode-svc-external # 与 service 一致
  name: wolfcode-svc-external # 与 service 一致
  namespace: default # 与 service 一致
subsets:
- addresses:
  - ip: <target ip> # 目标 ip 地址
  ports: # 与 service 一致
  - name: http
    port: 80
    protocol: TCP

特点：

1.各环境访问名称统一
2.访问 k8s 集群外的其他服务
3.项目迁移

3.反向代理外部域名
配置文件：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: wolfcode-external-domain
  name: wolfcode-external-domain
spec:
  type: ExternalName
  externalName: www.wolfcode.cn

4.常用类型
4.1 ClusterIP

只能在集群内部使用，不配置类型的话默认就是 ClusterIP

4.2 ExternalName

返回定义的 CNAME 别名，可以配置为域名

4.3 NodePort

会在所有安装了 kube-proxy 的节点都绑定一个端口，此端口可以代理至对应的 Pod，集群外部可以使用任意节点 ip + NodePort 的端口号访问到集群中对应 Pod 中的服务。
当类型设置为 NodePort 后，可以在 ports 配置中增加 nodePort 配置指定端口，需要在下方的端口范围内，如果不指定会随机指定端口
端口范围：30000~32767
端口范围配置在 /usr/lib/systemd/system/kube-apiserver.service 文件中

4.4 LoadBalancer

使用云服务商（阿里云、腾讯云等）提供的负载均衡器服务

4.2 Ingress：南北流量

Ingress 大家可以理解为也是一种 LB 的抽象，它的实现也是支持 nginx、haproxy 等负载均衡服务的

1.安装 ingress-nginx

https://kubernetes.github.io/ingress-nginx/deploy/#using-helm

1.1 添加 helm 仓库

# 添加仓库
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

# 查看仓库列表
helm repo list

# 搜索 ingress-nginx
helm search repo ingress-nginx

1.2 下载包

# 下载安装包
helm pull ingress-nginx/ingress-nginx

1.3 配置参数

# 将下载好的安装包解压
tar xf ingress-nginx-xxx.tgz

# 解压后，进入解压完成的目录
cd ingress-nginx

# 修改 values.yaml
镜像地址：修改为国内镜像
registry: registry.cn-hangzhou.aliyuncs.com
image: google_containers/nginx-ingress-controller
image: google_containers/kube-webhook-certgen
tag: v1.3.0

hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet

修改部署配置的 kind: DaemonSet
nodeSelector:
  ingress: "true" # 增加选择器，如果 node 上有 ingress=true 就部署
将 admissionWebhooks.enabled 修改为 false
将 service 中的 type 由 LoadBalancer 修改为 ClusterIP，如果服务器是云平台才用 LoadBalancer

1.4 创建 Namespace

# 为 ingress 专门创建一个 namespace
kubectl create ns ingress-nginx

1.5 安装 ingress

# 为需要部署 ingress 的节点上加标签
kubectl label node k8s-node1 ingress=true

# 安装 ingress-nginx
helm install ingress-nginx ./ingress-nginx -n ingress-nginx

2.基本使用
2.1 创建一个Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress # 资源类型为 Ingress
metadata:
  name: wolfcode-nginx-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules: # ingress 规则配置，可以配置多个
  - host: k8s.wolfcode.cn # 域名配置，可以使用通配符 *
    http:
      paths: # 相当于 nginx 的 location 配置，可以配置多个
      - pathType: Prefix # 路径类型，按照路径类型进行匹配 ImplementationSpecific 需要指定 IngressClass，具体匹配规则以 IngressClass 中的规则为准。Exact：精确匹配，URL需要与path完全匹配上，且区分大小写的。Prefix：以 / 作为分隔符来进行前缀匹配
        backend:
          service: 
            name: nginx-svc # 代理到哪个 service
            port: 
              number: 80 # service 的端口
        path: /api # 等价于 nginx 中的 location 的路径前缀匹配

2.2 多域名配置

apiVersion: networking.k8s.io/v1
kind: Ingress # 资源类型为 Ingress
metadata:
  name: wolfcode-nginx-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules: # ingress 规则配置，可以配置多个
  - host: k8s.wolfcode.cn # 域名配置，可以使用通配符 *
    http:
      paths: # 相当于 nginx 的 location 配置，可以配置多个
      - pathType: Prefix # 路径类型，按照路径类型进行匹配 ImplementationSpecific 需要指定 IngressClass，具体匹配规则以 IngressClass 中的规则为准。Exact：精确匹配，URL需要与path完全匹配上，且区分大小写的。Prefix：以 / 作为分隔符来进行前缀匹配
        backend:
          service: 
            name: nginx-svc # 代理到哪个 service
            port: 
              number: 80 # service 的端口
        path: /api # 等价于 nginx 中的 location 的路径前缀匹配
      - pathType: Exec # 路径类型，按照路径类型进行匹配 ImplementationSpecific 需要指定 IngressClass，具体匹配规则以 IngressClass 中的规则为准。Exact：精确匹配>，URL需要与path完全匹配上，且区分大小写的。Prefix：以 / 作为分隔符来进行前缀匹配
        backend:
          service:
            name: nginx-svc # 代理到哪个 service
            port:
              number: 80 # service 的端口
        path: /
  - host: api.wolfcode.cn # 域名配置，可以使用通配符 *
    http:
      paths: # 相当于 nginx 的 location 配置，可以配置多个
      - pathType: Prefix # 路径类型，按照路径类型进行匹配 ImplementationSpecific 需要指定 IngressClass，具体匹配规则以 IngressClass 中的规则为准。Exact：精确匹配>，URL需要与path完全匹配上，且区分大小写的。Prefix：以 / 作为分隔符来进行前缀匹配
        backend:
          service:
            name: nginx-svc # 代理到哪个 service
            port:
              number: 80 # service 的端口
        path: /

5. 配置与存储

5.1 配置管理

5.1.1 ConfigMap

一般用于去存储 Pod 中应用所需的一些配置信息，或者环境变量，将配置于 Pod 分开，避免应为修改配置导致还需要重新构建镜像与容器。

1.创建

使用 kubectl create configmap -h 查看示例，构建 configmap 对象

2.使用ConfigMap

5.1.2 加密数据配置Secret

与 ConfigMap 类似，用于存储配置信息，但是主要用于存储敏感信息、需要加密的信息，Secret 可以提供数据加密、解密功能。

在创建 Secret 时，要注意如果要加密的字符中，包含了有特殊字符，需要使用转义符转移，例如 $ 转移后为 $，也可以对特殊字符使用单引号描述，这样就不需要转移例如 1$289*-! 转换为 ‘1$289*-!’

5.1.3 SubPath的使用

使用 ConfigMap 或 Secret 挂载到目录的时候，会将容器中源目录给覆盖掉，此时我们可能只想覆盖目录中的某一个文件，但是这样的操作会覆盖整个文件，因此需要使用到 SubPath

配置方式：

1.定义 volumes 时需要增加 items 属性，配置 key 和 path，且 path 的值不能从 / 开始
2.在容器内的 volumeMounts 中增加 subPath 属性，该值与 volumes 中 items.path 的值相同

containers:
  ......
  volumeMounts:
  - mountPath: /etc/nginx/nginx.conf # 挂载到哪里
    name: config-volume # 使用哪个 configmap 或 secret
    subPath: etc/nginx/nginx.conf # 与 volumes.[0].items.path 相同
volumes:
- configMap:
  name: nginx-conf # configMap 名字
  items: # subPath 配置
    key: nginx.conf # configMap 中的文件名
    path: etc/nginx/nginx.conf # subPath 路径

5.1.4 配置的热更新

我们通常会将项目的配置文件作为 configmap 然后挂载到 pod，那么如果更新 configmap 中的配置，会不会更新到 pod 中呢？

这得分成几种情况：
默认方式：会更新，更新周期是更新时间 + 缓存时间
subPath：不会更新
变量形式：如果 pod 中的一个变量是从 configmap 或 secret 中得到，同样也是不会更新的

对于 subPath 的方式，我们可以取消 subPath 的使用，将配置文件挂载到一个不存在的目录，避免目录的覆盖，然后再利用软连接的形式，将该文件链接到目标位置

但是如果目标位置原本就有文件，可能无法创建软链接，此时可以基于前面讲过的 postStart 操作执行删除命令，将默认的吻技安删除即可

1.通过 edit 命令直接修改 configmap
2.通过 replace 替换

由于 configmap 我们创建通常都是基于文件创建，并不会编写 yaml 配置文件，因此修改时我们也是直接修改配置文件，而 replace 是没有 --from-file 参数的，因此无法实现基于源配置文件的替换，此时我们可以利用下方的命令实现

该命令的重点在于 --dry-run 参数，该参数的意思打印 yaml 文件，但不会将该文件发送给 apiserver，再结合 -oyaml 输出 yaml 文件就可以得到一个配置好但是没有发给 apiserver 的文件，然后再结合 replace 监听控制台输出得到 yaml 数据即可实现替换
kubectl create cm --from-file=nginx.conf --dry-run -oyaml | kubectl replace -f-

5.1.5 不可变的Secret和ConfigMap

对于一些敏感服务的配置文件，在线上有时是不允许修改的，此时在配置 configmap 时可以设置 immutable: true 来禁止修改

5.2 持久化存储

5.2.1 Volumes

1.HostPath

将节点上的文件或目录挂载到 Pod 上，此时该目录会变成持久化存储目录，即使 Pod 被删除后重启，也可以重新加载到该目录，该目录下的文件不会丢失

配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: nginx-volume
    volumeMounts:
    - mountPath: /test-pd # 挂载到容器的哪个目录
      name: test-volume # 挂载哪个 volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data # 节点中的目录
      type: Directory # 检查类型，在挂载前对挂载目录做什么检查操作，有多种选项，默认为空字符串，不做任何检查

配置文件说明：

类型：
空字符串：默认类型，不做任何检查
DirectoryOrCreate：如果给定的 path 不存在，就创建一个 755 的空目录
Directory：这个目录必须存在
FileOrCreate：如果给定的文件不存在，则创建一个空文件，权限为 644
File：这个文件必须存在
Socket：UNIX 套接字，必须存在
CharDevice：字符设备，必须存在
BlockDevice：块设备，必须存在

2.EmptyDir

EmptyDir 主要用于一个 Pod 中不同的 Container 共享数据使用的，由于只是在 Pod 内部使用，因此与其他 volume 比较大的区别是，当 Pod 如果被删除了，那么 emptyDir 也会被删除。

存储介质可以是任意类型，如 SSD、磁盘或网络存储。可以将 emptyDir.medium 设置为 Memory 让 k8s 使用 tmpfs（内存支持文件系统），速度比较快，但是重启 tmpfs 节点时，数据会被清除，且设置的大小会计入到 Container 的内存限制中。

配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: nginx-emptydir
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

5.2.2 NFS 挂载

nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。

1.安装NFS

# 安装 nfs：所有节点操作
yum install nfs-utils -y

# 启动 nfs：所有节点操作
systemctl start nfs-server

# 查看 nfs 版本：所有节点操作
cat /proc/fs/nfsd/versions

# 创建共享目录：主节点操作
mkdir -p /data/nfs
cd /data/nfs
mkdir rw
mkdir ro

# 设置共享目录 export：主节点操作
vim /etc/exports
/data/nfs/rw 192.168.190.0/24(rw,sync,no_subtree_check,no_root_squash)
/data/nfs/ro 192.168.190.0/24(ro,sync,no_subtree_check,no_root_squash)

# 重新加载：主节点操作
exportfs -f
systemctl reload nfs-server

# 到其他测试节点安装 nfs-utils 并加载测试
mkdir -p /mnt/nfs/rw
mount -t nfs 192.168.190.129:/data/nfs/rw /mnt/nfs/rw

2.配置文件

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /my-nfs-data
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: my-nfs-server.example.com # 网络存储服务地址
      path: /my-nfs-volume # 网络存储路径
      readOnly: true # 是否只读

5.2.3 PV 与 PVC

1.生命周期
1.1 构建
1.1.1 静态构建

集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息，并且对集群用户可用（可见）。PV 卷对象存在于 Kubernetes API 中，可供用户消费（使用）。

1.1.2 动态构建

如果集群中已经有的 PV 无法满足 PVC 的需求，那么集群会根据 PVC 自动构建一个 PV，该操作是通过 StorageClass 实现的。

想要实现这个操作，前提是 PVC 必须设置 StorageClass，否则会无法动态构建该 PV，可以通过启用 DefaultStorageClass 来实现 PV 的构建。

1.2 绑定

当用户创建一个 PVC 对象后，主节点会监测新的 PVC 对象，并且寻找与之匹配的 PV 卷，找到 PV 卷后将二者绑定在一起。

如果找不到对应的 PV，则需要看 PVC 是否设置 StorageClass 来决定是否动态创建 PV，若没有配置，PVC 就会一致处于未绑定状态，直到有与之匹配的 PV 后才会申领绑定关系。

1.3 使用

Pod 将 PVC 当作存储卷来使用，集群会通过 PVC 找到绑定的 PV，并为 Pod 挂载该卷。

Pod 一旦使用 PVC 绑定 PV 后，为了保护数据，避免数据丢失问题，PV 对象会受到保护，在系统中无法被删除。

1.4 回收策略

当用户不再使用其存储卷时，他们可以从 API 中将 PVC 对象删除，从而允许该资源被回收再利用。PersistentVolume 对象的回收策略告诉集群，当其被从申领中释放时如何处理该数据卷。目前，数据卷可以被 Retained（保留）、Recycled（回收）或 Deleted（删除）。

1.4.1 保留（Retain）

回收策略 Retain 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象被删除时，PersistentVolume 卷仍然存在，对应的数据卷被视为"已释放（released）"。由于卷上仍然存在这前一申领人的数据，该卷还不能用于其他申领。管理员可以通过下面的步骤来手动回收该卷：
1.删除 PersistentVolume 对象。与之相关的、位于外部基础设施中的存储资产（例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）在 PV 删除之后仍然存在。
2.根据情况，手动清除所关联的存储资产上的数据。
3.手动删除所关联的存储资产。
如果你希望重用该存储资产，可以基于存储资产的定义创建新的 PersistentVolume 卷对象。

1.4.2 删除（Delete）

对于支持 Delete 回收策略的卷插件，删除动作会将 PersistentVolume 对象从 Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中移除所关联的存储资产。动态制备的卷会继承其 StorageClass 中设置的回收策略，该策略默认为 Delete。管理员需要根据用户的期望来配置 StorageClass；否则 PV 卷被创建之后必须要被编辑或者修补。

1.4.3 回收（Recycle）

警告：回收策略 Recycle 已被废弃。取而代之的建议方案是使用动态制备。

如果下层的卷插件支持，回收策略 Recycle 会在卷上执行一些基本的擦除（rm -rf /thevolume/*）操作，之后允许该卷用于新的 PVC 申领。

2.PV
2.1 状态
2.1.1 Available：空闲，未被绑定
2.1.2 Bound：已经被 PVC 绑定
2.1.3 Released：PVC 被删除，资源已回收，但是 PV 未被重新使用
2.1.4 Failed：自动回收失败

2.2 配置文件

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 5Gi # pv 的容量
  volumeMode: Filesystem # 存储类型为文件系统
  accessModes: # 访问模式：ReadWriteOnce、ReadWriteMany、ReadOnlyMany
    - ReadWriteOnce # 可被单节点独写
  persistentVolumeReclaimPolicy: Recycle # 回收策略
  storageClassName: slow # 创建 PV 的存储类名，需要与 pvc 的相同
  mountOptions: # 加载配置
    - hard
    - nfsvers=4.1
  nfs: # 连接到 nfs
    path: /data/nfs/rw/test-pv # 存储路径
    server: 192.168.113.121 # nfs 服务地址

3.PVC
3.1 Pod绑定PVC

在 pod 的挂载容器配置中，增加 pvc 挂载
containers:
  ......
  volumeMounts:
    - mountPath: /tmp/pvc
      name: nfs-pvc-test
volumes:
  - name: nfs-pvc-test
    persistentVolumeClaim:
      claimName: nfs-pvc # pvc 的名称

3.2 配置文件

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteOnce # 权限需要与对应的 pv 相同
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi # 资源可以小于 pv 的，但是不能大于，如果大于就会匹配不到 pv
  storageClassName: slow # 名字需要与对应的 pv 相同
#  selector: # 使用选择器选择对应的 pv
#    matchLabels:
#      release: "stable"
#    matchExpressions:
#      - {key: environment, operator: In, values: [dev]}

4.StorageClass

k8s 中提供了一套自动创建 PV 的机制，就是基于 StorageClass 进行的，通过 StorageClass 可以实现仅仅配置 PVC，然后交由 StorageClass 根据 PVC 的需求动态创建 PV。

4.1 制备器（Porvisioner）

每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。

4.2 NFS动态制备案例
4.2.1 nfs-provisioner

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
  labels:
    app: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 192.168.113.121
            - name: NFS_PATH
              value: /data/nfs/rw
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.113.121
            path: /data/nfs/rw

4.2.2 StorageClass 配置

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
  namespace: kube-system
provisioner: fuseim.pri/ifs # 外部制备器提供者，编写为提供者的名称
parameters:
  archiveOnDelete: "false" # 是否存档，false 表示不存档，会删除 oldPath 下面的数据，true 表示存档，会重命名路径
reclaimPolicy: Retain # 回收策略，默认为 Delete 可以配置为 Retain
volumeBindingMode: Immediate # 默认为 Immediate，表示创建 PVC 立即进行绑定，只有 azuredisk 和 AWSelasticblockstore 支持其他值

4.2.3 RBAC 配置

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
  namespace: kube-system
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: kube-system
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

4.2.4 PVC 处于 Pending 状态

在 k8s 1.20 之后，出于对性能和统一 apiserver 调用方式的初衷，移除了对 SelfLink 的支持，而默认上面指定的 provisioner 版本需要 SelfLink 功能，因此 PVC 无法进行自动制备。

4.2.4.1 配置 SelfLink

修改 apiserver 配置文件
vim /etc/kubernetes/manifests/kube-apiserver.yaml

spec:
  containers:
  - command:
    - kube-apiserver
    - --feature-gates=RemoveSelfLink=false # 新增该行
    ......

修改后重新应用该配置
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

4.2.4.2 不需要 SelfLink 的 provisioner

将 provisioner 修改为如下镜像之一即可

gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.0

registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:v4.0.0

4.2.5 PVC 测试配置

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: auto-pv-test-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 300Mi
  storageClassName: managed-nfs-storage

6. 高级调度

6.1 CronJob 计划任务

在 k8s 中周期性运行计划任务，与 linux 中的 crontab 相同
注意点：CronJob 执行的时间是 controller-manager 的时间，所以一定要确保 controller-manager 时间是准确的，另外 cronjob

1.cron 表达式：

# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）
# │ │ │ │ │                          或者是 sun，mon，tue，web，thu，fri，sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

2.配置文件

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  concurrencyPolicy: Allow # 并发调度策略：Allow 允许并发调度，Forbid：不允许并发执行，Replace：如果之前的任务还没执行完，就直接执行新的，放弃上一个任务
  failedJobsHistoryLimit: 1 # 保留多少个失败的任务
  successfulJobHistoryLimit: 3 # 保留多少个成功的任务
  suspend: false # 是否挂起任务，若为 true 则该任务不会执行
#  startingDeadlineSeconds: 30 # 间隔多长时间检测失败的任务并重新执行，时间不能小于 10
  schedule: "* * * * *" # 调度策略
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

6.2 初始化容器 InitContainer

在真正的容器启动之前，先启动 InitContainer，在初始化容器中完成真实容器所需的初始化操作，完成后再启动真实的容器。
相对于 postStart 来说，首先 InitController 能够保证一定在 EntryPoint 之前执行，而 postStart 不能，其次 postStart 更适合去执行
一些命令操作，而 InitController 实际就是一个容器，可以在其他基础容器环境下执行更复杂的初始化功能。

在 pod 创建的模板中配置 initContainers 参数：
spec:
  initContainers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    command: ["sh", "-c", "echo 'inited;' >> ~/.init"]
    name: init-test

6.3 污点和容忍

k8s 集群中可能管理着非常庞大的服务器，这些服务器可能是各种各样不同类型的，比如机房、地理位置、配置等，有些是计算型节点，有些是存储型节点，此时我们希望能更好的将 pod 调度到与之需求更匹配的节点上。
此时就需要用到污点（Taint）和容忍（Toleration），这些配置都是 key: value 类型的。

1.污点（Taint）

污点：是标注在节点上的，当我们在一个节点上打上污点以后，k8s 会认为尽量不要将 pod 调度到该节点上，除非该 pod 上面表示可以容忍该污点，且一个节点可以打多个污点，此时则需要 pod 容忍所有污点才会被调度该节点。

# 为节点打上污点
kubectl taint node k8s-master key=value:NoSchedule

# 移除污点
kubectl taint node k8s-master key=value:NoSchedule-

# 查看污点
kubectl describe no k8s-master

污点的影响：
NoSchedule：不能容忍的 pod 不能被调度到该节点，但是已经存在的节点不会被驱逐
NoExecute：不能容忍的节点会被立即清除，能容忍且没有配置 tolerationSeconds 属性，则可以一直运行，设置了 tolerationSeconds: 3600 属性，则该 pod 还能继续在该节点运行 3600 秒

1.1 NoSchedule:

如果不能容忍该污点，那么 Pod 就无法调度到该节点上

1.2 NoExecute:

如果 Pod 不能忍受这类污点，Pod 会马上被驱逐。
如果 Pod 能够忍受这类污点，但是在容忍度定义中没有指定 tolerationSeconds，则 Pod 还会一直在这个节点上运行。
如果 Pod 能够忍受这类污点，而且指定了 tolerationSeconds，则 Pod 还能在这个节点上继续运行这个指定的时间长度。

2.容忍（Toleration）

容忍：是标注在 pod 上的，当 pod 被调度时，如果没有配置容忍，则该 pod 不会被调度到有污点的节点上，只有该 pod 上标注了满足某个节点的所有污点，则会被调度到这些节点

# pod 的 spec 下面配置容忍
tolerations:
- key: "污点的 key"
  value: "污点的 value"
  offect: "NoSchedule" # 污点产生的影响
  operator: "Equal" # 表是 value 与污点的 value 要相等，也可以设置为 Exists 表示存在 key 即可，此时可以不用配置 value

2.1 Equal:

比较操作类型为 Equal，则意味着必须与污点值做匹配，key/value都必须相同，才表示能够容忍该污点

2.2 Exists:

容忍与污点的比较只比较 key，不比较 value，不关心 value 是什么东西，只要 key 存在，就表示可以容忍。

6.4 亲和力（Affinity）

6.4.1 NodeAffinity

节点亲和力：进行 pod 调度时，优先调度到符合条件的亲和力节点上

1.RequiredDuringSchedulingIgnoredDuringExecution

硬亲和力，即支持必须部署在指定的节点上，也支持必须不部署在指定的节点上

2.PreferredDuringSchedulingIgnoredDuringExecution

软亲和力：尽量部署在满足条件的节点上，或尽量不要部署在被匹配的节点上

3.应用:
3.1 匹配类型

匹配类型	说明
In	部署在满足条件的节点上
NotIn	匹配不在条件中的节点，实现节点反亲和性
Exists	只要存在 key 名字就可以，不关心值是什么
DoesNotExist	匹配指定 key 名不存在的节点，实现节点反亲和性
Gt	value 为数值，且节点上的值小于指定的条件
Lt	value 为数值，且节点上的值大于指定条件

3.2 配置模板

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity: # 亲和力配置
    nodeAffinity: # 节点亲和力
      requiredDuringSchedulingIgnoredDuringExecution: # 节点必须匹配下方配置
        nodeSelectorTerms: # 选择器
        - matchExpressions: # 匹配表达式
          - key: topology.kubernetes.io/zone # 匹配 label 的 key
            operator: In # 匹配方式，只要匹配成功下方的一个 value 即可
            values:
            - antarctica-east1 # 匹配的 value
            - antarctica-west1 # 匹配的 value
      preferredDuringSchedulingIgnoredDuringExecution: # 节点尽量匹配下方配置
      - weight: 1 # 权重[1,100]，按照匹配规则对所有节点累加权重，最终之和会加入优先级评分，优先级越高被调度的可能性越高
        preference:
          matchExpressions: # 匹配表达式
          - key: another-node-label-key # label 的 key
            operator: In # 匹配方式，满足一个即可
            values:
            - another-node-label-value # 匹配的 value
#      - weight: 20
        ......
  containers:
  - name: with-node-affinity
    image: pause:2.0

6.4.2 PodAffinity

Pod 亲和力：将与指定 pod 亲和力相匹配的 pod 部署在同一节点。

1.RequiredDuringSchedulingIgnoredDuringExecution

必须将应用部署在一块

2.PreferredDuringSchedulingIgnoredDuringExecution

尽量将应用部署在一块

3.配置模板

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity: # 亲和力配置
    podAffinity: # pod 亲和力配置
      requiredDuringSchedulingIgnoredDuringExecution: # 当前 pod 必须匹配到对应条件 pod 所在的 node 上
      - labelSelector: # 标签选择器
          matchExpressions: # 匹配表达式
          - key: security # 匹配的 key
            operator: In # 匹配方式
            values: # 匹配其中的一个 value
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity: # pod 反亲和力配置
      preferredDuringSchedulingIgnoredDuringExecution: # 尽量不要将当前节点部署到匹配下列参数的 pod 所在的 node 上
      - weight: 100 # 权重
        podAffinityTerm: # pod 亲和力配置条件
          labelSelector: # 标签选择器
            matchExpressions: # 匹配表达式
            - key: security # 匹配的 key
              operator: In # 匹配的方式
              values:
              - S2 # 匹配的 value
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: pause:2.0

6.4.3 PodAntiAffinity

Pod 反亲和力：根据策略尽量部署或不部署到一块

1.RequiredDuringSchedulingIgnoredDuringExecution

不要将应用与之匹配的部署到一块

    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone

2.PreferredDuringSchedulingIgnoredDuringExecution

尽量不要将应用部署到一块

7. 身份与权限认证

Kubernetes 中提供了良好的多租户认证管理机制，如 RBAC、ServiceAccount 还有各种策略等。

通过该文件可以看到已经配置了 RBAC 访问控制
/usr/lib/systemd/system/kube-apiserver.service

7.1认证

所有 Kubernetes 集群有两类用户：由 Kubernetes 管理的Service Accounts （服务账户）和（Users Accounts）普通账户。
普通账户是假定被外部或独立服务管理的，由管理员分配 keys，用户像使用 Keystone 或 google 账号一样，被存储在包含 usernames 和 passwords 的 list 的文件里。

需要注意：在 Kubernetes 中不能通过 API 调用将普通用户添加到集群中。

普通帐户是针对（人）用户的，服务账户针对 Pod 进程。
普通帐户是全局性。在集群所有namespaces中，名称具有惟一性。
通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户。
普通帐户和服务账户的审核注意事项不同。
对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义。

7.1.1 User Accounts

7.1.2 Service Accounts

Service Account 自动化
1.Service Account Admission Controller

通过 Admission Controller 插件来实现对 pod 修改，它是 apiserver 的一部分。创建或更新 pod 时会同步进行修改 pod。当插件处于激活状态（在大多数发行版中都默认情况）创建或修改 pod 时，会按以下操作执行：
1.如果 pod 没有设置 ServiceAccount，则将 ServiceAccount 设置为 default。
2.确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求。
3.如果 pod 不包含任何 ImagePullSecrets，则将ServiceAccount 的 ImagePullSecrets 会添加到 pod 中。
4.为包含 API 访问的 Token 的 pod 添加了一个 volume。
5.把 volumeSource 添加到安装在 pod 的每个容器中，挂载在 /var/run/secrets/kubernetes.io/serviceaccount。

2.Token Controller

TokenController 作为 controller-manager 的一部分运行。异步行为:

观察 serviceAccount 的创建，并创建一个相应的 Secret 来允许 API 访问。
观察 serviceAccount 的删除，并删除所有相应的ServiceAccountToken Secret
观察 secret 添加，并确保关联的 ServiceAccount 存在，并在需要时向 secret 中添加一个 Token。
观察 secret 删除，并在需要时对应 ServiceAccount 的关联

3.Service Account Controller

Service Account Controller 在 namespaces 里管理ServiceAccount，并确保每个有效的 namespaces 中都存在一个名为 “default” 的 ServiceAccount。

7.2 授权(RBAC)

7.2.1 Role

代表一个角色，会包含一组权限，没有拒绝规则，只是附加允许。它是 Namespace 级别的资源，只能作用与 Namespace 之内。

# 查看已有的角色信息
kubectl get role -n ingress-nginx -oyaml

配置文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: nginx-ingress
  namespace: ingress-nginx
roles:
- apiGroups:
  - ""
  resources:
  - configmaps
  - pods
  - secrets
  - namespaces
  verbs:
  - get
- apiGroups:
  - ""
  resourceNames:
  - ingress-controller-label-nginx
  resources:
  - configmaps
  verbs:
  - get
  - update
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create

7.2.2 ClusterRole

功能与 Role 一样，区别是资源类型为集群类型，而 Role 只在 Namespace

# 查看某个集群角色的信息
kubectl get clusterrole view -oyaml

7.2.3 RoleBinding

Role 或 ClusterRole 只是用于制定权限集合，具体作用与什么对象上，需要使用 RoleBinding 来进行绑定。
作用于 Namespace 内，可以将 Role 或 ClusterRole 绑定到 User、Group、Service Account 上。

# 查看 rolebinding 信息
kubectl get rolebinding --all-namespaces

# 查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -oyaml

配置文件

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  ......
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name nginx-ingress-role
subjects:
- kind: ServiceAccount
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx

7.2.4 ClusterRoleBinding

与 RoleBinding 相同，但是作用于集群之上，可以绑定到该集群下的任意 User、Group 或 Service Account

三. 运维管理

1.Helm 包管理器

类似yaml npm yum aptget

1.1.什么是Helm？

Kubernetes 包管理器
Helm 是查找、分享和使用软件构件 Kubernetes 的最优方式。
Helm 管理名为 chart 的 Kubernetes 包的工具。Helm 可以做以下的事情：

从头开始创建新的 chart
将 chart 打包成归档(tgz)文件
与存储 chart 的仓库进行交互
在现有的 Kubernetes 集群中安装和卸载 chart
管理与 Helm 一起安装的 chart 的发布周期

对于Helm，有三个重要的概念：
1.chart 创建Kubernetes应用程序所必需的一组信息。
2.config 包含了可以合并到打包的chart中的配置信息，用于创建一个可发布的对象。
3.release 是一个与特定配置相结合的chart的运行实例。

1.2. Helm架构

1.2.1. 重要概念

概念	描述
chart	chart 创建 Kubernetes 应用程序所必需的一组信息。
config	config 包含了可以合并到打包的 chart 中的配置信息，用于创建一个可发布的对象。
release	release 是一个与特定配置相结合的 chart 的运行实例。

1.2.2. 组件

1.helm客户端

Helm 客户端是终端用户的命令行客户端。负责以下内容：

本地 chart 开发
管理仓库
管理发布
与 Helm 库建立接口

发送安装的 chart

发送升级或卸载现有发布的请求

2.helm库

Helm 库提供执行所有 Helm 操作的逻辑。与 Kubernetes API 服务交互并提供以下功能：

结合 chart 和配置来构建版本
将 chart 安装到 Kubernetes 中，并提供后续发布对象
与 Kubernetes 交互升级和卸载 chart

独立的 Helm 库封装了 Helm 逻辑以便不同的客户端可以使用它。

1.3. 安装Helm

https://helm.sh/docs/intro/install

#1.下载二级制文件
wget https://get.helm.sh/helm-v3.14.2-linux-amd64.tar.gz
#2.解压
tar -zxvf helm-v3.14.2-linux-amd64.tar.gz
#3.把解压目录中的helm 移动到目录
mkdir -p /usr/local/bin/helm
mv [解压目录的helm类型的sh文件] usr/local/bin/helm
#4.添加阿里云helm仓库

1.4.Helm常用命令

命令	描述
helm repo	列出、增加、更新、删除 chart 仓库
helm search	使用关键词搜索 chart
helm pull	拉取远程仓库中的 chart 到本地
helm create	在本地创建新的 chart
helm dependency	管理 chart 依赖
helm install	安装 chart
helm list	列出所有 release
helm lint	检查 chart 配置是否有误
helm package	打包本地 chart
helm rollback	回滚 release 到历史版本
helm uninstall	卸载 release
helm upgrade	升级 release

1.5. chart详解

chart ≈镜像≈软件安装包

1.5.1 目录结构

mychart
├── Chart.yaml
├── charts # 该目录保存其他依赖的 chart（子 chart）
├── templates # chart 配置模板，用于渲染最终的 Kubernetes YAML 文件
│   ├── NOTES.txt # 用户运行 helm install 时候的提示信息
│   ├── _helpers.tpl # 用于创建模板时的帮助类
│   ├── deployment.yaml # Kubernetes deployment 配置
│   ├── ingress.yaml # Kubernetes ingress 配置
│   ├── service.yaml # Kubernetes service 配置
│   ├── serviceaccount.yaml # Kubernetes serviceaccount 配置
│   └── tests
│       └── test-connection.yaml
└── values.yaml # 定义 chart 模板中的自定义配置的默认值，可以在执行 helm install 或 helm update 的时候覆盖

1.5.2 redis chart实战

1.修改helm源

# 查看默认仓库
helm repo list

# 添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add aliyun https://apphub.aliyuncs.com/stable
helm repo add azure http://mirror.azure.cn/kubernetes/charts

2.搜索 redis chart

# 搜索 redis chart
helm search repo redis

# 查看安装说明
helm show readme bitnami/redis

3.修改配置安装

# 先将 chart 拉到本地
helm pull bitnami/redis

# 解压后，修改 values.yaml 中的参数
tar -xvf redis-17.4.3.tgz

# 修改 storageClass 为 managed-nfs-storage
# 设置 redis 密码 password
# 修改集群架构 architecture，默认是主从（replication，3个节点），可以修改为 standalone 单机模式
# 修改实例存储大小 persistence.size 为需要的大小
# 修改 service.nodePorts.redis 向外暴露端口，范围 <30000-32767>

# 安装操作
# 创建命名空间
kubectl create namespace redis

# 安装
cd ../
helm install redis ./redis -n redis

4.查看安装情况

# 查看 helm 安装列表
helm list

# 查看 redis 命名空间下所有对象信息
kubectl get all -n redis

# 如果status一直是pendding中，检查managed-nfs-storage是否安装好

5.升级与回滚

要想升级 chart 可以修改本地的 chart 配置并执行：
helm upgrade [RELEASE] [CHART] [flags]
helm upgrade redis ./redis
使用 helm ls 的命令查看当前运行的 chart 的 release 版本，并使用下面的命令回滚到历史版本：

helm rollback <RELEASE> [REVISION] [flags]

# 查看历史
helm history redis
# 回退到上一版本
helm rollback redis
# 回退到指定版本
helm rollback redis 3