k8s service网络

资源

从整体来看，Kubernetes集群是由很多由JSON或者YAML定义的‘资源’组成，我个人比较推崇使用YAML写配置，因为它读写都很容易，同时还支持注释。

在Kubernetes中启动一个应用需要了解的几个基本‘资源’类型，如：Pod、Deployment（复制控制器）、Service与Namespace。
1. Deployment是Kubernetes集群的管理引擎，它负责管理集群中的Pod启停，如：负责配置一个集群中一共需要跑多少个Pod，Pod运行的内容，以及根据部署方案或者Node、集群发生的问题来决定如何来启停Pod。
2.
一个集群可以有多个Deployment，每个Deployment管理多个Pods与容器；但是，如何将容器中运行的服务暴露给外部网络呢？这就需要Service来解决了。Service提供了一个从Deployment与Pod到外部网络以及外部网络到内部容器的一个双工的通道。
3. 服务为一组Pod提供单一稳定的名称和地址。他们作为基本负载均衡器而存在。kube-proxy主要用于实现k8s的service机制，提供一部分SDN功能以及集群内部的智能LoadBalancer。
4. Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。
5. 在Service上面我们还可以定义它的Namespace属性，它实际上只是个标识符，用于封装、划分你的基础设施。

网络

kubernetes不提供网络解决方案，要确保master和所有minion的容器能互相通信，需要提供网络解决方案。比较常用的是etcd+flannel。

1. k8s的service的网络类型有三种：cluertip，nodeport，loadbanlance。
2. 如果一个service想向外部暴露服务，有nodeport和loadbanlance类型，但是nodeport类型需要知道service对应的pod所在node的ip，而loadbanlance通常需要第三方云服务商提供支持，如果没有第三方服务商服务的就没办法做了。
3. 除此之外还有很多其他的替代方式，如通过ingress的方式来实现service的对外服务的暴露。
4. service的cluster-ip是k8s系统中的虚拟ip地址，只能在内部访问。若需要在外部访问的话可以通过NodePort或者LoadBalancer的方式。
5. service type 目前有两种，如果使用 gce 的 kubernetes，可以直接使用LoadBalancer类型，gce 会自动帮忙生成一个对外的 ip，并帮你做负载均衡。

如果不是在 gce 平台，可以选择使用NodePort的类型，这样会在 node 里面添加一个对外的端口号，可以通过 nodeIP:nodePORT 来访问。可以自己搭建nginx 或者使用云服务商的负载均衡器来做处理。

目前，只是Cluster、LoadBalancer和NodePort三种方式，Cluster只能在集群内访问，LoadBalancer依赖IaaS服务，如果都不适用建议使用NodePort。

PS:

nodePort跟LoadBalancer其实是同一种方式。参见这里的说明

区别在于LoadBalancer比nodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流。cloud provider好像支持了openstack、gce等系统。

nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步导给对应的pod。

所以service采用nodePort的方式，正确的方法是在前面有一个lb，然后lb的后端挂上所有node的对应端口。这样即使node1挂了。lb也可以把流量导给其他node的对应端口。