Kubernetes

概念

概述

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。 由于 Kubernetes 在容器级别而不是在硬件级别运行，它提供了 PaaS 产品共有的一些普遍适用的功能， 例如部署、扩展、负载均衡、日志记录和监视。 但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。 Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。

组件

Control Plane Components 控制面板组件

对集群状态做出全局决策，如调度、检测、响应群事件等。

控制平面组件可以在集群任意节点运行，但是普遍会部署在同一计算机中部署所有控制平台组件，并且不会运行用户容器。

kube-apiserver

Kubernetes API 服务器公开了 Kubernetes API，是 Kubernetes 控制面板的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。kube-apiserver 在设计上考虑了水平伸缩，可以通过部署多个实例进行伸缩与负载均衡。

etcd

etcd 是兼具一致性与高可用性的键值数据库，可以保存 Kubernetes 所有集群数据的后台数据库。

通常情况下，etcd 需要有一个备份计划，可参考 etcd 文档

kube-scheduler

负责将还未指定运行 Node 的 Pods，调度到合适的 Node 上来运行。

调度策略考虑的因素包括，Pod 与 Pods 的资源需求、硬件/软件/策略约束、亲和性与反亲和性规范、数据位置、工作负载间的干扰与最后时限。

kube-controller-manager

在主节点上运行控制器的组件。

为了降低复杂度，所有的控制器被编译在同一个可执行文件，并运行在同一进程内。

控制器包括：

• 节点控制器： 负责在节点故障时通知与响应
• 任务控制器： 监测代表一次性任务的 Job 对象，并创建 Pods 来运行这些任务
• 端点控制器： 填充 Endpoints 对象（加入 Service 与 Pod）
• 服务账户和令牌控制器： 为新的命名空间创建默认账户与 API 访问令牌

cloud-controller-manager

cloud-controller-manager 仅运行特定于云平台的控制回路。如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，所部署的环境中不需要云控制器管理器。

以下控制器包含对云平台驱动的依赖：

• 节点控制器： 用于在节点终止相应后检测云提供商，以确定节点是否已经删除
• 路由控制器： 用于在底层云基础架构中设置路由
• 服务控制器： 用于创建、更新和删除云提供商负载均衡器

Node

节点组件在每个节点中运行，维护运行的 Pods 并提供 Kubernetes 运行环境

kubelet

在集群每个 Node 中运行的代理，确保容器均运行在 Pod 上。

kubelet 接受各类机制提供给他的 PodSpecs 确保其所描述的容器处于稳定状态，kubelet 不会管理非 Kubernetes 创建的容器。

kebe-proxy

在集群每个 Node 中运行的网络代理，实现 Kubernetes Service 概念的一部分。

kube-proxy 维护节点上的网络规则，这些规则允许集群和外部的网络会话与 Pod 进行通讯。

如果操作系统提供了可用的数据包过滤层，kube-proxy 可以通过它来实现网络规则，否则将仅转发流量本身。

Container Runtime 容器运行时

负责运行容器的软件

Kubernetes 支持多种运行时环境：Docker、containerd、CRI-O以及任何 Kubernetes CRI（容器运行环境接口） 的实现。

Addons 插件

使用 Kubernetes 资源（DaemonSet、Deployment等）实现集群功能。插件中命名空间域的资源，属于 kube-system 命名空间。完整插件列表见文档

DNS

尽管其他插件都并非严格意义的必须组件，但是几乎所有 Kubernetes 集群都需要有 Pod 与 Service 的 DNS 服务。

集群 DNS 是一个 DNS 服务器，与环境中其他 DNS 服务器一同工作，它为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

Web 仪表盘

Dashboard 是 Kubernetes 集群的通用 Web 用户界面，它可以使用户管理集群中运行的应用程序，或对集群本身进行故障排除。

容器资源监控

Container Resource Monitoring 将关于容器的一些常见时间序列度量值保存在集中数据库中，并提供用于可视化界面。

集群层面日志

cluster-level logging 负责手机容器的日志数据，保存在集中的日志存储中，并提供搜索与浏览接口。

对象

基础概念

在 Kubernetes 系统中，Kubernetes Object 是持久化的实体，可以使用这些实体去表示整个集群的状态，他们描述了如下信息：

• 那些容器化应用正在运行（以及运行的节点位置）
• 可以被应用使用的资源
• 关于应用运行时表现的策略，如重启策略、升级策略、容错策略。

Kubernetes Object 是目标性记录 ———— 一旦创建对象，Kubernetes 系统将持续工作确保对象存在。通过创建对象可以向 Kubernetes 系统传达所需的集群工作负载的最终状态，也就是 Kubernetes 集群的 Desired State。

只能使用 Kubernetes API 来管理 Kubernetes Object 的声明周期。无论是 kubectl 还是 SDK 调用，最后都会被转化为 Kubernetes API 的形式。

Spec and Status 规约与状态

几乎每个 Kubernetes Object 都会包含俩个嵌套的对象字段，负责管理对象的配置：spec 和 status。

对于具有 spec 的对象，必须在创建时设置其内容，描述它的 Desired State。

status 描述了对象的 Current State，它是由 Kubernetes 系统与组件设置并更新的。在任何时刻 Control Plane 都会积极的管理对象的实际状态，使之与 Desired State 相匹配。

描述 Kubernetes Object

在创建 Kubernetes Object 时，必须提供对象的 spec 以描述对应的 Desired State，以及对象的基本信息（例如名称）。在 Kubernetes API 创建对象时，必须在请求体中包含 JSON 格式信息，很多时候会通过 .yaml 文件为 kubectl 提供这些信息，由 kubectl 转化为 JSON 格式数据。

Yaml 规范

.yaml 文件中，需配置如下字段

• apiVersion 创建对象时使用的 Kubernetes API 版本
• kind 创建对象的类别
• metadata 对象的唯一性标识，包含 name、UID 与 namespace（可选）

还需提供对象的 spec 字段。对象的 spec 的精确格式对每个 Kubernetes Object 是不同的，包含了特定于该对象的嵌套字段。详情查阅：

• Kubernetes API 参考 查阅创建的对象的 spec 格式
• core/v1 PodSpec 查看 Pod 的 spec 格式
• apps/v1 DeploymentSpec 查看 Deployment 的 spec 格式

# demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

管理技巧

Tips： 应该只使用一种技术来管理 Kubernetes Object，混合和匹配技术作用在统一对象，将导致未定义行为。

Kubernetes 文档整理