K8S疑难概念理解——Pod,应该以哪种Kind来部署应用,为什么不直接Pod这种kind?

文章目录

一、Pod概念深度理解,为什么一般不直接以kind=Pod资源类型来部署应用?

Pod是Kubernetes中的最小部署单元,可以包含一个或多个紧密相关的容器(也就是如下yaml image可以配置不止一个,只是多数情况只配一个镜像也就是Pod里面只跑一个容器)。以nginx为例,直接部署Pod参考

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

但实际应用中很少 直接部署Kind为Pod资源类型。主要原因是Pod本身并不提供自我修复、扩展性以及滚动更新等高级功能。这些功能对于生产环境中的应用非常重要,而它们通常由控制器(如Deployment, StatefulSet, DaemonSet,Job/CronJob,RelicaSet等)来管理。 nginx应该选择以Deployment这种kind来部署,案例如下

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3  # 指定要运行的Pod副本数量
  selector:
    matchLabels:
      app: nginx  # 选择器,用于匹配Pod标签
  template:
    metadata:
      labels:
        app: nginx  # Pod的标签
    spec:
      containers:
      - name: nginx
        image: nginx:latest  # 使用最新的Nginx镜像
        ports:
        - containerPort: 80  # 容器内监听的端口

最直观的,这样部署的nginx可以方便进行扩容操作kubectl scale deployment nginx-deployment --replicas=2

二、究竟应该以哪种资源类型来部署应用

以哪种kind部署主要要看Pod里要跑什么类型的应用程序,比如上述nginx案例:
1. Deployment

  • 适用场景:适用于无状态应用,使用最广泛。
  • 特点:
    提供滚动更新和回滚功能。
    支持扩缩容。
    自动恢复失败的Pod。
    适合需要频繁更新的应用。
  • 为什么选择Deployment:
    Nginx作为Web服务器通常是无状态的,适合使用Deployment来管理。
    Deployment提供了自动扩缩容、滚动更新和自我修复等高级功能,非常适合生产环境中的Web服务。
    如果你需要对Nginx进行版本升级或配置更改,可以轻松地通过滚动更新来实现平滑过渡。
    2. StatefulSet
  • 适用场景:适用于有状态应用。
  • 特点:
    为每个Pod提供稳定的网络标识符(如DNS名称)。
    保证Pod的顺序启动和终止。
    适合需要持久存储的应用。
  • 为什么不选择StatefulSet:
    Nginx通常不需要稳定的身份标识或顺序启动,因此StatefulSet并不是最佳选择。
    StatefulSet主要用于数据库、缓存系统等有状态应用,而Nginx作为Web服务器通常是无状态的。
    3. DaemonSet
  • 适用场景:适用于需要在每个节点上运行一个副本的应用(守护)。
  • 特点:
    确保每个节点都运行一个Pod实例。
    适用于日志收集、监控代理等需要在每个节点上运行的服务。
  • 为什么不选择DaemonSet:
    除非你希望在每个节点上都运行一个Nginx实例(例如,用于本地负载均衡或代理),否则DaemonSet不是最佳选择。
    通常情况下,Nginx不需要在每个节点上运行,而是通过Service进行负载均衡。
    4. Job/CronJob
  • 适用场景:适用于一次性任务或定时任务。
  • 特点:
    Job用于执行一次性的任务。
    CronJob用于按时间计划执行的任务。
  • 为什么不选择Job/CronJob:
    Nginx是一个持续运行的服务,而不是一次性任务或定时任务,因此Job和CronJob不适合部署Nginx。
    5. ReplicaSet
  • 适用场景:直接控制一组Pod的副本数量。
  • 特点:
    直接指定Pod的副本数量。
    通常由Deployment创建和管理。
  • 为什么不选择ReplicaSet:
    虽然ReplicaSet可以控制Pod的副本数量,但它缺乏滚动更新和回滚等功能。
    通常建议使用Deployment来管理ReplicaSet,因为Deployment提供了更多的高级功能
相关推荐
lichenyang4532 天前
Docker 学习笔记(四):Dockerfile,把项目打成自己的镜像
docker·容器
lichenyang4532 天前
Docker 学习笔记(三):Docker 网络、bridge、子网和容器互通
docker·容器
lichenyang4532 天前
Docker 学习笔记(二):docker run 的参数到底在控制什么?
docker·容器
运维开发故事4 天前
基于 Arthas 的多集群在线诊断系统设计与实现
kubernetes
Patrick_Wilson6 天前
从「改个端口」到 502:Next.js on k8s 的容器端口、Service 映射与 env 覆盖
docker·kubernetes·next.js
探索云原生7 天前
K8s 1.36 这个 GA 特性,把 initContainer 拉模型的 hack 干掉了
ai·云原生·kubernetes
云恒要逆袭7 天前
运行你的第一个Docker容器
后端·docker·容器
Java之美8 天前
一次k8s升级引发的DevicePlugin注册失败
云原生·kubernetes
程序员老赵8 天前
10 分钟部署 OpenCode:Docker 一键安装,浏览器打开就能用 AI 写代码(附完整命令与排错)
docker·容器·ai编程