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

测试负载均衡