k8s之Deployment、PodTemplate与容器的关系

Kubernetes中Deployment、PodTemplate与容器的关系

这三者在Kubernetes中是层层嵌套的关系,可以用"套娃"模型来理解:

1. 核心关系图示

Deployment (管理应用部署)
│
└── PodTemplate (定义Pod的模板)
    │
    └── 容器 (实际运行的应用)

2. 具体关系解析

Deployment (部署控制器)

  • 作用:声明应用的期望状态(要运行多少副本、用什么镜像等)
  • 关键能力:滚动更新、回滚、扩缩容
  • 包含:一个PodTemplate + 副本数等配置

PodTemplate (Pod模板)

  • 位置:在Deployment的spec.template字段中
  • 作用:定义要创建的Pod的"模具"
  • 包含
    • 容器定义(1个或多个)
    • 存储卷配置
    • 网络设置
    • 节点选择规则等

容器 (Container)

  • 位置:在PodTemplate的spec.containers数组中
  • 作用:实际运行应用程序的隔离环境
  • 包含
    • 容器镜像
    • 环境变量
    • 资源限制
    • 端口配置等

3. 工作流程示例

当创建一个Deployment时:

  1. 用户定义Deployment(包含PodTemplate)

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deploy
    spec:
      replicas: 3  # 要创建3个Pod
      template:    # 这就是PodTemplate
        spec:
          containers:
          - name: nginx
            image: nginx:1.19
            ports:
            - containerPort: 80
    
  2. Deployment控制器

    • 读取PodTemplate
    • 创建3个相同的Pod(每个Pod里运行1个nginx容器)
  3. kubelet

    • 在每个节点上拉取nginx:1.19镜像
    • 创建并运行容器

4. 三者关系特点

对象生命周期是否直接创建主要作用
Deployment长期存在应用部署管理
PodTemplate随Deployment存在定义Pod的创建规则
容器随Pod存在实际运行应用进程

5. 实际应用中的体现

  • 修改镜像版本:改的是PodTemplate中的容器定义

    kubectl set image deployment/nginx-deploy nginx=nginx:1.20
    
  • 扩容:改的是Deployment的replicas,不影响PodTemplate

    kubectl scale deployment nginx-deploy --replicas=5
    
  • 查看关系

    # 查看Deployment的PodTemplate
    kubectl get deployment nginx-deploy -o yaml | grep -A10 "template:"
    
    # 查看Pod中的容器
    kubectl get pods -l app=nginx -o yaml | grep -A5 "containers:"
    

简单记忆法

把这三者想象成工厂生产:

  • Deployment是生产主管(决定生产多少)
  • PodTemplate是产品设计图(决定产品长什么样)
  • 容器是最终产品里的核心部件
### Kubernetes 中 Pod、Deployment、Service 和 Ingress 的作用配置方法 在 Kubernetes 中,Pod、Deployment、Service 和 Ingress 是构建和管理容器化应用的核心组件,它们各自承担不同的职责,并在项目部署交付中形成完整的链路。 #### Pod:容器运行的最小单元 Pod 是 Kubernetes 中最小的可部署单元,包含一个或多个共享资源的容器。每个 Pod 代表一个运行实例,通常用于承载应用的容器化服务。Pod 的生命周期是短暂的,当 Pod 被删除或节点故障时,Pod 会终止,其状态不会被保留。 ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 ``` #### Deployment:实现应用的声明式管理和滚动更新 Deployment 用于管理 Pod 的副本集(ReplicaSet),实现应用的自动扩缩容、滚动更新和版本回滚。通过定义期望状态,Kubernetes 会确保实际状态期望一致,从而实现高可用和自愈能力。 ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 ``` #### Service:实现 Pod 的网络访问负载均衡 Service 为一组 Pod 提供稳定的网络访问入口,并实现负载均衡。即使 Pod 发生变化,Service 的 IP 和端口保持不变,确保外部访问的稳定性。Service 通过标签选择器(selector)关联到对应的 Pod。 ```yaml apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 ``` #### Ingress:实现外部 HTTP/HTTPS 路由管理 Ingress 是 Kubernetes 中用于管理外部访问的 API 资源,通常 Ingress Controller(如 Nginx Ingress Controller)配合使用,提供基于路径或域名的路由规则,将外部请求转发到对应的 Service。Ingress 支持 SSL 终止、路径重写、虚拟主机等功能,适用于对外暴露 Web 服务。 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /app pathType: Prefix backend: service: name: nginx-service port: number: 80 ``` ### 各组件在项目部署交付中的关系 在项目部署交付过程中,Pod、Deployment、Service 和 Ingress 各司其职,形成完整的部署链路。Deployment 负责 Pod 的创建管理,确保应用的可用性;Service 为 Pod 提供稳定的访问地址;Ingress 则作为外部访问的统一入口,提供基于路径或域名的路由控制。这种分层结构使得应用部署具备良好的可维护性、扩展性和安全性。 在实际部署中,通常先定义 Deployment 来管理 Pod,再通过 Service 暴露服务,最后使用 Ingress 对外提供访问路径。这种模式广泛应用于微服务架构和云原生项目的交付中,提升了部署的灵活性和可维护性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值