目录
通过Service访问应用
-
通过Pod IP访问应用
-
通过ClusterIP Service在集群内部访问
通过Service访问应用
通过之前的操作，应用部署完成了，我们的Demo网站已经成功启动了，那么如何访问网站呢？
通过Pod IP访问应用
我们可以通过Pod IP来访问之前部署的网站，但是前提是我们需要知道Pod IP。我们可以通过“kubectl get”命令的参数“-o wide”来输出相关的信息，比如Pod IP：
kubectl get pods -lapp=demo -o wide
如果网络是通畅的，那么我们可以在任意的节点上访问我们的应用，如：
curl --head http://10.0.2.12
我们使用curl以get方式请求demo应用，返回请求头为200，那么表示我们已经成功访问了Demo。如果你还不太相信，我们可以通过安装了UI界面的CentOS节点服务器的浏览器上访问这些Pod IP，如下所示：
虽然我们通过Pod IP成功的访问到了应用，但是Pod有生老病死，如果“死”了呢，我们如何访问？Deployment会重建么？我们来试一试：
kubectl delete pods -lapp=demo kubectl get pods -lapp=demo -o wide
很不幸的是，如上图所示，POD IP变掉了。那么意味着POD IP会随着POD的生老病死而发生变化。而且，不仅存在这个问题，如果我们直接使用POD IP，那么多个POD也变得毫无意义。那么我们应该到底如何来访问我们的应用呢？
通过ClusterIP Service在集群内部访问
Kubernetes服务（Service）就是为此而抽象出来的，为了让应用能够稳定的输出，Service应运而生。
Service在Kubernetes中是一个抽象的概念，它定义了一组逻辑上的Pod和一个访问它们的策略（通常称之为微服务）。Service是通过标签选择器来绑定一组Pod 的Endpoints（端点）对象，当Pod的IP发生变化，Endpoints也随之变化。当Service接受到请求时，就能通过EndPoints找到请求转发的目标Pod地址。也就是说，通常情况下，Service定义了集群IP和端口，EndPoints则维护了一组Pod IP和端口。
了解了这些，接下来我们就使用ClusterIP Service来访问刚才的Demo应用。
ClusterIP Service是默认的Service类型，其通过集群的内部IP暴露服务，因此仅能在集群内部访问，常用于数据库等应用。
这里，我们定义一个简单的Service集群IP配置：
apiVersion: v1 kind: Service #资源类型 metadata: #标准元数据 name: demo-service #服务名称 spec: #规范定义 type: ClusterIP #服务类型，不填写此字段则默认为ClusterIP类型，也就是集群IP类型 selector: #标签选择器 app: demo #标签 ports: #端口 - protocol: TCP #协议，能够支持TCP和UDP port: 80 #当前端口 targetPort: 80 #目标端口
接下来，我们来执行Service的创建并且分别查询了Service和Endpoints：
kubectl create -f clusterIPService.yaml kubectl get services demo-service -o wide kubectl get endpoints demo-service -o wide
如上图所示，我们创建了集群IP为“11.13.47.67”的Service，端口为80（通常情况下，我们将port和targetPort设置为相同的值）。同时我们通过Endpoints列表看到，Endpoints自动绑定了5个Pod IP。接下来我们试试在集群内（节点上）访问：
注意：如果我们需要在创建时设置Service固定IP该如何去设置呢？可以通过字段“spec.clusterIp”进行设置，值需要符合Service IP段要求。
浏览器非常完美的呈现了Demo。在集群内是可以访问了，如果我们提供对外服务呢？比如我们希望我们的Demo被其他电脑访问，以获得用户的赞赏，老板的好评，那么该如何处理呢？我们下一篇再来分析！