k8s学习

一、简单了解

二、Pod的生命周期与拉取、重启策略

1.生命周期

2. 重启策略

适用于pod对象中的所有容器

3. 拉取策略

三、探针

就绪探针不会反复的进行重启，ready会变为0,但运行可能是running

存活探针会根据重启策略，来对pod中的容器进行重启。

mkdir /etc/k8s
kubectl delete -f /etc/k8s/nginx-pod.yaml
 
cat > /etc/k8s/nginx-pod.yaml <<-'EOF'
apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-nginx
spec: 
  containers: 
  - name: container-nginx
    image: nginx:latest 
    ports: 
    - containerPort: 80
  	#配置存活探针,每五秒钟执行一次探测容器80端口是否准备就绪
    #而第一次探测执行前先等待10秒，留出必要的初始化时间
    livenessProbe:
      tcpSocket:
        #port: 8080
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /abcde
        #path: /
        port: 80
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3      
EOF
 
kubectl apply -f /etc/k8s/nginx-pod.yaml
kubectl describe pod pod-nginx

在Kubernetes中，利用探针（Probes）检查Pod健康状态是一种标准化的方法，用于确保Pod内的容器处于期望的工作状态。Kubernetes提供了两种类型的探针：

1. Liveness Probe（存活探针）： 用于检测容器是否还在正常运行。如果存活探针检测失败，Kubernetes会认为容器已经进入不健康状态，kubelet会根据容器的重启策略（RestartPolicy）采取相应行动，如重启容器。这有助于自动恢复因内部错误而“卡死”但仍在运行状态的容器。

2. Readiness Probe（就绪探针）： 用于检测容器是否准备好接受流量。只有当就绪探针检测成功时，Kubernetes才会将该容器视为服务的一部分，将其纳入Service的负载均衡池。这对于确保服务只将请求路由到能够正确处理请求的容器至关重要，避免将流量导向尚未初始化完成或正在进行维护的容器。

探针可以通过以下三种方式定义和执行：

  Exec Action： 在容器内执行指定的命令，如果命令退出时返回码为0，则认为探针成功。

例如：

livenessProbe:
  exec:
    command:
    - cat
    - /healthcheck/liveness
readinessProbe:
  exec:
    command:
    - cat
    - /healthcheck/readiness

HTTP GET Action： 向容器内指定的HTTP端点发送GET请求，根据HTTP响应的状态码判断探针是否成功。可以指定超时时间（timeoutSeconds）、重试次数（periodSeconds）和初始延迟（initialDelaySeconds）：

livenessProbe:
  httpGet:
    path: /health
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: Awesome-Value
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

TCP Socket Action： 尝试连接到容器的指定TCP端口，如果能够建立连接，则认为探针成功：

livenessProbe:
  tcpSocket:
    port: 8080
readinessProbe:
  tcpSocket:
    port: 8080

思维导图

四、pod如何对外暴露

突然忘记了 master和workerNode

由k8s的无状态想到http的无状态

1.

五、部署

为什么既然保持一致，那为什么还要template,直接用selector不就行了

滚动更新的时机，通过kubectl edit deploy deploy-nginx --record ,进入配置文件，修改镜像的版本之后，会触发。  --record会将 更新的过程体现出来

操作pod的数量

进行回退后，pod的数量并不会发生改变，pod的镜像会发生改变。

八、service

kubectl   delete  svc  服务名          ps: svc是service的名称

service的IP和Port 比较固定，不像pod那样由于扩容伸缩，释放重建，灵活多变

service和pod通过selector进行绑定

但在设置时，需要设置三个port, 其中service自己设置的port可以被其他服务器进行访问（即可以在另一个工作节点：服务器  进行访问）。

画个图 把service和Node和pod的关系写出来