Kubernetes 初学者部署教程-卡咪卡咪哈-一个博客

本 Kubernetes 部署教程指南将通过 Nginx 示例部署解释 Kubernetes YAML 规范中的关键概念。

介绍

在 Kubernetes 中，Pod 是部署在集群中的基本单元。Kubernetes 部署是 Pod 的抽象层。部署对象的主要目的是将部署配置中声明的资源保持在其所需的状态。部署配置可以是 YAML或 JSON。

需要理解的关键概念

一次部署可以调度多个 pod。作为一个单元的 pod 不能自行扩展。单个 pod 可以有多个容器，并且单个 pod 中的这些容器共享相同的 IP，并且可以使用 localhost 地址相互通信。要访问具有一个或多个 pod 的部署，需要使用标签（labels）和选择器（selectors）映射到部署的 Kubernetes 服务端点。部署应该只有无状态服务。任何需要状态管理的应用程序都应该部署为 Kubernetes StatefulSet。

部署 YAML：

Kubernetes 部署 Yaml 包含以下主要规范：

api 版本种类元数据规格

现在让我们详细看看每个规格。

注意：在 Kubernetes 中，所有持久化的东西都被定义为一个对象。示例：部署、服务、副本集、Configmap 等

api 版本

这指定了 Kubernetes 部署对象的 API 版本。它在每个 Kubernetes 版本之间有所不同。

如何使用正确的 API 版本： Kubernetes 包含三个 API 版本。

Alpha：这是早期的候选版本。它可能包含错误，并且不能保证它将来会起作用。

例子： http://scalingpolicy.kope.io/v1alpha1

Beta：一旦经过 alpha 测试，API 就会变为 beta。它将持续开发和测试，直到它变得稳定。Beta 版本很可能会进入 Kubernetes 主要 API。

例如： batch/v1beta1

稳定：不包含 alpha 和 beta 的 API 属于稳定类别。仅建议在生产系统中使用稳定版本。

例子：apps/v1

这些 API 可能属于不同的 API 组。

下面显示了来自 Kubernetes 1.10.6 版本的不同 API 组的 Kubernetes API 示例列表。部署对象属于 apps API 组。可以使用 kubectl 代理在 http://localhost:8001/ 上列出这些 API。

{ “paths”: [ “/api”, “/api/v1”, “/apis”, “/apis/”, “/apis/admissionregistration.k8s.io”, “/apis/admissionregistration.k8s.io/v1beta1”, “/apis/apiextensions.k8s.io”, “/apis/apiextensions.k8s.io/v1beta1”, “/apis/apiregistration.k8s.io”, “/apis/apiregistration.k8s.io/v1”, “/apis/apiregistration.k8s.io/v1beta1”, “/apis/apps”, “/apis/apps/v1”, “/apis/apps/v1beta1”, “/apis/apps/v1beta2”, “/apis/authentication.k8s.io”, “/apis/authentication.k8s.io/v1”, “/apis/authentication.k8s.io/v1beta1”, “/apis/authorization.k8s.io”, “/apis/authorization.k8s.io/v1”, “/apis/authorization.k8s.io/v1beta1”, “/apis/autoscaling”, “/apis/autoscaling/v1”, “/apis/autoscaling/v2beta1”, “/apis/batch”, “/apis/batch/v1”, “/apis/batch/v1beta1”, “/apis/certificates.k8s.io”, “/apis/certificates.k8s.io/v1beta1”, “/apis/cloud.google.com”, “/apis/cloud.google.com/v1beta1”, “/apis/extensions”, “/apis/extensions/v1beta1”, “/apis/metrics.k8s.io”, “/apis/metrics.k8s.io/v1beta1”, “/apis/networking.k8s.io”, “/apis/networking.k8s.io/v1”, “/apis/policy”, “/apis/policy/v1beta1”, “/apis/rbac.authorization.k8s.io”, “/apis/rbac.authorization.k8s.io/v1”, “/apis/rbac.authorization.k8s.io/v1beta1”, “/apis/scalingpolicy.kope.io”, “/apis/scalingpolicy.kope.io/v1alpha1”, “/apis/storage.k8s.io”, “/apis/storage.k8s.io/v1”, “/apis/storage.k8s.io/v1beta1” ] }

种类

种类描述要创建的对象/资源的类型。在我们的例子中，它是一个部署对象。以下是 Kubernetes 支持的对象/资源的主要列表。

componentstatuses configmaps daemonsets deployments events endpoints horizontalpodautoscalers ingress jobs limitranges namespaces nodes pods persistentvolumes persistentvolumeclaims resourcequotas replicasets replicationcontrollers serviceaccounts services

元数据

它是唯一标识 Kubernetes 对象的一组数据。以下是可以添加到对象的关键元数据。

labels name namespace annotations

让我们看看每种元数据类型：

标签(labels) ：主要用于对部署对象进行分组和分类的键值对。它适用于使用选择器的对象到对象分组和映射。例如，kubernetes 服务使用其选择器中的 pod 标签将流量发送到正确的 pod。我们将在服务创建部分看到更多关于标签和选择器的信息。Name：它表示要创建的部署的名称。命名空间(namespace)：要在其中创建部署的命名空间的名称。注释(annotation)：键值对，如标签，但是，用于不同的用例。您可以将任何信息添加到注释中。例如，您可以有一个类似的注释 “monitoring” : “true ，外部源将能够找到具有此注释的所有对象以抓取其指标。没有此注释的对象将被省略。

还有其他系统生成的元数据，例如 UUID、时间戳、资源版本等，它们会添加到每个部署中。

示例元数据

metadata: name: resource-name namespace: deployment-demo labels: app: web platform: java release: 18.0 annotations: monitoring: true prod: true

Spec

在 Spec 下，我们声明我们想要拥有的对象的期望状态和特征。例如，在部署规范中，我们将指定副本的数量、镜像名称等。Kubernetes 将确保规范下的所有声明都处于所需的状态。

Spec 具有三个重要的子字段。

Replicas：它将确保始终运行的 pod 数量以进行部署。例如：

spec: replicas: 3

Selector：它定义了与要管理的部署的 pod 匹配的标签。例如：

selector: matchLabels: app: nginx

Template：它有自己的元数据和 spec。Spec 将包含 pod 应具有的所有容器信息，容器映像信息、端口信息、ENV 变量、命令参数等。例如：

template: metadata: labels: app: nginx spec: containers: – image: nginx name: nginx

Kubernetes 示例部署

由于我们已经了解了基础知识，让我们从一个示例部署开始。我们将在本节中执行以下操作。

创建命名空间创建 Nginx 部署创建 Nginx 服务暴露和访问 Nginx 服务

注意：我们在这个例子中执行的一些操作可以只使用 kubectl 并且没有 YAML 声明来执行。但是，我们将 YAML 规范用于所有操作以更好地理解它。

练习文件夹

要开始练习，请创建一个名为 deployment-demo 的文件夹，并将 cd 放入该文件夹。在此文件夹中创建所有练习文件。

mkdir deployment-demo && cd deployment-demo

创建命名空间

让我们创建一个名为 namespace.yaml 的 apiVersion: v1 kind: Namespace metadata: name: deployment-demo labels: apps: web-based annotations: type: demo

使用 kubectl 命令创建命名空间。

kubectl create -f namespace.yaml

等效的 kubectl 命令

kubectl create namespace deployment-demo

将资源配额分配给命名空间

现在让我们为新创建的命名空间分配一些资源配额限制。这将确保部署在此命名空间中的 pod 不会消耗比资源配额中提到的更多的系统资源。

创建一个名为 resourceQuota.yaml 的文件。这是资源配额 YAML 内容。

apiVersion: v1 kind: ResourceQuota metadata: name: mem-cpu-quota namespace: deployment-demo spec: hard: requests.cpu: “4” requests.memory: 8Gi limits.cpu: “8” limits.memory: 16Gi

使用 YAML 创建资源配额。

kubectl create -f resourceQuota.yaml

现在，让我们描述命名空间以检查资源配额是否已应用于部署演示命名空间。

kubectl describe ns deployment-demo

输出应如下所示。

Name: deployment-demo Labels: apps=web-based Annotations: type=demo Status: Active Resource Quotas Name: mem-cpu-quota Resource Used Hard ——– — — limits.cpu 0 2 limits.memory 0 2Gi requests.cpu 0 1 requests.memory 0 1Gi

创建部署

我们将使用公共 Nginx 映像进行此部署。

创建一个名为 deployment.yaml 的文件并将以下 YAML 复制到该文件中。

注意：此部署 YAML 所需的信息最少，我们在上面讨论过。您可以根据需要在部署 YAML 中有更多规范。

apiVersion: apps/v1 kind: Deployment metadata: name: nginx labels: app: nginx namespace: deployment-demo annotations: monitoring: “true” spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: – image: nginx name: nginx ports: – containerPort: 80 resources: limits: memory: “2Gi” cpu: “1000m” requests: memory: “1Gi” cpu: “500m”

在容器下，我们定义了它的资源限制、请求和容器端口（在 Dockerfile 中公开的一个）。

使用 kubectl 创建部署

kubectl create -f deployment.yaml

检查部署

kubectl get deployments -n deployment-demo

尽管我们添加了最少的信息，但在部署之后，Kubernetes 会在部署中添加更多信息，例如 resourceVersion、uid、状态等。

可以通过使用 kubectl 命令以 YAML 格式描述部署来检查它。

kubectl get deployment nginx -n deployment-demo –output yaml

创建服务并公开部署

现在我们有一个正在运行的部署，我们将创建一个指向 nginx 部署的 NodePort (30500) 类型的 Kubernetes 服务。使用 NodePort，您将能够在端口 30500 上访问所有 kubernetes 节点上的 Nginx 服务。

创建一个名为service.yaml的文件并复制以下内容。

apiVersion: v1 kind: Service metadata: labels: app: nginx name: nginx namespace: deployment-demo spec: ports: – nodePort: 30500 port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: NodePort

服务是解释标签和选择器的最佳示例。在这个服务中，我们有一个带有“app”=“nginx”标签的选择器。使用它，服务将能够匹配我们的 nginx 部署中的 pod，因为部署和 pod 具有相同的标签。因此，所有到达 nginx 服务的请求都会自动发送到 nginx 部署。

让我们使用 kubectl 命令创建服务。

kubectl create -f service.yaml

您可以查看使用 kubectl 命令创建的服务。

kubectl get services -n deployment-demo

现在，您将能够在端口 30500 上的任何一个 kubernetes 节点 IP 上访问 nginx 服务

例如，

http://35.134.110.153:30500/

THE END