从零开始的云计算生活——第四十三天，激流勇进，kubernetes模块之Pod资源对象

Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的容器总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。你也可以在集群支持临时性容器的情况下，为调试的目的注入临时性容器。

Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，即用来隔离容器的技术。在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。

Pod 类似于共享名字空间并共享文件系统卷的一组容器。

三.K8S-组件介绍

1.概述

Kubernetes 简称 k8s，是支持云原生部署的一个平台，起源于谷歌。谷歌早在十几年之前就对其应用，通过容器方式进行部署。

k8s 本质上就是用来简化微服务的开发和部署的，关注点包括自愈和自动伸缩、调度和发布、调用链监控、配置管理、Metrics 监控、日志监控、弹性和容错、API 管理、服务安全等，k8s 将这些微服务的公共关注点以组件形式封装打包到 k8s 这个大平台中，让开发人员在开发微服务时专注于业务逻辑的实现，而不需要去特别关心微服务底层的这些公共关注点，大大简化了微服务应用的开发和部署，提高了开发效率。

K8S的由来

K8S由google的Borg系统(博格系统，google内部使用的大规模容器编排工具)作为原型，后经GO语言延用Borg的思路重写并捐献给CNCF基金会开源。
云原生基金会（CNCF）于2015年12月成立，隶属于Linux基金会。CNCF孵化的第一个项目就是Kubernetes，随着容器的广泛使用，Kubernetes已经成为容器编排工具的事实标准。

K8S的功能

跨主机编排容器。
更充分地利用硬件资源来最大化地满足企业应用的需求。
控制与自动化应用的部署与升级。
为有状态的应用程序挂载和添加存储器。
线上扩展或缩减容器化应用程序与它们的资源。
声明式的容器管理，保证所部署的应用按照我们部署的方式运作。
通过自动布局、自动重启、自动复制、自动伸缩实现应用的状态检查与自我修复。
为多个容器提供服务发现和负载均衡，使得用户无需考虑容器IP问题。

K8S解决的问题

K8S 解决了裸跑 Docker 的若干痛点：

单机使用，无法有效集群
随着容器数量的上升，管理成本攀升
没有有效的容灾、自愈机制
没有预设编排模板，无法实现快速、大规模容器调度
没有统一的配置管理中心工具
没有容器生命周期的管理工具
没有图形化运维管理工具

K8S 提供了容器编排，资源调度，弹性伸缩，部署管理，服务发现等一系列功能。

K8S的特性

弹性伸缩

使用命令、UI 或者基于 CPU 使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

自我修复

在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

自动发布（默认滚动发布模式）和回滚

K8S 采用滚动更新策略更新应用，一次更新一个 Pod，而不是同时删除所有 Pod，如果更新过程中出现问题，将回滚更改，确保升级不影响业务。

集中化配置管理和密钥管理

管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在 K8S 中，方便应用程序使用。

存储编排，支持外挂存储并对外挂存储资源进行编排

挂载外部存储系统，无论是来自本地存储，公有云（如 AWS），还是网络存储（如 NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。

任务批处理运行

提供一次性任务，定时任务；满足批量数据处理和分析的场景。

2.K8S架构与组件

K8S架构

k8s 总体架构采用了经典的 maste/slave 架构模式，分 master 节点和 worker 节点，节点可以是虚拟机也可以是物理机。

K8S组件

master 节点组件

Kube-apiserver

用于暴露 Kubernetes API，任何资源请求或调用操作都是通过 kube-apiserver 提供的接口进行。以 HTTPRestful API 提供接口服务，所有对象资源的增删改查和监听操作都交给 API Server 处理后再提交给 Etcd 存储。
可以理解成 API Server 是 K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI命令行工具），然后根据用户的具体请求，去通知其他组件干活。可以说 API Server 是 K8S 集群架构的大脑。

Kube-controller-manager

运行管理控制器，是 K8S 集群中处理常规任务的后台线程，是 K8S 集群里所有资源对象的自动化控制中心。在 K8S 集群中，一个资源对应一个控制器，而 Controller manager 就是负责管理这些控制器的。
由一系列控制器组成，通过 API Server 监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个 Node意外宕机时，Controller Manager 会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

控制器类型	作用
Node Controller（节点控制器）	负责在节点出现故障时发现和响应。
Replication Controller（副本控制器）	负责保证集群中一个 RC（资源对象 Replication Controller）所关联的 Pod 副本数始终保持预设值。可以理解成确保集群中有且仅有 N 个 Pod 实例，N 是 RC 中定义的 Pod 副本数量。
EndpointsController（端点控制器）	填充端点对象（即连接 Services 和 Pods），负责监听 Service 和对应的 Pod副本的变化。可以理解端点是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道它的 endpoint。
Service Account & Token Controllers（服务帐户和令牌控制器）	为新的命名空间创建默认帐户和 API 访问令牌。
ResourceQuota Controller（资源配额控制器）	确保指定的资源对象在任何时候都不会超量占用系统物理资源。
Namespace Controller（命名空间控制器）	管理 namespace 的生命周期。
Service Controller（服务控制器）	属于 K8S 集群与外部的云平台之间的一个接口控制器。

Kube-scheduler

是负责资源调度的进程，根据调度算法为新创建的 Pod 选择一个合适的 Node 节点。
可以理解成 K8S 所有 Node 节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的 Node 节点来部署 Pod。
预选策略（predicate）
优选策略（priorities）

etcd

K8S 的存储服务。etcd 是分布式键值存储系统，存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据。

node节点组件

在 Kubernetes 集群中，在每个 Node（又称 Worker Node）上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器。每个 kubelet 进程都会在 API Server 上注册节点自身的信息，定期向 Master 汇报节点资源的使用情况，并通过 cAdvisor 监控容器和节点资源。

Kubelet

Node 节点的监视器，以及与 Master 节点的通讯器。Kubelet 是 Master 节点安插在 Node 节点上的“眼线”，它会定时向 API Server 汇报自己 Node 节点上运行的服务的状态，并接受来自 Master 节点的指示采取调整措施。
从 Master 节点获取自己节点上 Pod 的期望状态（比如运行什么容器、运行的副本数量、网络或者存储如何配置等），直接跟容器引擎交互实现容器的生命周期管理，如果自己节点上 Pod 的状态与期望状态不一致，则调用对应的容器平台接口（即 docker 的接口）达到这个状态。
管理镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源。

Kube-Proxy

在每个 Node 节点上实现 Pod 网络代理，是 Kubernetes Service 资源的载体，负责维护网络规则和四层负载均衡工作。负责写入规则至iptables、ipvs实现服务映射访问的。
Kube-Proxy 本身不是直接给 Pod 提供网络，Pod 的网络是由 Kubelet 提供的，Kube-Proxy 实际上维护的是虚拟的 Pod 集群网络。
Kube-apiserver 通过监控 Kube-Proxy 进行对 Kubernetes Service 的更新和端点的维护。
在 K8S 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都会运行一个 Kube-proxy 组件。

Controller Runtime

容器引擎，如：docker、containerd，运行容器，负责本机的容器创建和管理工作。
当 kubernetes 把 pod 调度到节点上，节点上的 kubelet会指示 docker 启动特定的容器。接着，kubelet 会通过 docker 持续地收集容器的信息，然后提交到主节点上。docker 会如往常一样拉取容器镜像、启动或停止容器。不同点仅仅在于这是由自动化系统控制而非管理员在每个节点上手动操作的。

Pod

k8s 中特有的一个概念，可以理解为对容器的包装，是 k8s 的基本调度单位，一个 Pod 代表集群上正在运行的一个进程，实际的容器是运行在 Pod 中的，可以把 Pod 理解成豌豆荚，而同一 Pod 内的每个容器是一颗颗豌豆。一个节点可以启动一个或多个 Pod。生产环境中一般都是单个容器或者具有强关联互补的多个容器组成一个 Pod。

四.POD创建过程（重要）

第一步：客户端提交创建Pod的请求，可以通过调用API Server的Rest API接口，也可以通过kubectl命令行工具。如kubectl apply -f filename.yaml(资源清单文件)

第二步： apiserver接收到pod创建请求后，会将yaml中的属性信息(metadata)写入etcd。

第三步： apiserver触发watch机制准备创建pod，信息转发给调度器scheduler，调度器用一组规则过滤掉不符合要求的主机，比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。调度器使用调度算法选择node，调度器将node信息给apiserver，apiserver将绑定的node信息写入etcd。

第四步： apiserver又通过watch机制，调用kubelet，指定pod信息，调用Docker API创建并启动pod内的容器。

第五步： worker创建完成之后反馈给自身的kubelet, 再反馈给控制器的kubelet，然后将pod的状态信息给apiserver,apiserver又将pod的状态信息写入etcd。

五.Pod资源清单详解

5.1 Pod资源清单介绍

#查看对象中包含哪些字段

[root@k8s-master ~]# kubectl explain pod.spec.containers
KIND:       Pod
VERSION:    v1

FIELD: containers <[]Container>

DESCRIPTION:
    List of containers belonging to the pod. Containers cannot currently be
    added or removed. There must be at least one container in a Pod. Cannot be
    updated.
    A single application container that you want to run within a pod.
    
FIELDS:
  args  <[]string>
    Arguments to the entrypoint. The container image's CMD is used if this is
    not provided. Variable references $(VAR_NAME) are expanded using the
    container's environment. If a variable cannot be resolved, the reference in
    the input string will be unchanged. Double $$ are reduced to a single $,
    which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will
    produce the string literal "$(VAR_NAME)". Escaped references will never be
    expanded, regardless of whether the variable exists or not. Cannot be
    updated. More info:
    https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

  command       <[]string>
    Entrypoint array. Not executed within a shell. The container image's
    ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME)
    are expanded using the container's environment. If a variable cannot be
    resolved, the reference in the input string will be unchanged. Double $$ are
    reduced to a single $, which allows for escaping the $(VAR_NAME) syntax:
    i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped
    references will never be expanded, regardless of whether the variable exists
    or not. Cannot be updated. More info:
    https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

  env   <[]EnvVar>
    List of environment variables to set in the container. Cannot be updated.

  envFrom       <[]EnvFromSource>
    List of sources to populate environment variables in the container. The keys
    defined within a source must be a C_IDENTIFIER. All invalid keys will be
    reported as an event when the container is starting. When a key exists in
    multiple sources, the value associated with the last source will take
    precedence. Values defined by an Env with a duplicate key will take
    precedence. Cannot be updated.

  image <string>
    Container image name. More info:
    https://kubernetes.io/docs/concepts/containers/images This field is optional
    to allow higher level config management to default or override container
    images in workload controllers like Deployments and StatefulSets.

  imagePullPolicy       <string>
    Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if
    :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More
    info: https://kubernetes.io/docs/concepts/containers/images#updating-images
    
    Possible enum values:
     - `"Always"` means that kubelet always attempts to pull the latest image.
    Container will fail If the pull fails.
     - `"IfNotPresent"` means that kubelet pulls if the image isn't present on
    disk. Container will fail if the image isn't present and the pull fails.
     - `"Never"` means that kubelet never pulls an image, but only uses a local
    image. Container will fail if the image isn't present

  lifecycle     <Lifecycle>
    Actions that the management system should take in response to container
    lifecycle events. Cannot be updated.

  livenessProbe <Probe>
    Periodic probe of container liveness. Container will be restarted if the
    probe fails. Cannot be updated. More info:
    https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  name  <string> -required-
    Name of the container specified as a DNS_LABEL. Each container in a pod must
    have a unique name (DNS_LABEL). Cannot be updated.

  ports <[]ContainerPort>
    List of ports to expose from the container. Not specifying a port here DOES
    NOT prevent that port from being exposed. Any port which is listening on th

最低0.47元/天解锁文章