k8s常用知识点总结
1.常用的命令
创建pod
kubectl apply -f pod的yaml文件路径
kubectl create -f pod的yaml文件路径
删除pod
kubectl delete pod - f pod的yaml文件路径
kubectl delete pod pod名
删除其他资源类似,如删除cm资源
kubectl delete cm -f cm的yaml文件路径
kubectl delete cm cm名字
查看pod
kubectl get pod pod名 -o wide
kubectl describe pod pod名
kubectl get pod pod名 -o yaml
进入容器
kubectl exec pod名 -it -- sh
一个pod多个容器进入指定容器
kubectl exec pod名 -c 容器名 -it --sh
使用容器执行命令(如查看环境变量)
kubectl exec pod名 -- env
复制容器文件到宿主机
kubectl cp pod名:容器文件路径 本地路径
复制宿主机文件到容器内
kubectl cp 本地文件 pod名:容器路径
查看容器日志
kubectl logs -f pod名
查看容器日志近10分钟
kubectl logs -f pod名 --since=10m
查看pod特定容器日志
kubectl logs -f pod名 -c 容器名
查看容器上一个实例（上一个挂掉的容器的日志）
kubectl logs -f pod名 -p
2.镜像的拉取策略
po.spec.container.imagePullpolicy(对单个容器生效)
never从不拉取，如果本地没有镜像则启动失败
always一直从远程仓库拉取，默认配置
ifNotPresent 优先运行本地镜像（即使远程版本较新），本地无镜像远程拉取
3.容器的重启策略
po.spec.restartPolicy
always:遇到关闭则重启
OnFailure:异常关闭重启
never:从不重启
4.数据卷
k8s中有多种数据卷，比如emptyDir,hostPath,nfs,数据卷的使用分为数据卷的定义和数据卷的挂载
emptyDir 卷是一个在 Pod 被分 配到节点时创建的临时目录。Pod 中的所有容器都可以访问这个目录，但一旦 Pod 被删除，存储在 emptyDir 卷中的数据也会被永久删除，主要是实现了pod中不同的容器的数据共享，生命周期和pod一致。使用hostPath解决了pod删除，数据丢失的问题。但是不同节点的pod之间的容器无法做到数据共享，此时使用nfs便解决了这个问题
在spec下定义和container同级
emptyDir,hostPath,nfs数据卷的定义
volumes:
- name: data01
emptyDir: {}
- name: data02
hostPath:
path: 宿主机路径
- name: data03
nfs:
server: nfs服务器ip
path: nfs服务器共享的目录
在container下定义
数据卷的使用，将数据卷挂载到 Pod 中的容器,name为使用的数据卷名，mountPath为挂载点，如下
volumeMounts: name:data01 mountPath: /usr/share/nginx/html
cm数据卷的使用见下文7.configMap
5.变量
定义完成变量，可以通过这条命令查看，kubectl exec pod名 -- env
变量的定义:
env: - name: AA value: aa - name: BB valueFrom： fieldRef: fieldPath: "status.hostIP" #使用cm资源定义的变量作为变量 - name: CC valueFrom: configMapKeyRef: name: cm资源名 key: 定义里面的key #secret资源定义的变量也可以作为变量，用法见下面secret资源部分
6.容器的资源限制
容器的资源限制
1️⃣ po.spec.container.resources.requests
2️⃣ po.spec.container.resources.limits
1️⃣是运行pod宿主机需要达到的资源，并不会一启动pod立刻就消耗这么多资源，如果没有节点达到，pod会处于pendding状态
2️⃣是对pod的资源限制，即pod消耗的资源的上限
spec: container: - name: xxx resources: requests: #这里1核心为1000m cpu: 500m memory:256M limits: #这里1.5表示1.5核 cpu: 1.5 memory: 10G
7.configMap资源
主要用于更改配置文件，或者修改变量
apiVersion: v1 kind: ConfigMap metadata: name: mycm data: chunjie: "kuaile" shijian: "yuanyuechusan" ngconf: | # 用户和组，通常设置为nginx或www-data，具体取决于你的系统和安装方式 user nginx; worker_processes auto; # 自动根据CPU核心数设置工作进程数 # 全局错误日志和PID文件路径 error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; ...
查看cm资源：kubectl get cm
查看cm资源及其定义的变量：kubectl describe cm cm名字
cm资源的使用：
一种是env使用cm的变量：如上5.变量章节说明，这里为了方便阅读，便把上述代码贴于此处
env: #使用cm资源定义的变量作为变量 - name: CC valueFrom: configMapKeyRef: name: cm资源名 key: 定义里面的key
另外一种用法是将cm资源挂载为pod的配置文件，比如想在cm资源定义nginx容器的配置文件，直接将配置文件写在|的下一行后两格（yaml语法）
定义数据卷：
volumes: - name: data01 configMap: #cm资源名字 name: mycm items: #比方说想要使用cm资源定义的nginx配置文件，对应cm资源下data的key名 - key: ngconf #当subPath的值和configMap.items.path相同时，mountPath的挂载点是一个文件而非目录 path: ng
挂载到容器的配置文件
volumeMounts: - name: data01 mountPath: /etc/nginx/conf.d/default.conf subPath: ng
8.容器端口映射
作用将pod容器端口映射到宿主机
ports: #指定容器的端口号 - containerPort: 80 #指定绑定的宿主机的端口号 hostPort: 88 #指定容器的协议 protocol: tcp
9.sercet资源
sercet资源用法和configMap资源用法类似，定义资源清单时，value值需要先经过base64加密。
创建sercet资源清单：
apiVersion: v1 kind: Secret metadata: name: mysec data: yinxiong: ZGlqaWEK ngconf: 配置文件base64编码之后
secret两种用法同cm资源类似
1.变量方式使用
env: - name: dongman valueFrom: secretKeyRef: #secret资源的名字 name: mysec key: yinxiong
2.数据卷形式挂载
定义数据卷
volumes: - name: data01 secret: #secret资源的名字 secretName: mysec items: - key: ngconf #当subPath的值和secret.items.path相同时，mountPath的挂载点是一个文件而非目录 path: ng
挂载
volumeMounts: - name: data01 mountPath: /etc/nginx/conf.d/default.conf subPath: ng
10.pod的标签管理
1.响应式创建标签
查看标签
kubectl get pods --show-labels
创建标签
kubectl label -f 清单文件 key=value 或者 kubectl label pod pod名 key=value
覆盖原来标签
kubectl label --overwrite pod pod名 key=value
移除标签
kubectl label pod pod名 key-
节点打标签
kubectl label nodes node_name key=value
所有节点删除标签
kubectl label nodes --all key-
2.声明式创建标签
apiVersion: v1 kind: Pod metadata: name:podlabel label: jiang:zhi key:value spec: ...
标签的作用：
1.指定标签进行删除
kubectl delete pods -l key=value
2.查看标签有某个键的资源
kubectl get pods -l kk (查看标签有kk的pod)
11.探针
探针一共有三种，分别为startupProbe启动检查探针，readinessProbe就绪探针，livenessProbe存活探针。
如果提供了启动探针，则所有其他的探针都会被禁用，直到此探针成功为止。
如果启动探测失败，kubelet杀死容器，而容器依照重启策略重启。
如果就绪探针探测失败，pod会处于未就绪状态。
如果就绪探针未开始检测，pod会处于未就绪状态。
如果存活探针检查失败，将重启容器，与前两者不同，存活探针会周期性检查。
检查方法有exec(自定义检查命令),httpGet(http请求结果),tcpsocket(端口是否监听)。
总结：当一个pod提供了这三种探针，首先是startupProbe启动检查探针，如果不通过，则重启pod，检查通过则进行就绪探针和存活探针检查。就绪探针检查通过pod为就绪状态，存活探针检测失败，按重启策略重启。就绪探针和存活探针属于并行关系。
三种探针详细使用方式详见博客。
12.名称空间
名称空间是用来隔离K8S集群的资源。我们通常使用名称空间对企业业务进行逻辑上划分。
全局资源不支持名称空间，局部资源支持名称空间。
同一个名称空间下，同一种资源类型，无法同时创建多个名称相同的资源。
1.查看名称空间
kubectl get namespace
kubectl get ns
2.默认名称空间为default，不指定名称空间默认为default名称空间
3.查看所有名称空间，使用-A或者--all-namespaces
如：kubectl get pods --all-namespaces 或者 kubectl get pods -A
4.describe或者查看yaml文件（-o yaml）的方式也可以查看名称空间
5.创建名称空间
apiVersion: v1 kind: Namespace metadata: name: myns
6.使用名称空间
metadata: name: xxx namespace: myns
7.注意事项，名称空间一旦被删除，其下所有资源也会被删除
13.ReplicationController（rc控制器）
作用：RC的主要作用是确保在任何时候，Kubernetes集群中都有指定数量的Pod在运行。如果实际运行的Pod数量少于RC中定义的副本数量（replicas），RC会自动创建额外的Pod来达到目标数量。
资源清单如下：
apiVersion: v1 kind: ReplicationController metadata: name: web-rc spec: # 指定Pod的副本数量，默认值为1 replicas: 3 # 指定标签选择器 selector: name: lxc zuoyong: web # 指定创建Pod的模板 template: metadata: #指定模板的标签，只有当模板标签包含标签选择器的所有标签才能创建成功，可以比选择器标签多 labels: name: lxc zuoyong: web spec: containers: - name: nginx image: harbor.lxcedu.com/base-img/nginx:1.14.2
更新：当需要更新Pod的镜像或其他配置时，可以通过更新RC的模板来实现。RC会创建带有新配置的新Pod，并逐渐替换掉旧的Pod，直到所有的Pod都被更新为止。这种滚动更新的方式可以减少对业务的影响。
升级:
更改资源清单文件，containers下的image使用新的镜像
更新资源清单文件：kubectl apply -f get rc-xx.xxx.yaml
逐个删除原来的pod: kubectl delete -f pods xxx
由于pod是被rc维护的，删除的pod会重新拉起，代替新的pod
回滚与升级类似
14.ReplicaSet(rs控制器)
ReplicaSet控制器简称rs资源，也是用于控制pod副本数量。
类似与rc资源，也可以控制pod的存活数量，但是其标签匹配更灵活，可以基于标签匹配，也可以基于表达式比配，基于表达式匹配可以匹配是否存在key。
apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-nginx spec: # 指定创建Pod的副本数量，默认值为1. replicas: 4 # 定义标签选择器,rs资源基于标签选择器关联对应的Pod哟～ selector: # 基于标签匹配 #matchLabels: # hobby: sleep # 基于表达式匹配 matchExpressions: - key: apps # values: # - haha # - xixi # - hehe # - web # 当operator的值为In或者NotIn时，values的值不能为空。 # - In: # key的值必须在values定义的数组内。 # - NotIn: # key的值必须不在values定义的数组内。 # operator: In # operator: NotIn # 当operator的值为Exists或者DoesNotExist时，values的值必须为空. # - Exists: # 只要存在key即可。 # - DoesNotExist: # 只要不存在指定的key即可。 # operator: Exists operator: DoesNotExist # 定义Pod资源创建的模板 template: metadata: labels: # apps: web hobby: sleep spec: containers: - name: web image: harbor.lxcedu.com/base-img/nginx:1.14.2
15.deployments资源
1.将rs资源的kind的值改为Deployment即可。
2.相比rs资源，升级时无须删除pod,
3.deployments资源不会直接控制pod，而是通过控制rs资源控制pod
4.strategy升级策略（与template同级）
strategy: # 升级的类型,"Recreate" or "RollingUpdate" # Recreate: # 先停止所有的Pod运行，然后在批量创建更新。 # 生产环节中不推荐使用这种策略，因为升级过程中用户将无法访问服务! # RollingUpdate: # 滚动更新，即先实现部分更新，逐步替换原有的pod，是默认策略。 # type: Recreate type: RollingUpdate # 自定义滚动更新的策略 rollingUpdate: # 在原有Pod的副本基础上，多启动Pod的数量。 # maxSurge: 2 maxSurge: 2 # 在升级过程中最大不可访问的Pod数量. # maxUnavailable: 2 maxUnavailable: 2
deployments资源的交互升级和非交互式升级
交互式升级：
kubectl edit -f 01-deploy-update.yaml
kubectl edit deployments.apps
非交互式升级：
kubectl set image deploy web-deploy nginx=harbor.lxcedu.com/base-img/nginx:3
即kubectl set image deploy deploy资源名 容器名=镜像名
16.service资源（svc资源）
1.ClusterIP:对内提供Pod服务的动态发现，对外提供统一的访问入口，进行pod的负载均衡。
apiVersion: v1 kind: Service metadata: name: sc-web-lb namespace: default spec: # 关联后端的Pod selector: name: lxc zuoyong: web # 指定svc的类型，有效值为: ExternalName, ClusterIP, NodePort, and LoadBalancer # ExternalName: # 可以将K8S集群外部的服务映射为一个svc服务。类似于一种CNAME技术. # ClusterIP: # 仅用于K8S集群内部使用。提供统一的VIP地址。默认值！ # NodePort: # 基于ClusterIP基础之上，会监听所有的Worker工作节点的端口，K8S外部可以基于监听端口访问K8S内部服务。 # LoadBalancer: # 主要用于云平台的LB等产品。 type: ClusterIP # 指定端口映射相关信息 ports: # 指定svc的端口号 - port: 88 # 指定Pod端口号 targetPort: 80 # 指定协议 protocol: TCP # 指定ClusterIP的地址 clusterIP: 10.200.100.100
2.NodePort:基于ClusterIP基础之上，会监听所有的Worker工作节点的端口，K8S外部可以基于监听端口访问K8S内部服务。NodePort类型的Service允许从集群外部访问集群内部的服务，如下配置，访问宿主机的30080端口相当于访问pod的80端口。
type: NodePort selector: app: blue # 指定端口映射相关信息 ports: # 指定svc的端口号 - port: 80 # 指定Pod端口号 targetPort: 80 # 指定协议 protocol: TCP # 指定访问宿主机的端口，该端口的报文会被转发后端的容器端口 # 默认svc有效端口范围是:"30000-32767" nodePort: 30080 # 指定ClusterIP的地址 clusterIP: 10.200.100.200
17.deployments资源实现蓝绿发布和灰度发布
实现蓝绿发布步骤：
1.部署当前版本（旧版本）
kind: Deployment apiVersion: apps/v1 metadata: name: blue spec: replicas: 3 selector: matchLabels: app: blue template: metadata: labels: app: blue spec: containers: - name: myweb image: 旧版本镜像
2.部署service
kind: Service apiVersion: v1 metadata: name: web-svc spec: type: NodePort ports: - port: 80 targetPort: 80 nodePort: 30080 selector: app: blue
3.部署新版本（使用新的deployment名称或label标签）
kind: Deployment apiVersion: apps/v1 metadata: name: green spec: replicas: 3 selector: matchLabels: app: green template: metadata: labels: app: green spec: containers: - name: myweb image: 新版本镜像
4.切换service标签到新的pod
将svc的spec的selector的app的值改为grenn即可。
缺点：浪费资源
实现灰度发布步骤：
1.部署当前版本（旧版本）
2.部署service
3.部署新版本deployments，pod数量为一个，标签与旧版本一致
4.无异常时，逐渐减小旧版本pod数量，增大新版本pod数量，直至所有pod变为新版本
18.DaemonSet控制器
作用：DaemonSet确保全部worker节点上运行一个Pod的副本。
DaemonSet的一些典型用法： (1)在每个节点上运行集群守护进程(flannel网络插件等)
(2)在每个节点上运行日志收集守护进程(flume，filebeat，fluentd等)
(3)在每个节点上运行监控守护进程（zabbix agent，node_exportor等）
补充： (1)当有新节点加入集群时，也会为新节点新增一个Pod
(2)当有节点从集群移除时，这些Pod也会被回收
(3)删除DaemonSet将会删除它创建的所有Pod
(4)如果节点被打了污点的话，且DaemonSet中未定义污点容忍，则Pod并不会被调度到该节点上
19.coreDNS
使用：<service name>.<namespace name>.集群域名
20.影响pod调度的因素
1.nodename 节点名字
2.hostnetwork 宿主机网络
3.污点
4.污点容忍
5.Pod亲和性
6.Pod反亲和性
7.节点亲和性
8.resources 资源情况
21.污点
作用于worker节点上，影响容器的调度。
key[=value]:effect
污点的类型：NoSchedule、PreferNoSchedule或NoExecute
NoExecute：该节点不再接收新的Pod调度，与此同时，会立刻驱逐已经调度到该节点的Pod。
NoSchedule：该节点不再接收新的Pod调度，但不会驱赶已经调度到该节点的Pod
PreferNoSchedule：该节点可以接受调度，但会尽可能将Pod调度到其他节点，换句话说，让该节点的调度优先级降低啦。
1.查看容器污点：kubectl describe nodes|grep Taints
2.给节点打上污点：kubectl taint node node_name wudianmingzi=wudain:NoSchedule (wudianmingzi污点的key,wudian污点的值，下同)
3.移除污点：kubectl taint node node_name wudianmingzi-
22.污点容忍
spec: # 配置Pod的污点容忍 tolerations: # 指定污点的key # 若不指定key，则operator的值必须为Exists，表示匹配所有的key - key: qq # 指定污点的value value: ww # 指定污点的effect，有效值为: NoSchedule, PreferNoSchedule,NoExecute # 若不指定则匹配所有的影响度。 effect: NoExecute # 表示key和value的关系，有效值为Exists， Equal。 # Exists # 表示存在指定的key即可，若配置，则要求value字段为空。 # Equal: # 默认值，表示key=value。 operator: Equal - key: web operator: Exists - key: node-role.kubernetes.io/master operator: Exists # 如果不指定key，value，effect，仅配置"operator: Exists"表示无视任何污点! #- operator: Exists
对以上总结一下，配置污点容忍，要先指明是哪一个key的污点，若不指明则oprator的值必须为Exists，再配置operator，operator为Exists则下面无需再写value,匹配key即可，operator为Equal，表示key的value值和下面的value的值相等，下面需要再写一行value:xxx。effect匹配污点类型，若不指定则匹配所有。
参考下图：
spec: tolerations: - key: oprator: value: effect:
到这里还不理解，可以参考几个常见的例子(对照流程图观看)
例1：匹配所有key为web，value值为空，effect为NoExecute的污点(kubectl taint node node_name web:NoExecute)
spec： tolerations: - key: web oprator: Exists effect: NoExecute
例2：匹配所有key为test，值为version1，effect为所有的污点
spec： tolerations: - key: test oprator: Equal value: version1
例3:忽略所有污点
spec： tolerations: - oprator: Exists
23.节点选择器
应用场景：当需要将pod调度到指定节点时候。
给指定的节点打标签
kubectl label nodes node_name keyaa=valueaa
spec： tolerations: - oprator: Exists nodeSelector: keyaa: valueaa
24.节点亲和性
节点选择器，当这样子当两个节点，比如节点a,keyaa=value1,节点b,keyaa=value2，此时节点选择器无法满足，所以引入了节点亲和性。
如下，这样子两个节点都会被调度到
spec: affinity: # 定义节点的亲和性 nodeAffinity: # 定义硬限制 requiredDuringSchedulingIgnoredDuringExecution: # 定义节点的匹配条件 nodeSelectorTerms: - # 基于节点的标签进行匹配 matchExpressions: - # 指定标签的key key: keyaa # 指定key和value之间的对应关系 operator: In # 指定标签的value（可以是一个或多个） values: - value1 - value2 # 指定key和value之间的对应关系，有效值如下: # In: # key的值必须在vlaues内。要求values不能为空。 # NotIn: # 和In相反。要求values不能为空。 # Exists: # 只要存在指定key即可，vlaues的值必须为空。 # DoesNotExist: # 只要不存在指定key即可，vlaues的值必须为空。 # Gt: # 表示大于的意思，values的值会被解释为整数。 # Lt: # 表示小于的意思，values的值会被解释为整数。
24.Pod亲和性与反亲和性
pod亲和性的理解：将全部pod调度到同一个拓扑域上（拓扑域指定节点的标签，指定的这个节点标签相同为同一个拓扑域，如下例子中节点k8s231和k8s234属于同一个拓扑域）
pod亲和性的理解：将全部pod调度到同一个拓扑域上
Pod亲和性应用场景：
比方说在广州，深圳，佛山三地都有服务器，想让所有pod都调度到其中一地。如何实现： 1.给不同地址的节点打标签
kubectl label node k8s231 place=guangzhou
kubectl label node k8s232 place=shenzhun
kubectl label node k8s233 place=foshan
kubectl label node k8s234 place=guangzhou
2.将拓扑域设置为place
apiVersion: apps/v1 kind: Deployment metadata: name: deployment_name # 请替换为实际的Deployment名称 spec: replicas: 3 # 副本数量，可根据需求调整 selector: matchLabels: name: lxc # 请替换为实际的应用标签 template: metadata: labels: name: lxc # 请替换为实际的应用标签 spec: affinity: #定义pod亲和性 podAffinity: #硬限制 requiredDuringSchedulingIgnoredDuringExecution: #指定拓扑域为place - topologyKey: place labelSelector: #基于标签进行匹配 matchExpressions: #指的是pod标签的key - key: name operator: In #pod标签key的values values: - lxc tolerations: - operator: Exists containers: ...
反亲和性：将podAddinity改为podAntiAffinity，其他不变，此时每个拓扑域只能调度一个pod。若没有足够的节点（每个节点的标签place的值应该与其他不同），则剩下的pod将会处于penging状态。假设此时副本数量为5,那么有一个pod处于penging状态。(补充说明:前提是上面指定的是硬限制，软限制则第5个pod可以调度成功)
25.k8s服务代理模式转换
(1)所有worker节点安装ipvs相关组件 yum -y install conntrack-tools ipvsadm.x86_64
(2)编写加载ipvs的配置文件
cat > /etc/sysconfig/modules/ipvs.modules <<EOF #!/bin/bash
modprobe -- ip_vs modprobe -- ip_vs_rr modprobe -- ip_vs_wrr modprobe -- ip_vs_sh modprobe -- nf_conntrack_ipv4 EOF
(3)加载ipvs相关模块并查看 chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4
4.1仅需修改工作模式("mode")为ipvs即可。 kubectl -n kube-system edit cm kube-proxy
4.2 验证是否修改成功：kubectl -n kube-system describe cm kube-proxy | grep mode
(5)删除旧的kube-proxy，最好逐个删除pod kubectl get pods -A | grep kube-proxy | awk '{print $2}' | xargs kubectl -n kube-system delete pods
(6)验证kube-proxy组件工作模式是否生效
kubectl get pods -A | grep kube-proxy kubectl logs kube-proxy-k6mrc -n kube-system
ipvsadm -ln | grep 10.200.100.200 -A 3
26.RBAC基于角色的访问控制
角色（Role）：定义了一组对资源的访问权限。Role作用于特定的命名空间。
角色绑定（RoleBinding）：将Role绑定到具体的用户、用户组或ServiceAccount上，从而在集群或命名空间级别授予用户或用户组对资源的访问权限。RoleBinding通常绑定到特定命名空间内的主体。
集群角色（ClusterRole）：与Role类似，但ClusterRole作用于整个集群，而不是单个命名空间。
集群角色绑定（ClusterRoleBinding）：将ClusterRole绑定到具体的用户、用户组或ServiceAccount上，用于集群范围的操作，如创建命名空间或管理集群配置。ClusterRoleBinding是跨集群的。
查看角色：kubectl get clusterrole
User:用户自定义名称，一般是给人用的
ServiceAccount:服务账号，一般是给程序用的
Group:给一个组使用
K8S内置集群角色： cluster-admin:超级管理员，有集群所有权限。 admin:主要用于授权命名空间所有读写权限。 edit:允许对大多数对象读写操作，不允许查看或者修改角色，角色绑定。 view: 允许对命名空间大多数对象只读权限，不允许查看角色，角色绑定和secret。
1.基于用户的权限管理，简单来讲，通过用户与角色的绑定来管理k8s资源。
2.基于用户组的权限管理，用户组的权限就是角色绑定到用户组的角色权限，然后属于用户组的用户持有的kubeconfig具有用户组的权限
3.基于serviceAccount服务账号的权限管理，sa资源使用步骤：1.创建服务账号，2.创建角色，3.角色绑定将sa和role绑定，4.pod资源使用服务账号。
以上此部分角色创建，角色绑定，用户组及用户配置，sa资源详细使用见博客。
27.PV，PVC，SC资源
PV:持久卷，用于定义持久卷，如大小，存储卷类型
PVC:持久卷声明，声明了对持久卷的需求
使用PV和PVC，可以实现应用与存储的解耦，使得应用在迁移或扩展时无需关心底层存储资源的变化。
PV的回收策略： Retain: "保留回收"策略允许手动回收资源,删除pvc时，pv仍然存在，并且该卷被视为"已释放(Released)"。 在管理员手动回收资源之前，使用该策略其他Pod将无法直接使用。 手动回收资源：将原有资源移动，删除pv,重新创建pv。pv将重新处于Available。
Recycle: 对于"回收利用"策略官方已弃用。相反，推荐的方法是使用动态资源调配。
StorageClass:动态存储卷，简称sc,作用可以根据pvc，自动创建pv。在Kubernetes中，当有了合适的StorageClass后，通常无需手动创建PV，只需要创建PVC，StorageClass会根据PVC的请求自动创建相应的PV。
对于k8s不支持的动态不支持的存储类型，如NFS，需要使用第三方的动态供应器。我已经把项目导出（k8s-external-storage/nfs-client/deploy）。
对于k8s-external-storage/nfs-client/deploy的补充：
1.class.yaml是sc资源，rbac.yaml角色创建和角色绑定，deployment.yaml是nfs动态存储配置器。
2.项目里面test-claim.yaml,创建pvc资源，test-pod.yaml，创建pod并使用“test-claim.yaml,创建pvc资源”。这两个文件可以用于测试。
3.基本上只需要修改deployment.yaml （修改nfs服务器地址和挂载点即共享路径，env里面的变量）
kubectl apply -f class.yaml -f rbac.yaml -f deployment.yaml
28.StatefulSet控制器
作用：(1)提供，稳定唯一的网络标识符。 (2)提供，稳定独立持久的存储。
稳定的网络标识:
其本质对应的是一个service资源，只不过这个service没有定义VIP，我们称之为headless service，即"无头服务"。
1.通过"headless service"来维护Pod的网络身份，会为每个Pod分配一个数字编号并且按照编号顺序部署。
综上所述，无头服务（"headless service"）要求满足以下两点: (1)将svc资源的clusterIP字段设置None，即"clusterIP: None"; (2)将sts资源的serviceName字段声明为无头服务的名称;
pod的域名：<pod-name>.<svc-name>.<namespace>.svc.cluster.local
svc.cluster.local为集群域名
sts无头服务固定资源清单：
vim 01-statefulset-headless-network.yaml
apiVersion: v1 kind: Service metadata: name: linux-headless spec: ports: - port: 80 name: web # 将clusterIP字段设置为None表示为一个无头服务，即svc将不会分配VIP。 clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: linux-web-sts spec: selector: matchLabels: app: nginx # 声明无头服务 serviceName: linux-headless replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: harbor.lxcedu.com/base-img/nginx:1
sts提供稳定唯一的网络标识符。，简单来讲，就是固定了域名，pod重启不影响域名。假如我的pod运行的mysql的主库和从库，sts可以确保每次连的是同一个数据库，不会说这次连主库，下次给连成从库。
sts提供稳定独立持久的存储案例：
此案例无需设置无头服务。
StatefulSet 确保每个 Pod 都有一个稳定且唯一的标识符，这使得它能够为每个 Pod 分配一个持久的存储卷。
apiVersion: apps/v1 kind: StatefulSet metadata: name: linux-web-sts-volume spec: selector: matchLabels: apps: nginx serviceName: linux-headless replicas: 3 # 卷申请模板，会为每个Pod去创建唯一的pvc并与之关联哟! volumeClaimTemplates: - metadata: name: data spec: accessModes: [ "ReadWriteOnce" ] # 声明自定义的动态存储类，即sc资源。 storageClassName: "managed-nfs-storage" resources: requests: storage: 2Gi template: metadata: labels: apps: nginx spec: containers: - name: nginx image: harbor.lxcedu.com/base-img/nginx:1 volumeMounts: - name: data mountPath: /usr/share/nginx/html --- apiVersion: v1 kind: Service metadata: name: linux-sts-svc spec: selector: apps: nginx ports: - port: 80 targetPort: 80
29.Metric Server
Metric Server是一种用于提供Kubernetes集群内Pod和节点资源使用情况（如CPU、内存等）的标准接口。它是Kubernetes内置自动缩放管道的可扩展、高效的容器资源指标来源。
作用：提供资源使用情况数据，支持自动缩放，支持集群的容量规划、性能调优和故障排查。
用法：
1.下载起源清单：
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml
2.修改资源清单，如图所示，增加- --kubelet-insecure-tls，修改镜像。 
3.创建应用：kubectl apply -f high-availability-1.21+.yaml
4.检查状态：kubectl -n kube-system get pods| grep metrics-server
5.验证 metrics-server是否正常
查看pod资源情况：kubectl top pods
查看节点资源情况：kubectl top node
30.HPA
Kubernetes的 HPA (Horizontal Pod Autoscaler) 是一种用于自动扩缩（伸缩）Pod副本数的机制，根据指标（如 CPU 使用率、内存使用率或自定义指标）动态调整部署的Pod数量，从而保证应用程序的性能和资源的高效使用。
简单来讲就是根据pod的性能指标，动态调整pod的数量，HPA调整的是Pod的数量，而不是节点上的Pod分布。它不会关心Pod具体运行在哪个节点上，只会根据集群的整体负载和指定的监控指标来调整Pod的总数
响应式创建HPA：kubectl autoscale deployment deployment资源名字 --min=2 --max=5 --cpu-percent=80
声明式创建HPA：
# 指定Api的版本号 apiVersion: autoscaling/v2 # 指定资源类型 kind: HorizontalPodAutoscaler # 指定hpa源数据信息 metadata: # 指定名称 name: deploy01-hpa # 指定名称空间 namespace: default # 用户的期望状态 spec: # 指定最大的Pod副本数量 maxReplicas: 5 # 指定监控指标 metrics: # 指定资源限制 - resource: # 指定资源限制的名称 name: cpu # 指定限制的阈值 target: #限制cpu为百分之八十 averageUtilization: 80 type: Utilization type: Resource # 指定最小的Pod副本数量 minReplicas: 2 # 当前的hpa规则应用在哪个资源 scaleTargetRef: apiVersion: apps/v1 kind: Deployment #deploy资源名字 name: deploy-hpa
上述代码，动态调整部署的Pod数量为2-5，关联的是名字为deploy-hpa的Deployment，限制的是cpu资源为百分之八十。当pods消耗资源超过限定的值，pod会自动扩容至5个，当资源消耗降低，则pod数量减少。
deploy资源例子
apiVersion: apps/v1 kind: Deployment metadata: name: deploy-hpa spec: replicas: 3 selector: matchExpressions: - key: apps operator: Exists template: metadata: labels: apps: hpa spec: containers: - name: web image: harbor.lxcedu.com/base-img/nginx:1 resources: requests: cpu: 500m memory: 200M limits: cpu: 1 memory: 500M
值得注意的是：Pod 的资源请求（requests）需要为 CPU 设置一个值。HPA 需要根据 CPU 的请求量来计算当前的 CPU 使用率。否则hpa功能无法实现。
31.helm和traefik
helm的使用及traefik基于helm的安装及启用，详见博客。
补充：建议将traefik的副本数调大，values的replica。
32.Ingress
相比于NodePort方式，使用Ingress可以节约端口资源，并且能够通过域名匹配将流量分配到不同的Pod上（这些Pod可能由不同的Deployment控制）。
-
工作原理：Ingress是Kubernetes中的一个API对象，它定义了外部用户如何访问集群内部的服务。Ingress控制器负责实现Ingress规则，将外部流量根据域名、路径等信息转发到集群内部相应的服务上。
-
端口占用：Ingress方式通常只需要一个或少量的NodePort（或LoadBalancer）来暴露Ingress控制器。由于Ingress控制器可以根据域名和路径等信息将流量转发到不同的服务上，因此不需要为每个服务都分配一个独立的NodePort。
-
流量分配：Ingress提供了灵活的流量分配功能。用户可以根据域名、路径、HTTP头部等信息来定义路由规则，实现基于域名的虚拟托管和基于路径的流量拆分。这使得Ingress成为微服务架构中管理外部流量的理想选择。
生产环境可以这样子配置，两台nginx服务器做了高可用，配置upstreem模块，将流量反向代理打到k8s集群的ingress的8000端口，配置了ingress规则，自动关联了pod，允许外部请求通过Ingress控制器访问到集群内部的指定Service。
ingress资源清单：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: yiliao annotations: kubernetes.io/ingress.class: traefik # 指定Ingress 控制器为"traefik" spec: rules: - host: yiliao.lxcedu.com http: paths: - backend: service: name: lxcedu-linux-yiliao-svc port: number: 80 path: "/" pathType: "Prefix"
通过Ingress资源配置了一个规则，允许外部请求通过Ingress控制器访问到集群内部的指定Service。
基于traefik的ingress需要将流量转发
kubectl port-forward kubectl get pods -l "app.kubernetes.io/name=traefik" -o name` --address=0.0.0.0 8000:8000
40.job控制器
job概述：一次性任务，pod完成作业后并不重启，重启策略为restartPolicy:Never，作业完成之后，pod的状态为competed。
apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: containers: - name: pi image: perl:5.34 # 它计算π到2000个位置并打印出来。大约需要 10 秒才能完成。 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never # 指定标记此作业失败之前的重试次数。默认值为6 backoffLimit: 4
41.cron job控制器
cronjob概述：周期性任务，CronJob底层逻辑是周期性创建Job控制器来实现周期性任务的。
apiVersion: batch/v1 kind: CronJob metadata: name: hello spec: # 定义调度格式，参考链接：https://en.wikipedia.org/wiki/Cron # ┌───────────── 分钟 (0 - 59) # │ ┌───────────── 小时 (0 - 23) # │ │ ┌───────────── 月的某天 (1 - 31) # │ │ │ ┌───────────── 月份 (1 - 12) # │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日） # │ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat # │ │ │ │ │ # │ │ │ │ │ # * * * * * schedule: "* * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox:1.28 imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; echo Hello restartPolicy: OnFailure
42.pod的驱逐与节点退出集群
43.kubeadm快速将节点加入集群
44.补充：
1.对于harbor仓库私有项目的拉取，需要现在harbor上创建对应的用户，其次通过kubectl create secret 创建凭证，拉取时候指定imagepullSecrets:- name:xxx,方可拉取镜像。
2.初始化容器应用场景:主容器使用StorageClass（简称SC）来动态分配持久卷（Persistent Volume，简称PV），由于持久卷没有代码，可以使用初始化容器从代码仓库拉取代码，初始化容器和主容器挂载到同一个sc。 过程： 在Pod的YAML定义文件中，添加初始化容器和主容器。 初始化容器负责从远程仓库（如Git）拉取代码，并将其存储到一个临时目录或PV中（如果PV已经被挂载到Pod中）。 主容器则挂载相同的PV，并可以从PV中访问初始化容器拉取的代码。