在 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来标记。
Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。
##可以再创建Deployment的同时用–expose创建一个Service。
Service 匹配一组 Pod 是使用 标签(Label)和选择器(Selector), 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用: - 指定用于开发，测试和生产的对象
- 嵌入版本标签
- 使用 Label 将对象进行分类
标签(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服务被成功暴露了出来。
问题
在检查过程中如果出现在容器所在服务器，通过 curl 命令直接访问外部端口的接口能够正常访问，在 windows 端通过 telnet 命令，无法访问不通外部端口。一般是iptables规则里FORWARD默认为DROP，只需将其改为ACCEPT即可。
iptables -P FORWARD ACCPRT
总结
- 将 Pod 暴露给外部通信 #Step 1已完成
- 跨多个 Pod 的负载均衡
- 使用标签(Label)
标签：Kubernetes,Service,IP,nginx,Step1,Pod,80 来源： https://blog.csdn.net/qq_45492289/article/details/114647642