k8s学习笔记(一)

发布于:2024-06-21 ⋅ 阅读:(65) ⋅ 点赞:(0)

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

测试负载均衡