转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。
第一章：Docker与k8s的恩怨情仇（一）—成为PaaS前浪的Cloud Foundry
第二章：Docker与k8s的恩怨情仇（二）—用最简单的技术实现“容器”
第三章：Docker与k8s的恩怨情仇（三）—后浪Docker来势汹汹
第四章：Docker与k8s的恩怨情仇（四）-云原生时代的闭源落幕
第五章：Docker与k8s的恩怨情仇（五）——Kubernetes的创新
第六章：Docker与k8s的恩怨情仇（六）—— “容器编排”上演“终结者”大片
在上节中我们介绍了活字格想在k8s上部署，如何实现容器之间的编排与管理控制。为了进一步实现内外交互调用，则需要实现服务发现的功能。也就是我们前面提到“人与狗”之间的关系。
做过微服务的同学可能了解过什么叫服务发现，spring cloud项目中的Eureka框架就是完成这个功能的，其主要工作就是注册内部的服务，以供其他集群的服务可以调用、访问这个服务。
我们合理猜测Kubernetes的存在很有可能激发了各种微服务框架产生服务发现机制。
在Kubernetes中服务发现对应的模块是Service与Ingress，接下来，我们分别来说说这两个功能。
Service与Ingress
Service类似于服务的注册功能。
其逻辑很简单，在kubernetes声明一个服务，从而生成一个VIP（虚拟网络），所有Kubernetes集群中的其他组件，都可以通过这个VIP来访问这个服务，并且这个服务是不会随Service的改变而改变的，只要创建就是终生存在。
Service
而服务的内容是什么呢？这部分和上述的Deployment一样，是通过selector选择器确定的。我们可以通过下述yaml来创建一个服务：
apiVersion: v1
kind: Service
metadata:
name: hostnames
spec:
selector:
app: hostnames
ports:
- name: default
protocol: TCP
port: 80
targetPort: 9376
通过上一篇的介绍，我们可以了解这个服务所需要代理的内容是app==hostnames的Pod。同时这里也有一个新的字段ports，这个字段是说明该代理的服务的请求方式（protocol）、对外暴露的端口（port）、内部的端口（targetPort）分别是什么。
我们可以通过这个sample-service.yaml的文件创建一个Service并且查看一个Service：
# 创建
kubectl apply -f sample-service.yaml
# 查看
kubectl get services hostnames
在这个service中存在一个ClusterIP，这个IP就是这个Service生成的VIP，在集群内部的其他成员，都可以通过这个VIP来访问这个Service。但是由于我们现在没有任何的具体服务让这个Service代理，因此现在请求这个IP是不会成功的。
那么，我们需要为这个Service创建一个具体实现：以下的sample-deployment.yaml文件是创建一个多副本的Pod，其Pod的功能是返回自己的podname：
apiVersion: apps/v1
kind: Deployment
metadata:
name: hostnames
spec:
selector:
matchLabels:
app: hostnames
replicas: 3
template:
metadata:
labels:
app: hostnames
spec:
containers:
- name: hostnames
image: k8s.gcr.io/serve_hostname
ports:
- containerPort: 9376
protocol: TCP
~
在这段代码中，我们把容器的9376端口暴露的出来，因为这个Pod是通过这个端口与外部通行的。同样我们执行以下命令创建和查看这个pod副本：
# 创建
kubectl apply -f sample-deployment.yaml
# 查看
kubectl get pods -l app=hostnames
在这部分内容中可以看到这个pod副本已经创建成功了。此时，根据我上一节所说的控制器模式，Service也有对应的处理Service的控制器，其内部发现了有满足app==hostnames的服务，即将这个服务和Service进行了绑定 。此时，我们就可以通过任意一台集群内的主机来请求刚才上文中的ClusterIP：
在这一部分可以看到，我们进行了很多次请求，但是每次返回的结果都不同，这是因为Service在其内部通过网络插件（CNI）做了负载均衡处理，所以我们可以通过Service来实现的负载均衡功能。
学习过程中的“误入歧路”
在学习了解这部分内容的时候，我一直有一个误解：认为Service是必须对应Deployment这种Pod的编排控制器对象才能工作的，所以把Service --> Deployment --> Pods这条逻辑关系熟记于心，但这种理解其实是错误的。
在Kubernetes中，每个功能组件各司其职，他们只会处理自己该做的事，比如这里，Service绑定Pod所依赖的是选择器中的app==hostnames，而这个定义是出现在Deployment中定义在Pod中的，因此Service和Deployment完全没有关系，它们俩谁也不认识谁，关系可以用下图来描述：
并且，在之前的学习中还错误地认为负载均衡服务是由Deployment提供的，其实这个功能是Service中的网络插件来处理的，并且用户同样也可以自定义使用的网络查件或者负载均衡算法是什么，Kubernetes给了用户足够大的自由度。
Ingress
有了Service之后，我们的服务就可以在集群中随意访问达到服务之间的交流关系了， 但是要想让我们的服务让最终的用户访问到，我们还需要最后一个组件Ingress。
Ingress是Kubernetes中的反向代理服务，它可以解析配置的域名指向到我们内部的Service中，其定义可以通过下述的yaml来实现：
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: sample-ingress
spec:
rules:
- host: hostname.sample.com
http:
paths:
- path: /
backend:
serviceName: hostnames
servicePort: 80
上述代码中，我们将hostname.sample.com这个域名指向了刚才定义的hostnames这个Service。通过这样的操作，我们的服务便就可以通过定义域名配置供外部的服务进行访问了。而Ingress的创建命令，也和前面所说的一样：
kubectl apply -f sample-ingress.yaml
有了这部分配置，我们的功能原则上就能够让外部访问了。但在实际应用中我们本地没有可供测试的环境，本地的Kubernetes环境是通过kindD生成的，其核心是多个Docker Container而不是多台机器。上述内容在Container内部运行，是使用Docker模拟Kubernetes的功能，因此这也是本文中唯一无法验证成功的一个功能模块。
完整部署一个活字格应用
通过上节我们一起学习了Pod间的编排控制器的使用，本节中实现了内外交互调用，进一步实现服务发现的功能，我们现在就可以再次回到之前提出的问题： 究竟如何成功部署一个活字格应用。
通过介绍整个Kubernetes的基础使用的流程，我们可以看到一个服务在Kubernetes变成Pod，通过Deployment部署，通过Service服务发现，通过Ingress反向代理的全过程，经过这些模块的协力配合之后，我们的活字格应用终于可以部署在这个Kubernetes集群中了。
希望这张图片展示，能够为大家带来更加直观的感觉。
总结
截止到本章，我们已经完整介绍了活字格做k8s部署的全过程。下一节将会为大家带来本系列文章的最后一篇——Kubernetes总览，让大家对Kubernetes集群内容部分有一个整体性印象，对一些深层次功能做一个总结。
感兴趣的小伙伴不要错过~我们下篇接着聊。