Kubernetes 从创建之初的核心模块之一就是资源调度。想要在生产环境使用好 Kubernetes，必须对它的资源模型以及资源管理非常了解。这篇文章算是对散布在网络上的 Kubernetes 资源管理内容的一个总结。干货文章，强列推荐一读。

Kubernetes 资源简介

什么是资源？

在 Kubernetes 中，有两个基础但是非常重要的概念：Node 和 Pod。Node 翻译成节点，是对集群资源的抽象；Pod 是对容器的封装，是应用运行的实体。Node 提供资源，而 Pod 使用资源，这里的资源分为计算（CPU、Memory、GPU）、存储（Disk、SSD）、网络（Network Bandwidth、IP、Ports）。这些资源提供了应用运行的基础，正确理解这些资源以及集群调度如何使用这些资源，对于大规模的 Kubernetes 集群来说至关重要，不仅能保证应用的稳定性，也可以提高资源的利用率。

在这篇文章，我们主要介绍 CPU 和内存这两个重要的资源，它们虽然都属于计算资源，但也有所差距。CPU 可分配的是使用时间，也就是操作系统管理的时间片，每个进程在一定的时间片里运行自己的任务（另外一种方式是绑核，也就是把 CPU 完全分配给某个 Pod 使用，但这种方式不够灵活会造成严重的资源浪费，Kubernetes 中并没有提供）；而对于内存，系统提供的是内存大小。

CPU 的使用时间是可压缩的，换句话说它本身无状态，申请资源很快，也能快速正常回收；而内存大小是不可压缩的，因为它是有状态的（内存里面保存的数据），申请资源很慢（需要计算和分配内存块的空间），并且回收可能失败（被占用的内存一般不可回收）。

把资源分成可压缩和不可压缩，是因为在资源不足的时候，它们的表现很不一样。对于不可压缩资源，如果资源不足，也就无法继续申请资源（内存用完就是用完了），并且会导致 Pod 的运行产生无法预测的错误（应用申请内存失败会导致一系列问题）；而对于可压缩资源，比如 CPU 时间片，即使 Pod 使用的 CPU 资源很多，CPU 使用也可以按照权重分配给所有 Pod 使用，虽然每个人使用的时间片减少，但不会影响程序的逻辑。

Ingress 是一种 Kubernetes 资源，也是将 Kubernetes 集群内服务暴露到外部的一种方式。本文将讲一讲如何用 Helm 在 Kubernetes 集群中部署 Ingress，并部署两个应用来演示 Ingress 的具体使用。

阅读本文前你需要先掌握 Helm 和一些 Kubernetes 服务暴露的相关知识点，如果你还不了解可以先读一读我之前写的 「Helm 入门指南」和「浅析从外部访问 Kubernetes 集群中应用的几种方式」这两篇文章。

部署 Ingress Controller

Ingress 只是一个统称，其由 Ingress 和 Ingress Controller 两部分组成。Ingress 用作将原来需要手动配置的规则抽象成一个 Ingress 对象，使用 YAML 格式的文件来创建和管理。Ingress Controller 用作通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化。

目前可用的 Ingress Controller 类型有很多，比如：Nginx、HAProxy、Traefik 等，我们将演示如何部署一个基于 Nginx 的 Ingress Controller。

这里我们使用 Helm 来部署，在开始部署前，请确认您已经安装和配置好 Helm 相关环境。

查找软件仓库中是否有 Nginx Ingress 包

1
2
3

$ helm search nginx-ingress
NAME                	CHART VERSION	APP VERSION	DESCRIPTION
stable/nginx-ingress	0.9.5        	0.10.2     	An nginx Ingress controller that uses ConfigMap...

注：这里我们使用的是在阿里云 Helm 镜像仓库。如果你还不知道如何增加三方仓库，可先阅读 「Helm 入门指南」一文。

阿里云 Helm 镜像仓库里的 nginx-ingress 软件包已经将要用到的相关容器镜像地址改成了国内可访问的地址。安装时需要用到的容器镜像有：

1
2
3

repository: registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.10.2
repository: registry.cn-hangzhou.aliyuncs.com/google_containers/defaultbackend:1.3
repository: sophos/nginx-vts-exporter:0.6

fd 是基于 Rust 开发的一个速度超快的命令行搜索工具，fd 旨在成为 Linux / Unix 下 find 命令的替代品。

fd 虽然不能提供现在 find 命令所有的强大功能，但它也提供了足够强大的功能来满足你日常需要。比如：简洁的语法、彩色的终端输出、超快的查询速度、智能大小写、支持正则表达式以及可并行执行命令等特性。

项目地址：https://github.com/sharkdp/fd

安装 fd

fd 具有良好跨平台特性，支持在 Linux、macOS、Windows 等多种平台下安装。下面我们介绍下几个比较常用平台的安装方法：

• Ubuntu / Debain

1
2

$ wget https://github.com/sharkdp/fd/releases/download/v7.0.0/fd_7.0.0_amd64.deb
$ sudo dpkg -i fd_7.0.0_amd64.deb

Helm 是 Kubernetes 生态系统中的一个软件包管理工具。本文将介绍 Helm 中的相关概念和基本工作原理，并通过一个具体的示例学习如何使用 Helm 打包、分发、安装、升级及回退 Kubernetes 应用。

Kubernetes 应用部署的挑战

Kubernetes 是一个提供了基于容器的应用集群管理解决方案，Kubernetes 为容器化应用提供了部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。

Kubernetes 的核心设计理念是: 用户定义要部署的应用程序的规则，而 Kubernetes 则负责按照定义的规则部署并运行应用程序。如果应用程序出现问题导致偏离了定义的规格，Kubernetes 负责对其进行自动修正。例如：定义的应用规则要求部署两个实例（Pod），其中一个实例异常终止了，Kubernetes 会检查到并重新启动一个新的实例。

用户通过使用 Kubernetes API 对象来描述应用程序规则，包括 Pod、Service、Volume、Namespace、ReplicaSet、Deployment、Job等等。一般这些资源对象的定义需要写入一系列的 YAML 文件中，然后通过 Kubernetes 命令行工具 Kubectl 调 Kubernetes API 进行部署。

以一个典型的三层应用 Wordpress 为例，该应用程序就涉及到多个 Kubernetes API 对象，而要描述这些 Kubernetes API 对象就可能要同时维护多个 YAML 文件。

从上图可以看到，在进行 Kubernetes 软件部署时，我们面临下述几个问题：

• 如何管理、编辑和更新这些这些分散的 Kubernetes 应用配置文件。
• 如何把一套相关的配置文件作为一个应用进行管理。
• 如何分发和重用 Kubernetes 的应用配置。

Helm 的出现就是为了很好地解决上面这些问题。

想象一下，如果我想将 Nginx 部署到 Kubernetes 集群，我可能会在终端中输入类似这样的命令：

1

$ kubectl run --image=nginx --replicas=3

然后回车。几秒钟后，你就会看到三个 Nginx Pod 分布在所有的工作节点上。这一切就像变魔术一样，但你并不知道这一切的背后究竟发生了什么事情。

Kubernetes 的神奇之处在于：它可以通过用户友好的 API 来处理跨基础架构的 Deployments，而背后的复杂性被隐藏在简单的抽象中。但为了充分理解它为我们提供的价值，我们需要理解它的内部原理。

本指南将引导您理解从 Client 到 Kubelet 请求的完整生命周期，必要时会通过源代码来说明背后发生了什么。

这是一份可以在线修改的文档，如果你发现有什么可以改进或重写的，欢迎提供帮助！

1. Kubectl

验证和生成器

当敲下回车键以后，Kubectl 首先会执行一些客户端验证操作，以确保不合法的请求（例如：创建不支持的资源或使用格式错误的镜像名称）将会快速失败，也不会发送给 Kube-Apiserver。通过减少不必要的负载来提高系统性能。

验证通过之后，Kubectl 开始将发送给 Kube-Apiserver 的 HTTP 请求进行封装。Kube-Apiserver 与 Etcd 进行通信，所有尝试访问或更改 Kubernetes 系统状态的请求都会通过 Kube-Apiserver 进行，Kubectl 也不例外。Kubectl 使用生成器（Generators）来构造 HTTP 请求。生成器是一个用来处理序列化的抽象概念。

通过 kubectl run 不仅可以运行 Deployment，还可以通过指定参数 --generator 来部署其他多种资源类型。如果没有指定 --generator 参数的值，Kubectl 将会自动判断资源的类型。

例如：带有参数 --restart-policy=Always 的资源将被部署为 Deployment，而带有参数 --restart-policy=Never 的资源将被部署为 Pod。同时 Kubectl 也会检查是否需要触发其他操作，例如：记录命令（用来进行回滚或审计）。

在 Kubectl 判断出要创建一个 Deployment 后，它将使用 DeploymentV1Beta1 生成器从我们提供的参数中生成一个运行时对象。