泽民博客 ☰ Menu

selector

当需要从集群外部访问k8s里的服务的时候，方式有四种：ClusterIP（默认）、NodePort、LoadBalancer、ExternalName 。



一、ClusterIP
该方式是指通过集群的内部 IP 暴露服务，但此服务只能够在集群内部可以访问，这种方式也是默认的 ServiceType。
VIP，是 Kubernetes 自动为 Service 分配的。对于这种方式称为 ClusterIP 模式的 Service。



二、NodePort
通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 NodeIP:Port，可以从集群的外部访问一个 NodePort 服务。



spec.selector 这个Service将要使用哪些Label，本例中指所有具有 run: my-nginx 标签的Pod。



三、LoadBalancer
使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上,该模式需要底层云平台（例如GCE、亚马孙AWS）支持。
四、ExternalName
创建一个dns别名指到service name上，主要是防止service name发生变化，要配合dns插件使用。



通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如 foo.bar.example.com）。
没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。




LoadBalancer 类型的 Service，它会为你在 Cloud Provider（比如：Google Cloud 或者 OpenStack）里创建一个与该 Service 对应的负载均衡服务。但是，相信你也应该能感受到，由于每个 Service 都要有一个负载均衡服务，所以这个做法实际上既浪费成本又高。作为用户，我其实更希望看到 Kubernetes 为我内置一个全局的负载均衡器。然后，通过我访问的 URL，把请求转发给不同的后端 Service。这种全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的 Ingress 服务。



https://blog.haohtml.com/archives/19945
一、资源元信息




  1. Kubernetes 资源对象
    我们知道，Kubernetes 的资源对象组成： 主要包括了 Spec、Status 两部分。 其中 Spec 部分用来描述期望的状态，Status 部分用来描述观测到的状态。 今天我们将为大家介绍 K8s 的另外一个部分，即元数据部分。 该部分主要包括了用来识别资源的标签： Labels， 用来描述资源的注解； Annotations， 用来描述多个资源之间相互关系的 OwnerReference。 这些元数据在 K8s 运行中有非常重要的作用。

  2. labels
    第一个元数据，也是最重要的一个元数据——资源标签。 资源标签是一种具有标识型的 Key： Value 元数据


  3. Selector
    最常见的 Selector 就是相等型 Selector。 现在举一个简单的例子： 假设系统中有四个 Pod，每个 Pod 都有标识系统层级和环境的标签，我们通过 Tie： front 这个标签，可以匹配左边栏的 Pod，相等型 Selector 还可以包括多个相等条件，多个相等条件之间是逻辑”与“的关系。 在刚才的例子中，通过 Tie=front,Env=dev 的 Selector，我们可以筛选出所有 Tie=front，而且 Env=dev 的 Pod，也就是下图中左上角的 Pod。 另外一种 Selector 是集合型 Selector，在例子中，Selector 筛选所有环境是 test 或者 gray 的 Pod。 除了 in 的集合操作外，还有 notin 集合操作，比如 tie notin(front,back)，将会筛选所有 tie 不是 front 且不是 back 的 Pod。 另外，也可以根据是否存在某 lable 的筛选，如： Selector release，筛选所有带 release 标签的 Pod。 集合型和相等型的 Selector，也可以用“，”来连接，同样的标识逻辑”与“的关系。




  4. Annotations
    另外一种重要的元数据是： annotations。 一般是系统或者工具用来存储资源的非标示性信息，可以用来扩展资源的 spec/status 的描述，这里给了几个 annotations 的例子： 第一个例子，存储了阿里云负载器的证书 ID，我们可以看到 annotations 一样可以拥有域名的前缀，标注中也可以包含版本信息。 第二个 annotation存储了 nginx 接入层的配置信息，我们可以看到 annotations 中包括“，”这样无法出现在 label 中的特殊字符。 第三个 annotations 一般可以在 kubectl apply 命令行操作后的资源中看到， annotation 值是一个结构化的数据，实际上是一个 json 串，标记了上一次 kubectl 操作的资源的 json 的描述。



  5. Ownereference
    最后一个元数据叫做 Ownereference。 所谓所有者，一般就是指集合类的资源，比如说 Pod 集合，就有 replicaset、statefulset，这个将在后序的课程中讲到。 集合类资源的控制器会创建对应的归属资源。 比如： replicaset 控制器在操作中会创建 Pod，被创建 Pod 的 Ownereference 就指向了创建 Pod 的 replicaset，Ownereference 使得用户可以方便地查找一个创建资源的对象，另外，还可以用来实现级联删除的效果。



现在查看一下 Pod 打的标签，我们用 –show-labels 这个选项，可以看到这两个 Pod 都打上了一个部署环境和层级的标签；
kubectl get pods —show-labels



假如说有多个相等的条件需要指定的，实际上这是一个与的关系，假如说 env 再等于 dev，我们实际上是一个 Pod 都拿不到的；
kubectl get pods —show-labels -l env=test,env=dev



我们还可以再试一下怎么样用集合型的 label Selector 来进行筛选。这一次我们还是想要匹配出所有部署环境是 test 或者是 dev 的一个 Pod，所以在这里加上一个引号，然后在括号里面指定所有部署环境的一个集合。这次能把两个创建的 Pod 都筛选出来；
kubectl get pods —show-labels -l ’env in (dev,test)’



https://blog.csdn.net/weixin_39683526/article/details/111623592



Label selector是Kubernetes核心的分组机制，通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象。



Label selector的使用场景



1.kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程



2.kupe-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立器每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制



3.通过对某些Node定义特定的Label,并且在Pod定义文件中使用NodeSelector这种标签调度策略，Kube-scheduler进程可以实现Pod定向调度的特性



在前面的留言板例子中，我们只使用了一个name=XXX的Label Selector。让我们看一个更复杂的例子。假设为Pod定义了Label: release、env和role，不同的Pod定义了不同的Label值，如图1.7所示，如果我们设置了“role=frontend”的Label Selector，则会选取到Node 1和Node 2上到Pod。



https://www.cnblogs.com/rengke2002/p/13234170.html



K8S中的Service是一个抽象概念，它定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务



举个例子：一个a服务运行3个pod，b服务怎么访问a服务的pod，pod的ip都不是持久化的重启之后就会有变化。
这时候b服务可以访问跟a服务绑定的service，service信息是固定的提前告诉b就行了，service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的。



https://www.cnblogs.com/freeaihub/p/12967117.html
kubectl get svc –show-labels -l run=xxx



Category k8s