configMap
一般用来存储配置信息
创建configMap
从文件中获取信息创建：kubectl create configmap my-config --from-file=/tmp/k8s/user.txt
直接指定信息：
kubectl create configmap my-config01 --from-literal=key1=config1 --from-literal=key2=config2
ymal文件创建
ConfigMap的使用
为什么使用： 1，复用配置文件，可以启动多个nginx的pod，共同使用同一个pod
2，便于修改，维护
如何使用：
1 将ConfigMap中的数据设置为容器的环境变量
定义configmap
kubectl create configmap my-config05 --from-literal=key1=123
2 configmap挂载
案例将名为my-config的cm挂载到pod中的/etc/config目录下，可以进入容器查看
注意：subPath: nginx.cong #如果mountPath挂载目录之前有数据，需要在下面加上subPath，表示不会覆盖原有数据。换句话说就是指定某个文件挂载，而不是挂载全部
secret
与configmap类似
探针
种类
livenessProbe
readynessProbe
startupProbe（1.16新引入）
探测方法
ExecAction（执行命令，正确返回0，错误返回非0）、
HttpGet（访问htttp页面，正确则显示正常，错误则会在svc中的endpoints中删除对应的pod，直至下次检查成功
TcpSocket： 通过TCP 连接来检查容器的状态。它通常用于检查容器内部的 TCP 服务是否可以正常连接。
livenessProbe
exec
root@master day07\]# cat liveness-exec.yml apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec-001 spec: containers: - name: liveness image: nginx args: #定义容器启动时执行的命令 - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: #指定livess检查 exec: #指定检查方式为执行命令 command: - cat - /tmp/healthy #命令成功返回0，失败返回非0，并杀死，重启 initialDelaySeconds: 5 #在容器启动后多久开始进行首次 liveness 检查，这里是 5 秒 periodSeconds: 5 #定义 liveness 检查的执行周期，每隔 5 秒钟执行一次。 pod状态为running时，此时exec进入pod中删除/usr/nginx/html/下面的index.html，使用describe 查看pod状态会显示错误，过一会重启后有显示正常（重启pod会自动创建新的container，index.htm存在） tcpsocket \[root@master day07\]# cat liveness-tcp.yml apiVersion: v1 kind: Pod metadata: name: goproxy labels: app: goproxy spec: containers: - name: goproxy image: nginx ports: - containerPort: 80 livenessProbe: tcpSocket: port: 88 #定义检查端口88是否可用15s后检测失败，容器重启 initialDelaySeconds: 15 periodSeconds: 20 #### rc （ReplicationController），老版本使用，将来（1.6版本）被禁用，不支持热更新 ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。 换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。 RC通过`spec.replicas`字段设置期望的Pod副本数，并通过`spec.template`定义Pod的模板，包括容器和标签等信息，它不支持滚动更新或灰度发布 首先通过rc创建三个pod,基于nginx镜像，标签lables为app=nginx,副本数为3  查看pod状态  删除pod，测试rc是否可以维持pod个数  再次查看pod  发现pod数量不变，但是IP和node节点发生变化 #### rs （replicasets） 相当于是rc的升级 RC通过`spec.replicas`字段设置期望的Pod副本数，并通过`spec.template`定义Pod的模板，包括容器和标签等信息 #### deployment 实际上是对rs的封装和升级，通过 ReplicaSet 来管理 Pod 的副本集。 供了对Pod副本集部署和更新的声明式配置，支持滚动更新、回滚和版本控制等功能 Deployment通过`spec.replicas`字段设置期望的Pod副本数，并通过`spec.template`定义Pod的模板，与RC和RS类似。不同之处在于，Deployment还支持`spec.strategy`字段，用于定义更新策略，例如滚动更新的速率和暂停条件， 其中deployment.spec.strategy.rollingUpdate下的两个重参数 maxSurge：在滚动更新期间可以创建的额外的 Pod 的最大数量或百分比，可以是一个值或百分比 maxUnavailable：滚动更新期间可以创建的额外的 Pod 的最大数量或百分比，值或百分比 ###### deploy的更新与回滚 更新 原理，通过修改image的版本不同，curl -I ip：端口显示的nginx版本不同  查看pod创建情况，这里的镜像版本为最新  测试版本，版本为1.21.5  版本的回滚，指定版本为1.16.1 直接vim编辑配置文件修改即可 把image: nginx修改为image: nginx1.16.1,保存退出 kubectl apply -f deploy-pod.yml 此时再次测试，实现通过deployment回滚版本  版本升级与回滚类似，vim修改镜像版本即可，完成后保存退出 执行kubectl apply -f deploy-pod.yml #### service service有4中类型 ExternalName, ClusterIP, NodePort, and LoadBalancer，默认为Cluster，配置好之后只能在k8s集群内部访问，NodePort可以在集群外部访问 ###### NodePort   此时可以在浏览器上输入192.168.199.149:32054,成功访问nginx，150，151也可以 ###### ClusterIP 创建service kubectl apply -f service.yml  查看svc ###### 服务发现 service会自动通过lables发现可用的pod节点，并把节点的ip加入到endps列表中 查看svc的endpoint，把符合条件的三个pod加入到列表中  删除pod，测试service是否能自动发现新创建的pod  查看endpoints，发现service的自动发现服务正常  ###### 负载均衡 查看pod情况  为了测试负载均衡，这里修改nginx服务的html配置文件，以达到负载均衡效果  查看service  测试负载均衡 