Kubernetes核心组件Services
1. Kubernetes Service概念
Service是kubernetes最核心的概念，通过创建Service，可以为一组具有相同功能的POD（容器）应用提供统一的访问入口，并且将请求进行负载分发到后端的各个容器应用上。
在Kubernetes中，在受到RC调控的时候，Pod副本是变化的，比如发生迁移或者伸缩的时候。这对于Pod的访问者来说是不可接受的。
Kubernetes中的Service是一种抽象概念，它定义了一个Pod逻辑集合以及访问它们的策略，Service同Pod的关联同样是居于Label来完成的。Service的目标是提供一种桥梁， 它会为访问者提供一个固定访问地址，用于在访问时重定向到相应的后端，这使得非 Kubernetes原生应用程序，在无须为Kubemces编写特定代码的前提下，轻松访问后端。
Service同RC一样，都是通过Label来关联Pod的。当你在Service的yaml文件中定义了该Service的selector中的label为app:my-web，那么这个Service会将Pod–>metadata–>labeks中label为app:my-web的Pod作为分发请求的后端。
当Pod发生变化时（增加、减少、重建等），Service会及时更新。这样一来，Service就可以作为Pod的访问入口，起到代理服务器的作用，而对于访问者来说，通过Service进行访问，无需直接感知Pod。
1.2 Kubernetes Service实现方式
Kubernetes分配给Service的固定IP是一个虚拟IP，并不是一个真实的IP，在外部是无法寻址的。在真实的系统实现上，Kubernetes是通过Kube-proxy组件来实现的虚拟IP路由及转发。所以在之前集群部署的环节上，我们在每个Node上均部署了Proxy这个组件，从而实现了Kubernetes层级的虚拟转发网络。
- Kubernetes通过为每个service分配一个唯一的ClusterIP，所以当使用ClusterIP：port的组合访问一个service的时候，不管port是什么，这个组合是一定不会发生重复的。另一方面，kube-proxy为每个service真正打开的是一个绝对不会重复的随机端口，用户在service描述文件中指定的访问端口会被映射到这个随机端口上。这就是为什么用户可以在创建service时随意指定访问端口。
- K8S集群中，Pod的IP是在docker0网段动态分配的，当发生重启，扩容等操作时，IP地址会随之变化。当某个Pod(frontend)需要去访问其依赖的另外一组Pod(backend)时，如果backend的IP发生变化时，如何保证fronted到backend的正常通信变的非常重要，此时需要借助Service实现统一访问。
- Service的Virtual VIP是由Kubernetes虚拟出来的内部网络，外部是无法寻址到的。但是有些服务又需要被外部访问到，例如web前段。这时候就需要加一层网络转发，即外网到内网的转发。Kubernetes提供了NodePort、LoadBalancer、Ingress三种方式：
- NodePort，原理是Kubernetes会在每一个Node上暴露出一个端口：nodePort，外部网络可以通过（任一Node）[NodeIP]:[NodePort]访问到后端的Service。
- LoadBalancer，在NodePort基础上，Kubernetes可以请求底层云平台创建一个负载均衡器，将每个Node作为后端，进行服务分发。该模式需要底层云平台（例如GCE）支持。
- Ingress，是一种HTTP方式的路由转发机制，由Ingress Controller和HTTP代理服务器组合而成。Ingress Controller实时监控Kubernetes API，实时更新HTTP代理服务器的转发规则。HTTP代理服务器有GCE Load-Balancer、HaProxy、Nginx等开源方案。
1.3 Service实战NodePort案例实战
NodePort模式，Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的，通过:NodePort的方式Kubernetes集群外部的程序可以访问Service。
NodePort每个 Node节点的端口有很多(0~65535)，NodePort案例演练配置实战，如图所示，选择外部网络：
通过Node IP+31455端口访问，如图所示：
Nginx Service配置代码如下：
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "nginx",
"namespace": "default",
"selfLink": "/api/v1/namespaces/default/services/nginx",
"uid": "6a84483a-5262-11e8-8969-000c292f77da",
"resourceVersion": "613764",
"creationTimestamp": "2021-05-08T01:52:08Z",
"labels": {
"app": "nginx"
}
},
"spec": {
"ports": [
{
"name": "tcp-30080-80-p7s3q",
"protocol": "TCP",
"port": 30080,
"targetPort": 80,
"nodePort": 31455
}
],
"selector": {
"app": "nginx"
},
"clusterIP": "172.17.188.189",
"type": "LoadBalancer",
"sessionAffinity": "None"
},
"status": {
"loadBalancer": {}
}
}
1.4 Service- LoadBalancer实操案例一
LoadBlancer Service 是 kubernetes 深度结合云平台的一个组件；当使用 LoadBlancer Service 暴露服务时，实际上是通过向底层云平台申请创建一个负载均衡器来向外暴露服务。
目前 LoadBlancer Service 支持的云平台已经相对完善，比如国外的 GCE、DigitalOcean，国内的 阿里云，私有云 Openstack 等等，由于 LoadBlancer Service 深度结合了云平台，所以只能在一些云平台上来使用。
LoadBalancer会分配ClusterIP，分配NodePort，并且通过Cloud Provider来实现LB设备的配制，并且在LB设备中配置中，将:NodePort作为Pool Member，LB设备依据转发规则将流量转到节点的NodePort。
kubectl expose deployment nginxv1 --port=8081 --target-port=80 --type=LoadBalancer
1.5 LoadBalancer案例二
LoadBalancer，在NodePort基础上，Kubernetes可以请求底层云平台创建一个负载均衡器，将每个Node作为后端，进行服务分发。 ClusterIP模式会提供一个集群内部的虚拟IP（与Pod不在同一网段)，以供集群内部的pod之间通信使用。ClusterIP是Kubernetes service的默认类型；
为了实现上图的功能，需要以下几个组件的协同工作：
- apiserver 用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求以后将数据存储到etcd中；
- kube-proxy kubernetes的每个节点中都有一个叫做kube-proxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables中；
- Iptables 使用NAT等技术将virtualIP的流量转至endpoint中。
Cluster IP访问需要在Master /etc/kubernetes/apiserver配置文件，添加如下代码：
KUBE_SERVICE_ADDRESSES=“–service-cluster-ip-range=172.17.188.0/24”
重启apiserver及其他相关的服务即可，指令：
for I in etcd kube-apiserver kube-controller-manager kube-scheduler; do systemctl restart $I; systemctl enable $I; done
然后实战ClusterIP案例演练配置，如图所示：
基于Cluster IP访问80端口，首先要在各个NODE节点配置访问Cluster IP网段的路由，执行命令如下：
ip route add 172.17.188.0/24 dev docker0
#ip route del 172.17.188.0/24 dev docker0
访问Cluster IP:172.17.188.61的80端口，访问效果如图所示：
