⒈简介
最初,ReplicationController是Kubernetes用于复制和在异常时重新调度节点的唯一组件,后来Kubernetes又引入了一个名为ReplicaSet的类似资源。它是新一代的ReplicationController,并且最终将完全替换掉ReplicationController(ReplicationController最终将被弃用)。它们几乎完全相同,因此ReplicaSet与ReplicationController的替换过程中几乎不会碰到任何麻烦。
通常不会直接创建它们,而是在创建更高层级的Deployment资源时自动创建它们。
⒉比较ReplicaSet 和ReplicationController
ReplicaSet的行为与ReplicationController完全相同,但pod选择器的表达能力更强。ReplicationController的标签选择器只允许包含某个标签然后去匹配pod,而ReplicaSet的标签选择器还允许匹配缺少某个标签的pod,或包含特定标签名的pod而无论其值如何。
另外,举个例子,单个ReplicationControler 无法将pod与标签env=production和env=deve1同时匹配。因为这两个标签拥有相同的LabelKey,它只能匹配带有env=deve1标签的pod或带有env=devel标签的pod。但是一个ReplicaSet可以匹配两组pod并将它们视为一个大组。
ReplicationController无法仅基于标签名(LebelKey)的存在来匹配pod,而ReplicaSet则可以。例如,ReplicaSet可匹配所有LabelKey为env的标签的pod,无论这个标签的LabelValue的实际值是什么(可以理解为env=*)。
⒊定义(创建)ReplicaSet
使用JSON或YAML创建k8s资源
apiVersion: apps/v1 #指定当前描述文件遵循apps/v1版本的KubernetesAPI,它不再属于v1,ReplicaSet不再是v1 API的一部分而属于apps/v1,需要确保在创建资源时指定正确的apiVersion。 kind: ReplicaSet #我们在描述一个ReplicaSet metadata: name: coreqi-manual #指定ReplicaSet的名称 spec: replicas: 3 #pod实例的目标数目 selector: #pod选择器决定了ReplicaSet的操作对象,和ReplicationController定义区别,在选择器中不必在selector属性中直接列出pod需要的标签,而是在selector.matchLabels下指定它们。这是ReplicaSet中定义标签选择器更简单(也更不具表达力)的方式 matchLabels: #这里使用了更简单的matchLabels选择器,这非常类似于ReplicationController的选择器 app: coreqi #当前ReplicaSet将确保符合标签选择器app=coreqi的pod实例始终是三个,当没有足够的pod时,将使用下面的pod模板创建新的pod template: #创建新pod所使用的pod模板 metadata: labels: app: coreqi #模板中的pod标签显然必须和ReplicationController的标签选择器相匹配,否则控制器将无休止的创建新的pod实例。因为创建新的pod不会使实际的副本数量接近期望的副本数量。为了防止出现这种情况,Kubernetes API服务会校验ReplicaSet的定义不会接收错误的配置。 #不指定ReplicaSet的标签选择器也是一种选择,因为ReplicaSet会自动从模板中提取标签,而且描述文件也将更简短 spec: containers: - name: coreqi image: fanqisoft/coreqi ports: - containerPort: 8080
apiVersion指定了两件事情:
某些Kubernetes资源位于所谓的核心API组中,该组并不需要在apiVersion字段中指定API组仅仅只需指定实际的API版本即可,例如ReplicationController
Kubermetes在后续的版本中引入其他资源,被分为几个API组。
原文:https://www.cnblogs.com/fanqisoft/p/11422820.html