L李钟意的博客

今天有两个实战项目。首先是 WordPress，把后端的存储服务 MariaDB 改造成了 StatefulSet，挂载了 NFS 网盘，这样就实现了一个功能比较完善的网站，达到了基本可用的程度。接着我们在 Kubernetes 里安装了 Dashboard，主要部署在名字空间“kubernetes-dashboard”。Dashboard 自身的安装很简单，但我们又为它在前面搭建了一个反向代理，配上了安全证书，进一步实践了 Ingress 的用法。

在【k8s】利用Kubeadm搭建多节点的Kubernetes集群(七)，我们为 Kubernetes 安装了一个网络插件 Flannel。都与网络相关，但也只是浅尝辄止，并没有太多深究。Flannel 到底是如何工作的呢？它为什么能够让 Kubernetes 集群正常通信呢？还有没有其他网络插件呢？今天我们就来聊一下这个话题，讲讲 Kubernetes 的网络接口标准 CNI，以及 Calico、Cilium 等性能更好的网络插件。提示：以下是本篇文章正文内容，下面案例可供参考。

把 Pod 和集群管好用好还缺少一个很重要的方面——集群的可观测性。也就是说，我们希望给集群也安装上检查探针，观察到集群的资源利用率和其他指标，让集群的整体运行状况对我们透明可见，这样才能更准确更方便地做好集群的运维工作。但是观测集群是不能用探针和Prometheus，以及基于它们的水平自动伸缩对象。提示：以下是本篇文章正文内容，下面案例可供参考Metrics Server 是一个 Kubernetes 插件，能够收集系统的核心资源指标，相关的命令是 kubectl top。

Kubernetes 的名字空间并不是一个实体对象，只是一个逻辑上的概念。它可以把集群切分成一个个彼此独立的区域，然后我们把对象放到这些区域里，就实现了类似容器技术里namespace的隔离效果，应用只能在自己的名字空间里分配资源和运行，不会干扰到其他名字空间里的应用。Kubernetes 的 Master/Node 架构已经能很好地管理集群，为什么还要引入名字空间这个东西呢？它的实际意义是什么呢？我觉得，这恰恰是Kubernetes面对大规模集群、海量节点时的一种现实考虑。

作为 Kubernetes 里的核心概念和原子调度单位，Pod 的主要职责是管理容器，以逻辑主机、容器集合、进程组的形式来代表应用，它的重要性是不言而喻的。看看在 Kubernetes 里配置 Pod 的两种方法：资源配额Resources、检查探 针Probe，它们能够给 Pod 添加各种运行保障，让应用运行得更健康。Resources和Probe。Resources就是为容器加上资源限制，而 Probe 就是主动健康检查，让 Kubernetes 实时地监控应用的运行状态。

上篇笔记我们学习了管理有状态应用的对象 StatefulSet，再加上管理无状态应用的 Deployment 和 DaemonSet，我们就能在 Kubernetes 里部署任意形式的应用了。只是把应用发布到集群里是远远不够的，要让应用稳定可靠地运行，还需要有持续的运维工作。在【k8s】Deployment让应用永不宕机(八)里，我们学过 Deployment 的应用伸缩功能就是一种常见的运维操作，在 Kubernetes 里，使用命令。

先从 PersistentVolume 谈起，它为 Kubernetes 带来了持久化存储的功能，能够让应用把数据存放在本地或者远程的磁盘上。有了持久化存储，应用就可以把一些运行时的关键数据落盘，相当于有了一份保险，如果 Pod 发生意外崩溃，也只不过像是按下了暂停键，等重启后挂载 Volume，再加载原数据就能够满血复活，恢复之前的状态继续运行。这里有一个关键词——状态，应用保存的数据，实际上就是它某个时刻的运行状态。运行状态信息就很重要了，如果因为重启而丢失了状态是绝对无法接受的，这样的应用就是。

要想让存储卷真正能被 Pod 任意挂载，我们需要变更存储的方式，不能限定在本地磁盘，而是要改成网络存储，这样 Pod 无论在哪里运行，只要知道 IP 地址或者域名，就可以通过网络通信访问存储设备。网络存储是一个非常热门的应用领域，有很多知名的产品，比如还专门定义了规范，不过这些存储类型的安装、使用都比较复杂，在实验环境里部署难度比较高。所以我们以为例学习如何在 Kubernetes 里使用网络存储，以及静态存储卷和动态存储卷的概念。提示：以下是本篇文章正文内容，下面案例可供参考。

PersistentVolume 简称为 PV，是 Kubernetes 对存储设备的抽象，由系统管理员维护，需要描述清楚存储设备的类型、访问模式、容量等信息。PersistentVolumeClaim 简称为 PVC，代表 Pod 向系统申请存储资源，它声明对存储的要求，Kubernetes 会查找最合适的 PV 然后绑定。StorageClass 抽象特定类型的存储系统，归类分组 PV 对象，用来简化 PV/PVC 的绑定过程。

这个网站离真正实用还差得比较远，但框架已经很完善了，可以在这个基础上添加其他功能，比如创建证书 Secret、让 Ingress 支持 HTTPS 等等。另外，对于数据库 MariaDB 来说，虽然 Deployment 在发生故障时能够及时重启 Pod，新 Pod 却不会从旧 Pod 继承数据，之前网站的数据会彻底消失，这个后果是完全不可接受的。所以后面会继续学习持久化存储对象 PersistentVolume，以及有状态的 StatefulSet 等对象。

提示：这里对文章进行总结：例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。

在云原生时代，微服务无疑是应用的主流形态。Service，它是集群内部的负载均衡机制，用来解决服务发现的关键问题。在Kubernetes Service 文档中Service被定义为将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。提示：以下是本篇文章正文内容，下面案例可供参考Pod 的生命周期很短暂，会不停地创建销毁，所以就需要用 Service 来实现负载均衡，它由 Kubernetes 分配固定的 IP 地址，能够屏蔽后端的 Pod 变化。

DaemonSet 的目标是为集群里的每个节点部署唯一的 Pod，常用于监控、日志等业务。DaemonSet 的 YAML 描述与 Deployment 非常接近，只是没有 replicas 字段。污点和容忍度是与 DaemonSet 相关的两个重要概念，分别从属于 Node 和 Pod，共同决定了 Pod 的调度策略。静态 Pod 也可以实现和 DaemonSet 同样的效果，但它不受 Kubernetes 控制，必须在节点上纯手动部署，应当慎用。

Pod 只能管理容器，不能管理自身，所以就出现了 Deployment，由它来管理 Pod。Deployment 里有三个关键字段，其中的 template 和 Job 一样，定义了要运行的 Pod 模板。replicas 字段定义了 Pod 的“期望数量”，Kubernetes 会自动维护 Pod 数量到正常水平。selector 字段定义了基于 labels 筛选 Pod 的规则，它必须与 template 里 Pod 的 labels 一致。

本系列会继续深入研究 Kubernetes 的其他 API 对象，也就是那些在 Docker 中不存在的但对云计算、集群管理至关重要的概念。这就需要一个比minikube更真实的Kubernetes环境，它应该是一个多节点的Kubernetes集群，这样更贴近现实中的生产系统，能够让我们尽快地拥有实际的集群使用经验。所以我们改用 kubeadm 搭建一个 Kubernetes 集群，这里是kubeadm 文档。Kubernetes 由很多组件构成（也可以访问Kubernetes 官方文档 - 组件。

容器技术开启了云原生的大潮，但成熟的容器技术，到生产环境的应用部署的时候，却显得“步履维艰”。来表述对象的状态，不涉及具体的操作细节，这样 Kubernetes 就能够依靠存储在 etcd 里集群的状态信息，不断地“调控”对象，直至实际状态与期望状态相同，这个过程就是 Kubernetes 的自动化运维管理。点击任意一个 Pod 的名字，就会进入管理界面，可以看到 Pod 的详细信息，而右上角有 4 个很重要的功能，分别可以查看日志、进入 Pod 内部、编辑 Pod 和删除 Pod，相当于执行。

一类是明文配置，也就是不保密，可以任意查询修改，比如服务端口、运行参数、文件路径等。另一类则是机密配置，由于涉及敏感信息需要保密，不能随便查看，比如密码、密钥、证书等。这两类配置信息本质上都是字符串，只是由于安全性的原因，在存放和使用方面有些差异，所以 Kubernetes 也就定义了两个 API 对象，ConfigMap用来保存明文配置，Secret用来保存秘密配置。ConfigMap 记录了一些 Key-Value 格式的字符串数据，描述字段是“data”，不是“spec”。

Pod 是 Kubernetes 的最小调度单元，但为了保持它的独立性，不应该向它添加多余的功能。Kubernetes 为离线业务提供了 Job 和 CronJob 两种 API 对象，分别处理“临时任务”和“定时任务”。Job 的关键字段是 spec.template，里面定义了用来运行业务的 Pod 模板，其他的重要字段有 completions、parallelism 等。

现实中经常会有多个进程密切协作才能完成任务的应用，而仅使用容器很难描述这种关系，所以就出现了 Pod，它“打包”一个或多个容器，保证里面的进程能够被整体调度。Pod 是 Kubernetes 管理应用的最小单位，其他的所有概念都是从 Pod 衍生出来的Pod 也应该使用 YAML“声明式”描述，关键字段是“spec.containers”，列出名字、镜像、端口等要素，定义内部的容器运行状态。

Kubernetes采用YAML作为工作语言是它有别与其他系统的一大特色，声明式的语言能够更准确更清晰地描述系统状态，避免引入繁琐的操作步骤扰乱系统，与 Kubernetes 高度自动化的内部结构相得益彰，而且纯文本形式的 YAML 也很容易版本化，适合 CI/CD。YAML是 JSON 的超集，支持整数、浮点数、布尔、字符串、数组和对象等数据类型。也就是说，任何合法的 JSON 文档也都是YAML文档。接下来我们就要通过 YAML 文件配置 Kubernetes。

Kubernetes 的内部架构和工作机制，了解它能够傲视群雄的秘密所在。提示：以下是本篇文章正文内容，下面案例可供参考Kubernetes 能够在集群级别管理应用和服务器，可以认为是一种集群操作系统。它使用“控制面 / 数据面”的基本架构，Master 节点实现管理控制功能，Worker 节点运行具体业务。Kubernetes 由很多模块组成，可分为核心的组件和选配的插件两类。

Kubernetes 就是一个生产级别的容器编排平台和集群管理系统，不仅能够创建、调度容器，还能够监控、管理服务器，它凝聚了 Google 等大公司和开源社区的集体智慧，从而让中小型公司也可以具备轻松运维海量计算节点——也就是“云计算”的能力。