江苏龙网

  1. 主页 > 生活百科 > >

开发者的Kubernetes懒人指南( 四 )

Kubernetes


apiVersion: v1kind: Podmetadata:name: marcocodes-webspec:containers:- image: gcr.io/marco/marcocodes:1.4name: marcocodes-webports:- containerPort: 8080name: httpprotocol: TCP…并使用以下 kubectl 命令将其输入到你的 Kubernetes 集群中：
kubectl apply -f marcocodes-pod.yaml应用这个 yaml 文件会做什么呢？嗯，让我们逐步了解：
Kubernetes 知道各种所谓的对象，Pod 是其中之一 ， 你稍后会遇到其他对象 。简单来说，这个 .yaml 文件描述了我们要部署的 Pod 。
metadata:name: marcocodes-webKubernetes 中的每个对象，因此每个 .yaml 文件都充满了metadata标签 。在这种情况下，我们为我们的 pod 指定了名称，值为marcocodes_web 。这个 metadata 有什么用呢？简单来说，Kubernetes 需要以某种方式唯一标识集群中的资源：我是否已经运行了一个名称为marcocodes_web的 pod，还是我需要启动一个新的 pod？这就是 metadata 的作用 。
spec:containers:- image: gcr.io/marco/marcocodes:1.4name: marcocodes-webports:- containerPort: 8080name: httpprotocol: TCP你需要告诉 Kubernetes 你的 pod 应该是什么样的 。记住，它可以是 n+ 个容器 ， 因此你可以在 YAML 文件中指定容器的列表，尽管通常你只指定一个 。
你将指定一个特定的 Docker 镜像，包括其版本，并通过 http 在该容器上暴露端口 8080 。就是这样 。
这个 yaml 文件到底发生了什么？长话短说，当你运行 kubectl apply 时，你的 yaml 文件将被提交到 Kubernetes API 服务器，最终我们的 Kubernetes 系统将安排一个 pod（带有 marcocodes 1.4 容器）在我们集群中的一台健康、可行的节点上运行 。
更技术性地说，Kubernetes 有一个协调循环的概念，一个调度器能够说的花哨点的术语：
"这是我的当前 Kubernetes 集群状态 ， 这是用户的 yaml 文件，让我协调这两者 。用户想要一个新的 pod 吗？我会创建它 。用户想要存储吗？我会将其附加到容器上 ， 等等 。
说到存储...
资源和卷仅指定容器镜像并不是你所能做的全部 。首先，你可能想要处理容器的资源消耗：
# ....spec:containers:- image: gcr.io/marco/marcocodes:1.4resources:requests:cpu: "500m"memory: "128Mi"# ....这确保你的容器至少获得 500m（即 0.5）的 CPU 和 128 MB 的内存（你还可以指定永远不可突破的上限） 。
此外，当一个 pod 被删除或容器重新启动时，容器文件系统中的数据也将被删除 。为了避免这种情况，你可能想要将数据存储在持久卷上 。
# ....spec:volumes:- name: "marcocodes-data"hostPath:path: "/var/lib/marcocodes"containers:- image: gcr.io/marco/marcocodes:1.4name: marcocodesvolumeMounts:- mountPath: "/data"name: "marcocodes-data"ports:- containerPort: 8080name: httpprotocol: TCP# ....我们将拥有一个名为marcocodes-data的卷，它将被挂载到容器上的/data目录下，并存在于主机机器上的/var/lib/marcocodes下 。
有什么要注意的吗？你刚学到有 pod，它们由一个或多个 Docker 镜像组成，以及资源消耗规则和卷定义 。
有了所有这些 YAML，我们成功地安排了一个单一的、静态的、一次性的 pod 。问题来了：与仅运行docker run -d --publish 8080:8080 gcr.io/marco/marcocodes:1.4相比，有何优势？
嗯，实际上目前并没有 。
这就是为什么我们需要更深入地了解ReplicaSet和Deployment概念的原因 。
ReplicaSet我们要谦卑一点 。一开始我们不需要自动缩放 ， 但拥有应用程序的冗余实例和一些负载平衡会很不错 ， 这样我们的部署会显得更专业 ， 不是吗？
Kubernetes 的ReplicaSet来拯救我们！
让我们看一个定义了这样一个最小 ReplicaSet 的marcocodes-replica.yaml文件 。
apiVersion: apps/v1kind: ReplicaSet# metadata:# ...spec:replicas: 2selector: "you will learn this later"# ...template:metadata: "you will learn this later"# ...spec:containers:- name: marcocodes-webimage: "gcr.io/marco/marcocodes:3.85"我省略了这个 YAML 文件中的很多行（和复杂性），但现在最有趣的是这两个变化：
这个 .yaml 现在描述的是一个 ReplicaSet，而不再是一个 Pod 。
这是重点：我们希望始终有 2 个副本 == pod 在任何给定的时间运行 。如果我们在这里填入 10，Kubernetes 将确保同时运行 10 个 pod 。
当我们现在应用这个 .yaml 文件...
kubectl apply -f marcocodes-rs.yamlKubernetes 将从 Kubernetes API 获取一个 Pod 清单（并根据metadata过滤结果） ， 根据返回的 pod 数量 ， Kubernetes 将启动或停止额外的副本 。就是这么简单 。


推荐阅读


上一篇：在项目中如何避免和解决Java内存泄漏问题

下一篇：Kubernetes是什么？主要特点是什么？