一、容器组Pod

1、Pod基础

在Kubernetes中，并不直接操作容器，最小的管理单位是容器组(Pod)。容器组由一个或多个容器组成，Kubernetes围绕容器组进行创建、调度、停止等生命周期管理；
同一个容器组中，各个容器共享命名空间；
每个Pod都有一个特殊的被称为”根容器”的Pause容器；
K8S为每个Pod都分配了唯一的IP地址，称之为PodIP，一个Pod里多个容器共享PodIP地址；
K8S要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信；
Pod其实有两种类型：

  1. 普通的Pod和静态的Pod(static Pod)，后者比较特殊，它并不存放在K8S
  2. 的etcd存储里，而是存放在某个具体的Node上的某个具体的文件里，并
  3. 且只在此Node上运行；普通的Pod一旦被创建，就会被放入到etcd中存储
  4. ，随后被K8SMaster调度到某个具体的Node上并进行绑定，该Pod被对应的
  5. Node上的kubelet进程实例化成一组相关的Docker容器并启动起来。在默
  6. 认情况下，当Pod里的某个容器停止时，K8S会自动检测到这个问题并重
  7. 新启动这个Pod(重启Pod里的所有容器)，如果Pod所在的Node宕机，则会
  8. 将这个Node上的所有Pod重新调度上其他节点上。

Pod、容器与Node的关系如下图：

资源对象 - 图1

$ kubectl describe pod podName // 查看pod的描述信息，可定位问题原因

2、Pod资源

每个Pod都可以对其能使用的服务器上的资源设置限额，当前可以设置的限额包括：CPU和Memory，其中CPU的资源单位为CPU(Core)的数量，是一个绝对值而非相对值。

CPU

一个CPU的配额对于绝大多数容器来说是相当大的一个资源配额了，所以在K8S中，通常以千分之一的CPU配额为最小单位，用m来表示。通常一个容器的CPU配额被定义为100 ~ 300m，即占用0.1 ~ 0.3个CPU。

Memory

Memory配额也是一个绝对值，它的单位是内存字节数。

在K8S里，一个计算资源进行配额限定需要设置一下两个参数：

  • Requests：该资源的最小申请量，系统必须满足要求
  • Limits：该资源最大允许使用的量，不能被突破，当容器尝试使用超过这个量的资源时，可能会被K8S Kill并重启。

例如：

spec:
    containers:
        -name: db
            image: mysql
            resources:
                requests:
                    memory: "64Mi"
                    cpu: "250m"
                limits:
                    memory: "128Mi"
                    cpu: "500m"

二、Replication Controller(RC)

RC是K8S系统中的核心概念之一，包括如下几个部分：

  • Pod期待的副本数(replicas)
  • 用于筛选目标Pod的Label Selector
  • 当Pod的副本数量小预期数量的时候，用于创建新Pod的Pod模板(template)

当我们定义个一个RC并提交到K8S集群中以后，Master节点上的Controller Manager组件就得到通知，定义巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，如果有过多的Pod副本在运行，系统就会停掉一些Pod，否则系统就会再自动创建一些Pod。通过RC，K8S实现了用户应用集群的高可用行。
在运行时，可以通过命令修改RC的副本数量，来实现Pod的动态缩放：

$ kubectl scale rc redis-slave --replicas=3

注意：

删除RC并不会影响通过该RC已经创建好的Pod，为了删除所有的Pod，
可以设置replicat=0，然后更新该RC。另外，kubectl提供了stop和
delete命令来一次性删除RC和RC控制的全部Pod。

RC升级历程：
RC -> Replica Set -> Deployment(负责一整套Pod创建、删除、更新的编排机制)

三、Deployment

Deployment是对RC的一次升级，替代了RC和Replica Set。
Deployment相对于RC的一个最大的升级是我们可以随时知道当前Pod”部署”的进度。

典型使用场景：

  • 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程
  • 检车Deployment的状态来看部署动作是否完成
  • 更新Deployment以创建新的Pod
  • 如果当前Deployment不稳定，则回滚到一个早先的Deployment版本
  • 挂起或者恢复一个Deployment
$ kubectl get deployments   // 查看deployment信息
- DESIRED: Pod副本数量的期望值，即Deployment里定义的Replica
- CURRENT: 当前Replica的值
- UP-TO-DATE: 最新版本的Pod的副本数量，用于指示在滚动升级的过程中，有多少个Pod副本已经成功升级
- AVAILABLE: 当前集群中可用的Pod副本数量

$ kubectl get rs    // 查看与Deployment有关的Replica Set
$ kubectl get pods  // 查看Replica Set 创建了那些Pod

四、Horizontal Pod Autoscaler(HPA)：目前还在实验，不建议生产环境使用

横向自动扩容，当前HPA有一下两种方式作为Pod负载的度量指标：

  • CPUUtilizationPercentage：算术平均值，即目标Pod所有副本本身的CPU利用率的平均值
一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod
Request的值，比如我们定义一个Pod的Pod Request为0.4，而当
前Pod的CPU使用量为0.2，则CPU利用率为50%
  • 应用程序自定义的度量指标，比如：QPS、TPS

五、Service

1、概述

K8S的Service定义了一个服务的访问入口地址，前端应用的Pod通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端的Pod副本集群之间通过Label Selector来实现无缝对接；而RC的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准；

2、K8S的服务发现机制

K8S通过Add-On增值包的方式引入了DNS系统，把服务名作为DNS域名，这样一来，程序就可以直接使用服务名来建立通信连接了。

3、外部系统访问Service的问题

三种IP地址：

  • Node IP：Node节点的IP地址
真是存在的物理机地址
  • Pod IP：Pod的IP地址
虚拟的二层网络地址
  • Cluster IP：Service的IP地址
虚拟的IP

通过将Service的端口映射到Node的端口上，然后对外提供服务