在本章中,我们将探讨Kubernetes对象模型,并讨论它的一些基本构建块,如Pods、ReplicaSets、Deployments、Namespaces等。我们还将讨论Labels和Selectors在微服务驱动的体系结构中扮演的重要角色,因为它们将分离的对象组合在一起。
Kubernetes有一个非常丰富的对象模型,表示Kubernetes集群中不同的持久实体。这些实体描述:
Kubernetes对象有Pods、ReplicaSets、Deployments、Namespaces等,我们将在下一步对它们进行探讨。
创建对象时,必须将spec字段下面对象的配置数据部分提交给Kubernetes API Server。spec部分描述了目标状态以及一些基本信息,比如对象的名称。创建对象的API请求必须包含spec部分以及其他详细信息。尽管API服务器接受JSON格式的对象定义文件,但我们通常以YAML格式提供这些文件,kubectl将这些文件转成JSON并将其发送到API服务器。
下面是YAML格式的部署对象配置示例:
apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15.11 ports: - containerPort: 80
apiVersion是第一个必填字段,它指定API服务器上的我们想要连接到的API端点,它必须与已定义的对象类型的现有版本匹配。第二个必需字段是kind,指定对象类型——在我们的示例中是Deployment,但它可以是Pod、Replicaset、Namespace、Service等。第三个必需字段metadata保存对象的基本信息,如name, labels, namespace等。我们的示例显示了两个spec字段(spec和spec.template.spec)。第四个必需的字段spec标记定义部署对象所需状态的块的开始。在我们的例子中,我们希望在任何给定的时间确保运行3个pod。Pods是使用spec.Template中定义的Pods模板创建的。嵌套的对象(如作为部署一部分的Pod)将保留其metadata和spec,但去掉apiVersion和kind——两者都将被template替换。在spec.template.spec中,我们定义了Pod的期望状态。我们的Pod创建了一个运行来自Docker Hub的nginx:1.15.11镜像的容器。一旦创建了部署对象,Kubernetes系统就会将status字段附加到该对象;我们稍后将对其进行研究。接下来,我们将更深入地研究一些Kubernetes对象以及其他组成部分。
Pod是最小最简单的Kubernetes对象。它是Kubernetes中的部署单元,表示应用程序的单个实例。Pod是一个或多个容器的逻辑集合,容器有如下特点:
Pods是一个或多个容器的集合
事实上Pod是短暂的,它们没有自我恢复能力。这就是为什么它们需要与处理Pod的复制、容错、恢复等的控制器一起使用。控制器有Deployments, ReplicaSets, ReplicationControllers等。我们使用Pod模板将嵌套Pod的spec附加到控制器对象,如前一节所示。
下面是YAML格式的Pod对象配置示例:
apiVersion: v1kind: Podmetadata: name: nginx-pod labels: app: nginxspec: containers: - name: nginx image: nginx:1.15.11 ports: - containerPort: 80
apiVersion字段为Pod对象定义指定"v1"。第二个必需字段是指定Pod对象类型的kind。第三个必需的字段元数据包含对象的名称和标签。第四个必需的字段spec定义Pod对象所需状态,也称为Pod spec。我们的Pod创建了一个运行来自Docker Hub的nginx:1.15.11 镜像的容器。
Label是附加到Kubernetes对象(例如Pods、ReplicaSets)的键值对。标签用于根据现有需求组织和选择对象的子集。许多对象可以具有相同的标签。标签不能为对象提供唯一性。控制器使用标签将分离的对象逻辑地组合在一起,而不是使用对象的名称或id。
在上图中,我们使用了两个Label的Key:app和env。根据我们的要求,我们给了四个吊舱不同的价值。Label env=dev在逻辑上选择并分组前两个pod,而Lable app=frontend在逻辑上选择并分组左两个pod。我们可以从左下角的四个pod中选择一个,方法是使用两个标签:app=frontend和env=qa。
Controllers使用标签选择器选择对象的子集。Kubernetes支持两种类型的选择器:
虽然不再推荐,但ReplicationController是一种控制器,它可以用于确保在任何给定时间运行指定数量的Pod副本。如果pod多于所需数量,则ReplicationController将终止额外的pod;如果pod较少,则复制控制器将创建更多的pod以匹配所需数量。通常,我们不会独立部署Pod,因为如果因为错误终止,它将无法自己重新启动。推荐的方法是使用某种类型的ReplicationController来创建和管理pod。默认控制器是一个Deployment ,它将配置ReplicaSet 为管理Pods的生命周期。
ReplicaSet是下一代复制控制器。replicationset支持基于等式和集合的选择器,而replicationcontroller只支持基于等式的选择器。目前,这是唯一的区别。在ReplicaSet的帮助下,我们可以扩展运行特定容器应用程序映像的pod的数量。缩放可以手动完成,也可以通过使用autoscaler完成。接下来,您可以看到一个replicaSet的图形表示,我们将Pod的replicas count设置为3。
现在,让我们继续同一个示例,假设其中一个pod被强制终止(由于资源不足、超时等),并且当前状态不再与所需状态匹配。
ReplicaSet将检测到当前状态不再与所需状态匹配。ReplicaSet将创建一个额外的Pod,从而确保当前状态与所需状态匹配。
ReplicaSet可以独立用作Pod控制器,但它们只提供有限的一组功能。Deployment提供了一组补充功能,这是pod编排的推荐控制器。Deployment管理pod的创建、删除和更新。Deployment会自动创建一个ReplicaSet,然后创建一个Pod。不需要单独管理ReplicaSet和pod,Deployment将代表我们管理它们。下一步我们将更仔细地研究Deployment。
Deployment对象为pod和ReplicaSet提供声明性更新。DeploymentController是master node的控制器管理器的一部分,它确保当前状态始终与所需状态匹配。它允许通过rollouts和rollbacks无缝地更新和降级应用程序,并直接管理其ReplicaSet以进行应用程序扩展。在下面的示例中,一个新的Deployment创建了ReplicaSet A,然后它创建了3个Pod,每个Pod模板配置为运行一个nginx:1.7.9容器映像。在本例中,ReplicaSetA与nginx:1.7.9相关联,nginx:1.7.9表示部署的状态。此特定状态记录为修订版1。
现在,在Deployment中,我们更改了Pods的Template,并将容器映像从nginx:1.7.9更新为nginx:1.9.1。部署为1.9.1版本的新容器映像触发新的ReplicaSet B,此关联表示部署的新记录状态,版本2。这两个ReplicaSet之间的无缝转换是Deployment滚动更新,从带有3个Pods版本1.7.9的ReplicaSet A到带有3个Pods版本1.9.1的新ReplicaSet B,或者说从修订版1到修订版2。当我们为Deployment更新Pods Template时,会触发滚动更新。scaling或labeling等操作不会触发滚动更新,因此不会更改修订号。一旦滚动更新完成,Deployment将同时显示ReplicaSets A和B,其中A被缩放为0 pod,B被缩放为3 pod。这就是Deployment如何将其先前的状态配置设置记录为修订版的方式。
一旦ReplicaSet B及其版本为1.9.1的3个Pods准备就绪,Deployments就开始积极地管理它们。但是,Deployment将其先前的配置状态保存为历史修订版,修订版在Deployment的回滚功能中起着关键作用—返回到先前已知的配置状态。在我们的示例中,如果新nginx:1.9.1的性能不令人满意,则可以将部署回滚到以前的版本,在本例中,从版本2回滚到运行nginx:1.7.9的版本1。
如果多个用户和团队使用同一个Kubernetes集群,我们可以使用名称空间将集群划分为虚拟子集群。在命名空间中创建的资源/对象的名称是唯一的,但在群集中的命名空间中不是唯一的。要列出所有命名空间,可以运行以下命令:
$ kubectl get namespacesNAME STATUS AGEdefault Active 11hkube-node-lease Active 11hkube-public Active 11hkube-system Active 11h
通常,Kubernetes创建四个默认名称空间:kube system、kube public、kube node lease和default。kube system名称空间包含由Kubernetes系统创建的对象,主要是控制平面代理。default命名空间包含管理员和开发人员创建的对象和资源。默认情况下,我们连接到default命名空间。kube public是一个特殊的名称空间,任何人都可以对其进行安全和可读,用于特殊目的,例如公开集群的公共(非敏感)信息。最新的名称空间是kube node lease,它保存用于节点心跳数据的节点租约对象。然而,好的做法是创建更多的名称空间来为用户和开发团队虚拟化集群。通过Resource Quotas,我们可以在名称空间内划分集群资源。我们将在未来的一章中简要介绍Resource Quotas。
推荐阅读:平板电脑选购指南
(正文已结束)
免责声明及提醒:此文内容为本网所转载企业宣传资讯,该相关信息仅为宣传及传递更多信息之目的,不代表本网站观点,文章真实性请浏览者慎重核实!任何投资加盟均有风险,提醒广大民众投资需谨慎!