kubernetes-pod介绍、service资源介绍、部署并访问应用的流量访问

wffeige
147 阅读5分钟

好文章 # 为什么我们需要Pod？ time.geekbang.org/column/arti…

kubernets 是什么? (声名式API)

  • Platform for Platform 本身就是一个平台, 他的功能是去构建其他的平台
  • 底层化能力
    • 可以纳管底层基础设施类的服务
    • kubernets 可以将Kafka的功能 封装成API 对外暴露服务
  • 容器的编排功能
  • 服务网格平台的底层设施

展开讲 软件系统组成部分

  • OS + 硬件
  • 基础设施类服务
    • 中间件服务, 支持业务组件协同的服务 go/c/c++ 开发的
    • Kafka、mysql、redis
  • 业务软件、业务应用 java/python程序
    • 自己开发的软件 应用

image.png

Pod介绍

image.png

Pod是Kubernetes中可以调度的最小逻辑单元 Kubernetes本质上是“以应用为中心”的现代应用基础设施，

本质上是共享Network、IPC和UTS名称空间以及存储资源的容器集

  • 可将其想象成一台物理机或虚拟机，各容器就是该主机上的进程
  • 同一POD中的各容器共享网络协议栈、网络设备、路由、IP地址和端口
  • 同一POD中的各容器Mount、PID和USER 是隔离的
  • 每个Pod上还可附加N个“存储卷（Volume）”作为该“主机”的外部存储，独立于Pod的生命周期，可由Pod内的各容器共享

Pod是运行应用的原子单元，其生命周期管理和健康状态监测由kubelet负责完成，而诸如更新、扩缩容和重建等应用编排功能需要由专用的控制器实现，这类控制器即工作负载型控制器

  • ReplicaSet和Deployment 无状态
  • DaemonSet 系统应用使用
  • StatefulSet 有状态应用
  • Job和CronJob 作业类的应用

模拟“不可变基础设施” ，删除后可通过资源清单重建

  • 具有动态性，可容忍误删除或主机故障等异常
  • 存储卷可以确保数据能超越Pod的生命周期

pod 的组织原则

在设计上，仅应该将具有“超亲密”关系的应用分别以不同 容器的形式运行于同一Pod内部

linux mysql nginx php不是超亲密关系 tomcat 日志收集(fluted)是超亲密关系 mysql mysql_exporter(promethues)是超亲密关系

Pause容器介绍

创建POD时, 需要Network、IPC和UTS namespace 给到Pause容器, 创建的POD共享 Pause容器的namespace

image.png

service资源介绍

什么是service?

service 通过标签选择器 识别和发现 关联后端的pod, 提供一个固定的访问地址 通过service实现负载均衡

为什么要设计Service资源？

Pod具有动态性，其IP地址也会在基于配置清单重构后重新进行分配，因而需要服务发现机制的支撑

image.png

POD被删除后 可以 通过创建新的pod 然后关联到volume 从而恢复此前的服务 image.png

service的基础工作逻辑??

Pod和工作负载型控制器

image.png

工作负载型控制器的工作重心

  • 确保选定的Pod精确符合期望的数量
    • 数量不足时依据 Pod模板 创建
    • 超出时销毁多余的对象
  • 按配置定义进行扩容和缩容
    • 通过replicas副本数控制
  • 依照策略和配置进行应用更新
  • 调谐循环 对比监控 用户定义的POD属性 和实际运行的状态
  • 标签选择器 通过pod上的lable进行选择

展开的概念

API server是restful风格的API(http协议)

面向对象

- 抽象为类型 由多个字段
- 每个字段都描述该该实例的一个纬度的属性
- 资源类型可以 实例化 成一个对象

声明式API

- 仅需要定义出对象的终态 不需要关心中间的过程 全部交给系统来完成

举例 人 + 车 --->上海

  • 面向终态(对象)
    • 自动驾驶到上海 车自己走 只需要告诉它 你期望的结果
    • 车有特定领域的智能
  • 面向过程
    • 自己开车 导航 实现途中的每一个步骤

所有的资源类型都是声明式的 需要底层的Controller支撑

部署并访问应用

image.png

Kubernetes上部署应用的常规逻辑

创建pod的工作流:

apiserver接收请求 scheduler 调度选择node kublet 负责把pod拉起来

step1 依照编排需求，选定合适类型的 工作负载型控制器

  • ReplicaSet和Deployment 无状态应用
  • DaemonSet 系统应用
  • StatefulSet 有状态应用
  • Job和CronJob 作业类的应用

step2 创建 工作负载型控制器 对象，由其确保、运行合适数量的Pod对象

  • (loop循环 参考pod模版 检查实际pod数量是否满足模版要求)

step3 创建Service对象，为该组Pod对象提供固定的访问入

- 服务发现
- 负载均衡 注册给标签选择器

请求访问Service对象上的服务 有两个分支

image.png

南北向流量: 集群外部和集群内部通信的流量 流入流出集群的流量

东西向流量: 集群内的流量 pod之间的流量

内部访问

  • 集群内部的通信流量也称为东西向流量，客户端也是集群上的Pod对象；
  • 内部的客户端(某个pod) 直接访问service对象

外部访问

  • 集群外部访问
    • 外部client -->node --> service对象 --> pod对象
    • 外部client --ingress --> pod对象
  • Service同集群外部的客户端之间的通信流量称为南北向流量，客户端是集群外部的进程；
    • 另外，集群上的Pod也可能会与集群外部的服务进程通信
avatar
文章
阅读
粉丝