在 Kubernetes 集群外用 Service 暴露应用(Step1)

目标

  • 了解Kubernetes中的Service
  • 了解标签(Label)和标签选择器(Label Selector) 对象如何与 Service 关联
  • 在 Kubernetes 集群外用 Service 暴露应用

Kubernetes Service 总览

Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态,以保证应用程序正常运行。 换一个例子,考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本,即使 Pod 丢失或重新创建。也就是说,Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址,因此需要一种方法自动协调 Pod 之间的变更,以便应用程序保持运行。
Kubernetes 中的服务(Service)是一种抽象概念,它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。
尽管每个 Pod 都有一个唯一的 IP 地址,但是如果没有 Service ,这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露

  • ClusterIP (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。
  • NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用: 从集群外部访问 Service。是 ClusterIP 的超集(定义:如果一个集合S2中的每一个元素都在集合S1中,且集合S1中可能包含S2中没有的元素,则集合S1就是S2的一个超集,反过来,S2是S1的子集。 S1是S2的超集,若S1中一定有S2中没有的元素,则S1是S2的真超集,反过来S2是S1的真子集)。
  • LoadBalancer - 在当前云中创建一个外部负载均衡器(如果支持的话),并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
  • ExternalName - 通过返回带有该名称的 CNAME 记录,使用任意名称(由 spec 中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。
    ##本文实例是使用NodePort标记type的方式暴露。
    另外,需要注意的是有一些 Service 的用例没有在 spec 中定义selector。 一个没有selector创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用type: ExternalName来标记。
    在 Kubernetes 集群外用 Service 暴露应用(Step1)
    Service 通过一组 Pod 路由通信。Service 是一种抽象,它允许 Pod 死亡并在 Kubernetes 中复制,而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。
    ##可以再创建Deployment的同时用–expose创建一个Service。
    Service 匹配一组 Pod 是使用 标签(Label)和选择器(Selector), 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对,可以以多种方式使用:
  • 指定用于开发,测试和生产的对象
  • 嵌入版本标签
  • 使用 Label 将对象进行分类
    在 Kubernetes 集群外用 Service 暴露应用(Step1)
    标签(Label)可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。

实例操作

Step 1

创建一个新服务(nginx):

kubectl create deployment k8s-nginx  --image=nginx  -r 1

查看pod:

kubectl get pod

如果没有运行pod,则意味着交互环境仍在重新加载之前的状态。稍等几秒钟,再执行一遍。当看到一个Pod运行时,就可以继续了。
查看部署:

kubectl get deployments

查看部署创建的复制集:

kubectl get rs

列出集群中当前的服务

kubectl get services

将nginx服务公开给外部流量,这里使用的是带NodePort参数的expose命令(minikube还不支持LoadBalancer选项)。

kubectl expose deployment/k8s-nginx --type="NodePort" --port 80

(nginx启动的是默认监听的80端口,所以这里容器暴露的是80端口)

[root@minikube ~]# kubectl get services
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes     ClusterIP   10.96.0.1       <none>        443/TCP          41h
k8s-nginx      NodePort    10.98.195.174   <none>        80:31331/TCP   8s

现在可以看到一个正在运行的服务,名为k8s-nginx。服务接收到一个唯一的集群IP、一个内部端口和一个外部IP(节点的IP)。
查看服务的详细信息:找出外部打开的端口(通过NodePort选项)

[root@minikube lib]# kubectl describe service  k8s-nginx 
Name:                     k8s-nginx
Namespace:                default
Labels:                   app=k8s-nginx 
Annotations:              <none>
Selector:                 app=k8s-nginx 
Type:                     NodePort
IP Families:              <none>
IP:                       10.108.47.2
IPs:                      <none>
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31331/TCP
Endpoints:                172.17.0.5:80,172.17.0.6:80,172.17.0.8:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

在本机使用curl、节点的IP和外部暴露的端口测试应用程序是否暴露在集群之外:

curl 192.168.0.229:31331

也可以再真实机*问192.168.0.229:31331,会显示如下效果,nginx服务被成功暴露了出来。
在 Kubernetes 集群外用 Service 暴露应用(Step1)

问题

在检查过程中如果出现在容器所在服务器,通过 curl 命令直接访问外部端口的接口能够正常访问,在 windows 端通过 telnet 命令,无法访问不通外部端口。一般是iptables规则里FORWARD默认为DROP,只需将其改为ACCEPT即可。

iptables -P FORWARD ACCPRT

总结

  • 将 Pod 暴露给外部通信 #Step 1已完成
  • 跨多个 Pod 的负载均衡
  • 使用标签(Label)
上一篇:因为β随着err(k)的变化在不是修改着控制器的表达式


下一篇:SAPUI5 WalkThrough Step 1: Bootstrap