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
测试负载均衡
