Kubernetes组件-ReplicaSet
⒈简介
最初，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
创建此ReplicaSet后将会从当前所有的pod中匹配app=coreqi选择器，ReplicaSet将把符合选择器的pod归为自己的管辖范围，如果满足当前ReplicaSet要求的实例数量则不会触发创建任何新的pod。
apiVersion指定了两件事情：
- API组（在这种情况下是apps)
- 实际的API版本（v1)
某些Kubernetes资源位于所谓的核心API组中，该组并不需要在apiVersion字段中指定API组仅仅只需指定实际的API版本即可，例如ReplicationController
Kubermetes在后续的版本中引入其他资源，被分为几个API组。
创建以上描述文件后使用kubectl命令创建ReplicaSet
kubectl create -f coreqi-manual.yaml
可以使用kubectl get 和 kubectl describe来检查ReplicaSet
#rs是ReplicaSet的缩写
kubectl get rs
kubectl describe rs
⒋ 使用ReplicaSet更富表达力的标签选择器
ReplicaSet 相对于ReplicationController的主要改进是它更具表达力的标签选择器。在上面定义ReplicaSet示例中，用较简单的matchLabels选择器来确认ReplicaSet与ReplicationController没有区别。现在，我们用更强大的matchExpressions 属性来重写选择器。
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需要的标签 matchExpressions: #选择器表达式，每个表达式都必须包含一个key，一个operator（运算符），并且可能还有一个values列表（取决于运算符），如果指定多个表达式，之间为and的关系，即表达式之间都为true - key: app #此选择器要求该pod包含名为"app"的标签 operator: In #运算符，有四个有效的运算符 #In：LabelValue的值必须和values列表中的一个值相匹配 #NotIn：LabelValue的值不与values列表中的值相匹配 #Exists：pod必须包含一个指定名称的LabelKey（值不重要）。使用此运算符，不应指定values字段。 #DoesNotExist：pod不得包含有指定名称的LabelKey。使用此运算符，不得指定values values: #values列表(取决于运算符) - coreqi #标签的值必须为"coreqi" 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
⒌删除ReplicaSet
应始终使用ReplicaSet作为ReplicationController的替代。但仍可以在其他人的部署中找到 ReplicationController。
使用以下命令删除ReplicaSet
kubectl delete re {reName}
删除ReplicaSet会删除所有的pod。这种情况下是需要列出pod来确认的。
