在本教程中,我们将对 Kubernetes 进行简要的理论介绍。具体而言,我们将讨论以下主题:
为了更深入地了解,我们还可以看看官方文档。
在上一篇文章中,我们已经讨论了一些 Docker 基础知识,以及如何打包和部署自定义应用程序。
简而言之,Docker 是一个容器运行时:它提供了以标准化方式打包、交付和运行应用程序的单个实例的功能,也称为容器。
然而,随着复杂性的增加,新的需求出现了;自动部署、容器编排、计划应用、授予高可用性、管理包含多个应用实例的群集等。
市场上有很多工具。然而,Kubernetes 越来越像一个重要的竞争对手。
简而言之,Kubernetes 是一个跨节点集群(包括网络和存储基础设施)编排容器化应用程序的系统。一些最重要的功能是:
主服务器维护集群的所需状态。当我们与集互时,例如通过使用kubectl命令行界面,我们始终与集群的主节点进行通信。
群集中的节点是运行应用程序的计算机(VM、物理服务器等)。主节点控制每个节点。
节点需要容器运行时。Docker 是 Kubernetes 最常用的运行时。
Minikube是一个 Kubernetes 发行版,它使我们能够在工作站上的 VM 内运行单节点集群以进行开发和测试。
KubernetesAPI通过将 Kubernetes 概念包装到对象中来提供 Kubernetes 概念的抽象(我们将在下一节中介绍)。
kubectl是一个命令行工具,我们可以使用它来创建、更新、删除和检查这些 API 对象。
API 对象是“意图记录”——一旦我们创建了对象,集群系统将持续工作以确保该对象存在。
每个对象都由两部分组成:对象规范和对象状态。规范描述了对象的所需状态。状态描述对象的实际状态,由集群提供和更新。
在下一节中,我们将讨论最重要的对象。之后,我们将看一个示例,规范和状态在现实中的样子。
Pod是 Kubernetes 处理的基本单元。它封装了一个或多个密切相关的容器、存储资源、唯一的网络 IP 以及容器应如何运行的配置,从而表示应用程序的单个实例。
服务是一种抽象,它将 Pod 的逻辑集合组合在一起,并定义如何访问它们。服务是一组容器的接口,因此消费者不必担心单个访问位置以外的任何事情。
使用卷,容器可以访问外部存储资源(因为它们的文件系统是临时的),并且可以读取文件或永久存储文件。卷还支持在容器之间共享文件。支持一长串卷类型。
通过命名空间,Kubernetes 提供了在一个物理集群上运行多个虚拟集群的可能性。命名空间为资源名称提供范围,这些名称在命名空间中必须是唯一的。
此外,还有一些更高级别的抽象,称为控制器。控制器基于基本对象构建并提供附加功能:
部署控制器为 Pod 和副本集提供声明性更新。我们在部署对象中描述所需状态,部署控制器将实际状态更改为所需状态。
副本集可确保在任何给定时间运行指定数量的 Pod 副本。
使用StatefulSet,我们可以运行有状态的应用程序:与部署不同,Pod 将具有唯一且持久的身份。使用 StatefulSet,我们可以实现具有唯一网络标识符或持久存储的应用程序,并且可以保证有序、优雅的部署、扩展、删除和终止,以及有序和自动滚动更新。
使用DaemonSet,我们可以确保集群中的所有或一组特定节点运行特定 Pod 的一个副本。如果我们需要在每个节点上运行一个守护进程,例如用于应用程序监控或收集日志,这可能会有所帮助。
垃圾收集确保删除某些对象,这些对象曾经有所有者,但不再有所有者。这有助于通过删除不再需要的对象来节省资源。
作业会创建一个或多个 Pod,确保其中特定数量的 Pod 成功终止,并跟踪成功完成情况。作业有助于并行处理一组独立但相关的工作项,例如发送电子邮件、呈现帧、转码文件等。
元数据是属性,提供有关对象的其他信息。
必需属性包括:
还有可选的元数据属性。其中一些最重要的有:
在理论上讨论了 Kubernetes API 之后,我们现在来看一个示例。
API 对象可以指定为 JSON 或 YAML 文件。但是,文档建议使用 YAML 进行手动配置。
在下文中,我们将定义无状态应用程序部署的规范部分。之后,我们将查看从集群返回的状态可能是什么样子的。
名为demo-back的应用程序的规范可能如下所示:
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-backend
spec:
selector:
matchLabels:
app: demo-backend
tier: backend
replicas: 3
template:
metadata:
labels:
app: demo-backend
tier: backend
spec:
containers:
- name: demo-backend
image: demo-backend:latest
ports:
- containerPort: 8080如我们所见,我们指定了一个部署对象,称为演示后端。下面的_spec:_part 实际上是一个嵌套结构,包含前面各节中讨论的以下 API 对象:
如果我们从群集查询部署的状态,响应将如下所示:
Name: demo-backend
Namespace: default
CreationTimestamp: Thu, 22 Mar 2018 18:58:32 +0100
Labels: app=demo-backend
Annotations: deployment.kubernetes.io/revision=1
Selector: app=demo-backend
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=demo-backend
Containers:
demo-backend:
Image: demo-backend:latest
Port: 8080/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: demo-backend-54d955ccf (3/3 replicas created)
Events: <none>如我们所见,部署似乎已启动并正在运行,我们可以识别规范中的大多数元素。
我们有一个复制因子为 3 的部署,一个 pod 包含一个容器,从映像演示后端:latest 实例化。
响应中存在但未在我们的规范中定义的所有属性都是默认值。
我们可以在各种平台上运行 Kubernetes:从我们的笔记本电脑到云提供商上的虚拟机,或者裸机服务器机架。
首先,Minikube可能是最简单的选择:它使我们能够在本地工作站上运行单节点集群以进行开发和测试。
查看官方文档,了解进一步的本地计算机解决方案、托管解决方案、要在 IaaS 云上运行的发行版等。