k8s学习

grin : (0~.~0)

已于 2024-04-25 23:45:28 修改

阅读量695

点赞数 3

文章标签： kubernetes 学习容器

于 2024-03-30 23:18:32 首次发布

本文链接：https://blog.csdn.net/qq_64071349/article/details/137186121

版权

一、简单了解

二、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提供了两种类型的探针：

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

五、部署

为什么既然保持一致，那为什么还要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的关系写出来

九、Ingress

Ingress和Ingress Controller是Kubernetes中紧密相关但职责不同的两个概念，它们之间的区别与联系如下：

Ingress：

定义： Ingress是Kubernetes的一个API资源对象，通常以YAML或JSON格式的资源配置文件创建。它是一个高层次的抽象，用来描述集群外部的HTTP(S)流量应该如何路由到内部的Service。
功能： Ingress资源定义了外部请求的路由规则，包括主机名（hostname）、URL路径（path）、后端Service、TLS配置等。这些规则告诉Kubernetes集群如何将来自外部客户端的请求映射到相应的Service。
作用： Ingress本身并不执行任何实际的流量处理或代理工作。它更像是一个配置模板，定义了集群对外暴露服务的策略和规则。

Ingress Controller：

定义： Ingress Controller是Kubernetes集群中运行的一个或一组软件组件（通常是部署为Pod），它们持续监控Ingress资源的变化，并根据Ingress的规则配置实际的负载均衡器或代理服务器。
功能：当Ingress Controller检测到Ingress资源的创建、更新或删除时，它会解析这些规则，并将其转化为实际的代理配置（如Nginx的配置文件、Envoy的路由规则等）。然后，Ingress Controller会确保这些配置被应用到其管理的负载均衡器或代理服务器上，使其能够按照Ingress定义的规则处理外部请求。
作用： Ingress Controller是Ingress规则的执行者，它实现了Ingress资源的语义，负责将抽象的路由规则转化为实际的网络流量处理逻辑。常见的Ingress Controller实现包括Nginx Ingress Controller、Traefik、Contour、Istio等。

联系与区别总结：

联系： Ingress和Ingress Controller共同构成了Kubernetes的外部访问管理机制。Ingress定义了流量路由规则，而Ingress Controller负责将这些规则转化为实际的网络配置，并确保这些配置在负载均衡器或代理服务器上生效。两者相互配合，使得Kubernetes能够透明地将外部请求路由到集群内的Service。
区别：
- 角色：Ingress是配置层面的抽象，描述了路由规则；Ingress Controller是执行层面的组件，负责实现这些规则。
- 操作：用户直接操作和管理的是Ingress资源；Ingress Controller则是自动响应Ingress变化，无需用户直接干预。
- 生命周期：Ingress资源的创建、更新、删除由用户通过Kubernetes API完成；Ingress Controller的部署、升级、维护则属于集群基础设施的一部分，通常由运维人员管理。

总的来说，Ingress和Ingress Controller分工明确，前者负责定义路由策略，后者负责实现这些策略，它们共同构建了Kubernetes集群对外提供HTTP(S)服务的统一入口和管理机制。

十、无头服务

用于内部访问其他节点。

十一、 PV

让多个pod共享同一个文件

容器内部产生数据