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:  #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: 

　　创建此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:  #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: 

⒌删除ReplicaSet

　　应始终使用ReplicaSet作为ReplicationController的替代。但仍可以在其他人的部署中找到 ReplicationController。

　　使用以下命令删除ReplicaSet

kubectl delete re {reName} 

　　删除ReplicaSet会删除所有的pod。这种情况下是需要列出pod来确认的。