我想分享的云计算技能/知识点

Kubernetes-Service

该技能/知识点的背景介绍

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

Service能够提供负载均衡的能力，但是只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

该技能/知识点实际运用

  • Service代理

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

在 Kubernetes v1.0 版本，代理完全在 userspace（用户空间）。从 Kubernetes v1.2 起，默认就是 iptables 代理。在 Kubernetes 1.14 版本开始默认使用  ipvs 代理。

在 Kubernetes v1.0 版本，Service 是 “4层”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了 Ingress API（应用程序编程接口）（beta 版），用来表示 “7层”（HTTP）服务

问：为何不使用 round-robin（轮询） DNS？

应用程序没有对DNS缓存做有效的处理，会记录DNS解析记录，造成负载均衡的不均衡。

1、username代理模式

缺点：转发由kube-proxy处理，kube-proxy的压力太大，所有的负载流量都要通过kube-proxy

2、iptables 代理模式

特点：kube-proxy只负责通过netlink接口实现iptables规则的更替，转发由iptables完成

3、ipvs 代理模式

特点：kube-proxy只负责通过netlink接口实现ipvs规则，所有的流量是通过ipvs模块进行负载均衡

总结

 Service 在 K8s 中有以下四种类型

  1. ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP

  2、NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 <NodeIP>: NodePort 来访问该服务

3、LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到<NodeIP>: NodePort

集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kubedns 才支持

提醒：在发布作品前请把不用的内容删掉