测试开发右移 — Kubernetes 初识，核心概念

这里的资源和对象是什么？

kubesetes所有内容都被抽象为资源，如：Pod、service、Node，“对象” 就是 “资源” 的实例，是持久化的实体，如某个具体的 Pod、某个具体的 Node，Kubesetes 使用这些实体去表示整个集群的状态。
对象的创建、删除、修改都是通过 “Kebusetes API” ，也就是 “Api service” 组件提供的 API 接口，这些是 RESTful 风格的Api，命令行工具 “kebuctl” 实际上也是调用 kebusetes api。

对象的规约和状态

规约 Spec

“spec” 是 “规约”、“规格” 的意思，spec 是必须的，它描述了对象的期望状态（Desired State）— 希望对象具有的特征，当创建 kebusetes 对象时，必须提供对象的规约，用来描叙该对象的期望状态，以及关于对象的一些基本信息。

状态 State

表示对象的实际状态，该属性有 k8s 自己维护，k8s 会通过一系列的控制器对对应的对象进行管理，让对象的实际状态尽可能的与期望状态重合。

资源的分类

元数据、集群级、命名空间级 （代表性的3个）

集群级别的资源：作用于集群之上，集群下的所有资源都可共享使用
命名空间级别的资源：作用于命名空间之上，通常只能在该命名空间范围内使用
元数据级别的资源：对资源的元数据描述，每一个资源都可以使用元数据的数据

元数据

Horizontal Pod Autoscaler（HPA）

Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。

• 控制管理器每隔 30s（可以通过 -horizontal-pod-autoscaler-sync-period 修改）查询 metrics 的资源使用情况
• 支持三种 metrics 类型
  • 预定义 metrics（比如 Pod 的 CPU）以利用率的方式计算
  • 自定义的 Pod metrics，以原始值（raw value）的方式计算
  • 自定义的 object metrics
• 支持两种 metrics 查询方式：Heapster 和自定义的 REST API
• 支持多 metrics

Pod Template

是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。

limitRange

可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。request 表示最少资源数，limit 表示最多资源数。

集群级

Namespace

集群下面的命名空间

Node

不像其他的资源（如 Pod 和 Namespace），Node 本质上不是 Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。虽然可以通过 Manifest 创建一个 Node 对象（如下 json 所示），但 Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度 Pod。

ClusterRole

权限组， 用于对集群的权限进行管理

ClusterRoleBinding

ClusterRole表示是还未与资源绑定，ClusterRoleBinding则用于资源与权限组的绑定，只能绑定到集群级别的资源上面。

命名空间

工作负载型

Pod

• Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。Docker 是 Kubernetes Pod 中使用最广泛的容器引擎；Kubernetes Pod 同时也支持其他类型的容器引擎。

• Kubernetes 集群中的 Pod 存在如下两种使用途径：

  • 一个 Pod 中只运行一个容器。”one-container-per-pod” 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
  • 一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个 Pod 中。

• 举例两个强依赖关系的容器

• 通过 pod 实现共享
  

• 一个完整的 pod
  

副本（replicas）

• 先引入“副本”的概念——一个 Pod 可以被复制成多份，每一份可称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。

• Pod 的“控制器”通常包含一个名为 “replicas” 的属性。“replicas” 属性则指定了特定 Pod 的副本的数量，当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。

控制器 （内存级的对象）

• 使用无状态服务

  • ReplicationController（RC）
    Replication Controller 简称 RC，RC 是 Kubernetes 系统中的核心概念之一，简单来说，RC 可以保证在任意时间运行 Pod 的副本数量，能够保证 Pod 总是可用的。如果实际 Pod 数量比指定的多，那就结束掉多余的；如果实际数量比指定的少，就新启动一些 Pod。当 Pod 失败、被删除或者挂掉后，RC 都会去自动创建新的 Pod 来保证副本数量，所以即使只有一个 Pod，我们也应该使用 RC 来管理我们的 Pod。可以说，通过 ReplicationController，Kubernetes 实现了动态的更新副本数量、 Pod 的高可用性。

  • ReplicaSet（RS）— Label、Selector
    

    • Deployment（针对RS更高的封装）
      创建ReplicaSet/Pod、滚动升级/回滚、平滑扩容和缩容、暂停与回复Deployment

• 适用有状态服务

  注意事项：kubenetes v1.5 支持内容

  • 所有 Pod 的 Volume 必须使用 PersistentVolume 或者是管理员事先创建好
  • 为了保证数据安全，删除 StatefulSet 时不会删除 Volume
  • StatefulSet 需要一个 Headless Service 来定义 DNS domain，需要在 StatefulSet 之前创建好

  • StatefulSet

    • StatefulSet 中每个 Pod 的 DNS 格式为：statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local

    • serviceName 为 Headless Service 的名字

    • 0..N-1 为 Pod 所在的序号，从 0 开始到 N-1

    • statefulSetName 为 StatefulSet 的名字

    • namespace 为服务所在的 namespace，Headless Service 和 StatefulSet 必须在相同的 namespace

    • .cluster.local 为 Cluster Domain

    • 主要特点：稳定持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序删除

  • StatefulSet 的组成

    • Headless Service
    • volumeClaimTemplate

• 守护进程

  • DeamonSet

    

  • • DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

    • 日志收集，比如 fluentd、logstash 等

    • 系统监控，比如 Prometheus Node Exporter、collectd、New Relic agent、Ganglia gmond 等

    • 系统程序，比如 kube-proxy、kube-dns、glusterd、ceph 等

  • 任务/定时任务

  • Job
    一次性任务，运行完成后Pod销毁，不在重新启动新容器。

  • CronJob
    周期性任务，在 Job 基础上加了定时功能

服务发现

Service

“Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。

可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。

Ingress

实现将 k8s 内部服务包喽给外网访问的服务

配置与存储

Vloume

数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库的数据。

CSI

Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。

CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

特殊类型配置

ConfigMap

配置文件修改后容器会更新

Secret

Secret 有三种类型：
Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中；
Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；
kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。

DownwardAPI

downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据，也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。

downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：

• 环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
• volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

其他

Role

Role是一组权限的集合，列入Role可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 namespase 中的资源进行鉴权。

RoleBinding

只能将 Role 绑定到命名空间中的资源上。

本作品采用《CC 协议》，转载必须注明作者和本文链接