【云原生】k8s核心概念—Pod & Controller & Service & Serect & ConfigMap介绍——20230213

一、Pod

1. pod概述

Pod 是 k8s 系统中可以创建和管理的最小单元,是资源对象模型中由用户创建或部署的最小资源对象模型,也是在 k8s 上运行容器化应用的资源对象,其他的资源对象都是用来支撑或者扩展 Pod 对象功能的,比如控制器对象是用来管控 Pod 对象的,Service 或者Ingress 资源对象是用来暴露 Pod 引用对象的,PersistentVolume 资源对象是用来为 Pod提供存储等等,k8s 不会直接处理容器,而是 Pod。Pod 是由一个或多个 container 组成。

每一个 Pod 都有一个特殊的被称为”根容器“的 Pause容器。Pause 容器对应的镜 像属于 Kubernetes 平台的一部分,除了 Pause 容器,每个 Pod还包含一个或多个紧密相关的用户业务容器,如下图。
在这里插入图片描述

POD特性:

    1. 资源共享
      一个 Pod 里的多个容器可以共享存储和网络,可以看作一个逻辑的主机。共享的如namespace,cgroups 或者其他的隔离资源。
      多个容器共享同一 network namespace,由此在一个 Pod 里的多个容器共享 Pod 的 IP 和端口 namespace,所以一个 Pod 内的多个容器之间可以通过 localhost 来进行通信,所需要注意的是不同容器要注意不要有端口冲突即可。不同的 Pod 有不同的 IP,不同 Pod 内的多个容器之前通信,不可以使用 IPC(如果没有特殊指定的话)通信,通常情况下使用 Pod的 IP 进行通信。
      一个 Pod 里的多个容器可以共享存储卷,这个存储卷会被定义为 Pod 的一部分,并且可以挂载到该 Pod 里的所有容器的文件系统上。
    1. 生命周期短暂
      Pod 属于生命周期比较短暂的组件,比如,当 Pod 所在节点发生故障,那么该节点上的 Pod会被调度到其他节点,但需要注意的是,被重新调度的 Pod 是一个全新的 Pod,跟之前的Pod 没有半毛钱关系。
    1. 平坦的网络
      K8s 集群中的所有 Pod 都在同一个共享网络地址空间中,也就是说每个 Pod 都可以通过其他 Pod 的 IP 地址来实现访问。

总结:

  • 最小部署单元
  • 包含多个容器(一组容器的集合)
  • 一个pod中容器共享网络命名空间(NameSpace)
  • pod是短暂的

(1)Pod vs 应用
每个 Pod 都是应用的一个实例,有专用的 IP。
(2)Pod vs 容器
一个 Pod 可以有多个容器,彼此间共享网络和存储资源,每个 Pod 中有一个 Pause 容器保存所有的容器状态, 通过管理 pause 容器,达到管理 pod 中所有容器的效果。
(3)Pod vs 节点
同一个 Pod 中的容器总会被调度到相同 Node 节点,不同节点间 Pod 的通信基于虚拟二层网络技术实现。
(4)Pod vs Pod
普通的 Pod 和静态 Pod。

①普通 Pod
普通 Pod 一旦被创建,就会被放入到 etcd 中存储,随后会被 Kubernetes Master 调度到某个具体的 Node 上并进行绑定,随后该 Pod 对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动起来。在默认情 况下,当 Pod 里某个容器停止时,Kubernetes 会自动检测到这个问题并且重新启动这个 Pod 里某所有容器, 如果 Pod 所在的 Node 宕机,则会将这个 Node 上的所有 Pod 重新调度到其它节点上。
②静态 Pod
静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod,它们不能通过 API Server进行管理,无法与 ReplicationController、Deployment 或 DaemonSet 进行关联,并且kubelet 也无法对它们进行健康检查。

2. pod存在意义

  1. 创建容器使用docker,一个docker对应的是一个容器,一个容器有进程,一个容器运行一个应用程序

  2. pod是多进程设计,运行多个应用程序
    一个pod有多个容器,一个容器里面运行一个应用程序
    原因参考这篇文章

  3. pod存在为了亲密性
    ①两个应用之间进行交互
    ②网络之间调用
    ③两个应用需要频繁调用

3. Pod实现机制

1)共享网络
通过Pause容器,把其他业务容器加入到Pause容器里面,让所有业务容器在同一个namespace中,从而实现网络共享。

  • pod实现共享网络机制

①创建Pause容器(也叫info容器,也叫根容器)
②创建业务容器1,2,……
③业务容器一次加入到info容器(pause容器)中,创建出独有的IP,mac地址,port
使得所有业务容器在同一个namespace中,实现网络共享。
在这里插入图片描述

2)共享存储
通过引用数据卷概念Volumn,使用数据卷进行持久化存储

  • pod实现共享存储机制

现有2个node节点
①node1中pod产生的数据会存储到数据卷中持久化存储
②node1宕机/挂掉后
③node1中的pod会到node2中继续运行,通过读取数据卷中存储的数据
从而实现持久化存储。

在这里插入图片描述

4. pod镜像拉取策略

在这里插入图片描述

5. pod资源限制

在这里插入图片描述

6. pod重启机制

以nginx为例,假如说我们现在创建了一个nginx服务,nginx在node1上运行,且未对nginx产生的数据做持久化存储(没有挂载)。如果因为某种情况使得node1宕机,nginx服务会被调度到node2上运行,相当于重新在node2上创建pod,这时候就需要重新拉取新的nginx镜像,重新部署nginx服务,node2里面也就没有nginx之前的数据了。
原因是因为配置文件中“imagePullPolicy:Always”这个设定。
在这里插入图片描述

7. pod健康检查

在这里插入图片描述

8. 创建pod流程

在这里插入图片描述

9. pod调度

  • 影响调度的属性
  1. pod资源限制对pod调度产生影响每个 Pod 都可以对其能使用的服务器上的计算资源设置限额,Kubernetes 中可以设置限额
    的计算资源有 CPU 与 Memory 两种,其中 CPU 的资源单位为 CPU 数量,是一个绝对值而非相对值。Memory 配额也是一个绝对值,它的单 位是内存字节数。

Kubernetes 里,一个计算资源进行配额限定需要设定以下两个参数: Requests 该资源最小申请数量,系统必须满足要求 Limits 该资源最大允许使用的量,不能突破,当容器试图使用超过这个量的资源时,可能会被 Kubernetes Kill 并重启

  1. 节点选择器标签影响pod调度
    在这里插入图片描述
    节点选择器工作流程⬇
    在这里插入图片描述
  2. 节点亲和性影响pod调度
    节点亲和性 nodeAffinity 和之前 nodeSelector 基本一样的,根据节点上标签约束来绝对pod调度到哪些节点上。

在这里插入图片描述

  1. 污点和污点容忍
    在这里插入图片描述
    在这里插入图片描述

二、Controller

1. 什么是Controller

在集群上管理和运行容器的对象

2. Pod和Controller关系

(1)Pod是通过Controller实现应用的运维,比如伸缩、滚动升级等等
(2)Pod和Controller之间通过label标签关系

3. deployment应用场景

(1)部署无状态应用
(2)管理Pod和ReplicaSet
(3)部署,滚动升级等功能
应用场景:web服务,微服务

4. 使用deployment部署应用(yaml)

# 第一步:导出yaml文件
kubectl create deployment web --image=nginx --dry-run -o yaml > web.yaml
# 第二部:使用yaml部署应用
kubectl apply -f web.yaml
# 第三部:对外发布(暴露对外端口号)
kubectl expose deployment web --port=80 --target-port=80 --type=NodePort --name=web1 -o yaml > web1.yaml
kubectl apply -f web1.yaml
kubectl get pods,svc
# ip+端口能否访问nginx

5. 应用升级回滚和弹性伸缩

# 应用升级
kubectl set image deployment web nginx=nginx:1.15

# 查看升级状态
kuectl rollout status deployment web

# 查看升级版本
kubectl rollout history deployment web

# 回滚到上一个版本
kubectl rollout undo deployment web

# 回滚到指定版本
kubectl rollout undo deployment web --to-revision=2

# 弹性伸缩
kubectl scale deployment web --replicas=10

6. StatefulSet 部署有状态应用——无状态和有状态

(1)无状态:
①认为Pod都是一样的
②没有顺序要求
③不用考虑在哪个node运行
④随意进行伸缩和扩展
(2)有状态
上面因素都要考虑到
①让每个Pod都是独立的,保持pod启动顺序和唯一性
②唯一的网络标识符,持久储存
③有序,比如MySQL主从

7. 部署有状态应用

  • 无头service:通俗讲就是将ClusterIP值设为none,即ClusterIP:none
    (1)StatefulSet部署有状态应用
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

8. 部署守护进程DaemonSet

(1)在每个node上运行一个pod,新加入的node也同样在一个pod里面
例子:在每个node节点安装数据采集工具
在这里插入图片描述

9. job(一次性任务)

10. cronjob(定时任务)

三、service

1. Service存在意义

(1)防止Pod失联(服务发现)
(2)定义一组Pod访问策略(负载均衡)

在这里插入图片描述

2. Pod和Service关系

根据label和selector标签建立关联
在这里插入图片描述

3. 常用Service类型

(1)ClusterIP:集群内部使用
(2)NodePort:对外访问应用使用
(3)LoadBalancer:对外访问应用使用,公有云

node内网部署应用,外网一般不能访问到的

  • 找到一台可以进行外网访问机器,安装nginx,反向代理
    ** 手工把可以访问节点添加到nginx里面
    LoadBalancer:公有云,把负载均衡,控制器

四、配置管理—Serect

作用:加密数据,存在etcd里面,让pod容器以挂载Volume方式进行访问。
场景:凭证

  1. 创建serect加密数据
    在这里插入图片描述
  2. 以变量形式挂载到容器中
    kubectl exec:在指定容器内执行命令
    在这里插入图片描述
  3. 以Volume形式挂在到Pod容器中
    在这里插入图片描述

五、配置管理—ConfigMap

作用:存储不加密数据到etcd,以变量或者Volume挂载到pod容器中。
场景:配置文件

  1. 创建配置文件
  2. 创建configmap
    在这里插入图片描述
  3. 以Volume挂载到pod容器中
    在这里插入图片描述
  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我是小bā吖

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值