Kubernetes的核心对象详解

本文主要介绍了K8S常用组件概念，主要是Pod、Controller、Service、ConfigMap

1、Pod资源对象

pod概念

Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一 个进程。kubernetes中其 他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等控制器对象，用于暴露Pod应用的Service和Ingress对象，为pod提供存储的PersistentVolume存储资源对象等。

pod是什么

• pod相当于逻辑主机，每个pod都有自己的ip地址
• pod内的容器共享相同的ip和端口空间
• 默认情况下，每个容器的文件系统与其他容器完全隔离
• 可以理解为：容器组，同时pod相当于逻辑主机，进入pod后仿佛进入一个linux主机，命令都可用（linux系统下），该“主机”内又有很多容器，进入后又仿佛是又进了一个linux主机。

常见使用方式

• 一个Pod中运行一个容器。“每个Pod中一个容器"的模式是最常见的用法:在这种使用方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。
• 在一个Pod中同时运行多个容器。一个pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位， 比如一个容器共享文件，另一个"sidecar"容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。

pause容器作用

pause是pod启动的第一个进程，每个pod都会有一个pause容器，作用是可以共享两种资源:网络和存储。

• 网络:
  每个Pod都会被分配一个唯一的IP地址。Pod中的所 有容器共享网络空间，包括IP地址和端口。Pod内 部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源(例如使用宿主机的端口映射)
• 存储:
  可以Pod指定多个共享的Volume. Pod中 的所有容器都可以访问共享的Volume，Volume 也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

2.Controller

Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等。

Pod和Controller

Pod是通过Controller实现应用的运维，比如弹性伸缩、滚动更新等
Pod和Controller之间是通过label标签来建立关系，同时Controller有称为控制器工作负载

ReplicaSet

实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet。
通过Deployment去使用ReplicaSet的话我们就不需要担心和其他机制的冲突（如：ReplicaSet不支持滚动更新，但是Deployment支持）。

deployment

Deployment：这是在使用kubernetes时候，大家部署系统或者是服务经常使用的一种controller类型。因为我们可以通过它来使用ReplicaSet来为我们部署的应用进行副本的创建。
一般在实际的运用中，大家用 Deployment 做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。

Deployment控制器应用

• Deployment控制器可以部署无状态应用
• 管理Pod和ReplicaSet
• 部署，滚动升级等功能
• 应用场景： web服务，微服务

StatefuleSet

StatefulSet主要是用来部署有状态应用
对于StatefulSet中的Pod，每个Pod挂自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

适合StatefulSet的业务包括数据库服务MySQL和PostgreSQL，集群化股那里服务Zookeeper、etcd等有状态服务

有状态应用和无状态应用

无状态应用

• 认为Pod都是一样的
• 没有顺序要求
• 不考虑应用在那个node上运行
• 能够进行随意伸缩和扩展

有状态应用

• 让每一个Pod独立
• 让每一个Pod独立，保持Pod启动顺序和唯一性
• 唯一的网络标识符，持久存储
• 有序，比如MySQL的主从

3.Service

Pod对象有Pod IP地址，但是该地址无法确保Pod对象重启或者重建之后保持不变，这会带来集群中Pod应用间依赖关系维护的麻烦。比如前段Pod应用无法基于固定的IP地址跟中后端的Pod应用。
​而Service资源就是在被访问的Pod对象中添加一个有着固定IP地址的中间层，客户端向该地址发起访问请求后，由相关的Service资源进行调度并代理到后端的Pod对象。

Service 类型

ClusterIp

默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP

NodePort

在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过: NodePort来访问该服务。

虚拟IP 和服务代理

• userspace 模型
• iptables 代理模型
• ipvs 代理模型

流程定义

• 一个Service 对象就是工作节点上一些iptables 和 ipvs 规则， 用于将到达Service 对象的IP 地址调度转发至相应的 Endpoints 对象指定的IP和端口
• kube-proxy 组件通过API-server 持续监控各个Service及其联动的 Pod,并将其创建和变动反映至当前 工作节点上相应的 iptables 和 ipvs规则上

4.ConfigMap

configmap是k8s原生配置中心，可以将配置以key-value的形式传递，通常用来保存不需要加密的配置信息，加密信息则需用到Secret，主要用来应对以下场景：

1. 使用k8s部署应用，当你将应用配置写进代码中，就会存在一个问题，更新配置时也需要打包镜像，configmap可以将配置信息和docker镜像解耦。
2. 使用微服务架构的话，存在多个服务共用配置的情况，如果每个服务中单独一份配置的话，那么更新配置就很麻烦，使用configmap可以友好的进行配置共享。

其次，configmap可以用来保存单个属性，也可以用来保存配置文件。