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提供了更多的高级功能
相关推荐
我没有开挂22 分钟前
旧 docker 版本通过 nvkind 搭建虚拟多节点 gpu 集群的坑
运维·docker·容器
小鸡,啄米1 小时前
centos9安装docker 配置docker代理
运维·docker·容器
oceanweave1 小时前
【K8S学习之生命周期钩子】详细了解 postStart 和 preStop 生命周期钩子
学习·kubernetes
小锋学长生活大爆炸7 小时前
【教程】Docker更换存储位置
运维·docker·容器
gnufre8 小时前
Kubernetes 1.28 无 Docker 运行时环境下的容器化构建实践:Kaniko + Jenkins 全链路详解
kubernetes·jenkins·kaniko
川石教育11 小时前
测试工程师如何学会Kubernetes(k8s)容器知识
云原生·容器·kubernetes·kubernetes容器·kubernetes教程
iRayCheung12 小时前
Kind方式部署k8s单节点集群并创建nginx服务对外访问
nginx·kubernetes·kind
小黑_深呼吸13 小时前
Prometheus实战教程:k8s平台-Mysql监控案例
运维·学习·kubernetes·prometheus
THMAIL13 小时前
mac M芯片运行docker-desktop异常问题
macos·docker·容器
家庭云计算专家14 小时前
还没用过智能文档编辑器吗?带有AI插件的ONLYOFFICE介绍
服务器·人工智能·docker·容器·编辑器