kubernetes基础知识之服务service和代理模式

kubernetes service 是暴露服务的重要方式。

ReplicationController RC和ReplicaSet RS控制器可以保障当前的pod副本数量和期望值一致。

Deployment deploy控制器基于replicaset RS的管理创建pod，提供了一种声明式的表达方式，支持滚动更新和回滚。

statefulset控制器去解决数据持久化的问题。

daemonset DS控制器保证每个节点有且只有一个pod，并且动态地随着集群的创建而增加pod节点数量。

job和cronjob cj 控制器完成批处理任务，cronjob控制器可以周期性地创建job，去完成批处理任务。

Horizontal Pod Autoscaler HPA控制器根据负载情况自动调整pod的副本数量，自动扩缩容来提高应用的响应能力和资源利用率。

pod控制器解决的是一个微服务或者一个应用的发布问题。有了控制器，可以批量创建相似的pod。

给用户提供一个统一的接口，来提供负载均衡的能力，必须借助到service来提供，service是kubernetes集群中暴露服务的一种重要方式。

Endpoint端点是service服务底层的一个重要对象。

查看服务类型：

kubectl get svc --all-namespaces | awk -F ' ' '{print $3}'| sort | uniq

service服务的概念和原理：

kubernetes service定义了一种抽象：一个pod的逻辑分组，一种可以访问它们的策略，访问服务的策略通常称为微服务。这一组pod能够被service访问到，通常是通过Label Selector。

微服务，如果服务的框架很复杂，某一个组件需要升级或者某一项功能需要升级，会影响全局。这时候可以借助微服务的思想，将整体服务分散成不同的小的独立的模块，这些模块整体就是全部的功能。但是分开的时候，又各自实现一部分功能。这样的每个小模块，我们就叫做一个微服务。多个微服务组合在一起，就形成了整体的功能。

使用微服务的好处：

①：不同的团队可以开发不同的微服务模块，解决不同的功能问题。

②：某一块的微服务出现性能的下降，由于访问量产生性能的下降，我们可以针对性地给它增加更多的节点，去提高它的用户访问量，去提高它的性能。

③：某一个模块损坏后，不去影响其他模块的运行。

并不是所有的场景都适合使用微服务业务的，只有规模足够大、业务的逻辑足够复杂，上微服务才有意义。

传统的架构不适合微服务的部署。

每一个微服务都可以通过控制器加上service服务做到。

一组pod能够被service服务访问到，通常是通过Label Selector标签选择器。

就绪探测readiness Probe一旦就绪通过之后，并且pod符合service的标签选择器，那么这样的pod就会被获取到当前的负载均衡集群中，去实现负载访问。

用户一般通过访问外部端点，然后访问服务。服务会通过服务的标签选择器，去把服务请求负载到后端的pod中。

deployment deploy控制器的作用：控制器基于replicaset RS的管理创建pod，提供了一种声明式的表达方式，支持滚动更新和回滚。

服务service的作用是把多副本的pod以负载均衡的方式提供给客户去访问。负载均衡集群一定要给多个不同的机器、同样的服务提供一个统一的端点，这样我们才允许用户访问。

Tomcat的缺点是：Tomcat是免费开源的软件，对静态资源的支持不好。

Tomcat一般与Nginx配合使用。Nginx对静态资源的处理能力非常棒，我们可以做一个反向代理，将静态资源交给nginx本身处理，将动态的一些请求交给Tomcat处理。

Nginx反向代理Tomcat可以使用nginx的upstream和server区域的Proxy_pass设置实现，通过proxy_pass反向代理可以把请求转到upstream区域，这样就实现了负载均衡。

Nginx具备对七层服务存活的探测能力。

传统的Nginx反向代理tomcat的方案：

上层是N个Nginx，下层是M个Tomcat。

kubernetes service方案：

上层N个nginx pod，中间是服务service，下层是M个Tomcat pod。

服务service选择pod的两个条件：

①：标签选择器必须完全匹配。

②： pod状态必须要就绪。

在kubernetes负载均衡集群和反向代理的前后端解耦方案中，需要把nginx的proxy_pass配置到service的IP。

只要kubernetes集群运行正常，那么当前的service服务就会一直存在。

抓取最新的后端的pod信息交给service去做，类似前端的应用，直接反向代理到当前的service本身，这样前后端就解耦了。

只要当前的后端pod终止掉，那么service服务就会把它从负载均衡集群中剔除掉。然后将最新创建出来的pod给添加到负载均衡集群里面。

kubernetes 中service的底层原理：

在kubernetes集群中，每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟IP）的形式。

它的底层原理并不是一成不变的。在kubernetes v1.0版本，代理完全在userspace，也就是代理完全在我们当前的用户空间去实现。在kubernetes v1.1版本，新增了iptables代理，但是它并不是默认的运行模式。从kubernetes v1.2版本起，默认就是iptables代理。在kubernetes v1.8.0-beta0中，添加了ipvs代理。最新的kubernetes集群中，默认的依然使用iptables防火墙的代理模式去实现service服务的负载均衡。

查看kubernetes版本信息：

kubectl get node

删除所有的cronjob创建的pod:

kubectl delete cronjob --all

使用命令创建deployment控制器类型的pod:

kubectl create deployment myapp --image=xxx/$image_name:$image_tag（deployment控制器默认创建出来1个pod）

查看pod的详细信息：

kubectl get pod -n $namespace_name（默认命名空间为default）

使用scale的方式扩容pod:

kubectl scale deployment myapp --replicas=10

查看扩容后pod的信息：

kubectl get pod -n $namespace_name -w(默认命名空间为default)

创建服务service，类型是clusterIP类型：

kubectl create svc clusterip myapp --tcp=80:80

创建的service名称最好和当前的deployment控制器的名称相同。

第一个代表tcp负载均衡集群端口，第二个代表后端真实服务器的端口。

确认service的代理模式：

执行ipvsadm -Ln,结果中规则是空，说明使用的默认代理模式是iptables，而不是ipvs。

执行ipvsadm -Ln并没有对应的ipvs规则存在，可以确认当前正在使用iptables的代理模式在运行。

在最新的kubernetes版本中，userspace用户空间的代码已经移除了。现在有的就是ipvs和iptables的代理模式。

kubernetes kube-proxy默认的代理模式是iptables，代理模式也可以从iptables迁移成ipvs的代理模式。

鼓励的话语：人生拿的起，放得下的，不止是筷子！