Kubernetes | Service - Ingress | ZkeqのCoding日志

Kubernetes | Service 的概念

SVC 负责监测他所匹配的 Pod 的信息, 并且把他加入到 SVC 的 Endpoints 中, 从而实现负载均衡的功能,
如何后期有变化的话, SVC 会进行信息同步, Nginx 指向这个 SVC, 会将请求转发至正常工作的 Pod, 不需要我们在 Nginx 做任何的修改. 这就是 SVC 的机制.
引入 SVC 之后, 如果服务有 扩容、伸缩 等操作都不会对上一层的服务造成影响.
SVC 也叫做服务发现.

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

多标签没问题只要不少标签就可以了

Service 能够提供负载均衡的能力，但是在使用上有以下限制：

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

Service 的类型

Service 在 K8s 中有以下四种类型：

ClusterIP：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP。
NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 <NodeIP>:NodePort 来访问该服务。
LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到 <NodeIP>:NodePort。
ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

VIP 和 Service 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。在 Kubernetes v1.0 版本，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。从 Kubernetes v1.2 起，默认就是 iptables 代理。在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理。在 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 服务器可能会缓存 Service 的 IP 地址，这样会导致 Service 的负载均衡失效。

代理模式的分类

Ⅰ、userspace 代理模式

Ⅱ、iptables 代理模式

Ⅲ、ipvs 代理模式

这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints，调用 netlink 接口以相应地创建 ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

rr：轮询调度
lc：最小连接数
dh：目标哈希
sh：源哈希
sed：最短期望延迟
nq：不排队调度

注意: ipvs 模式假定在运行 kube-proxy 之前在节点上都已经安装了 IPVS 内核模块. 当 kube-proxy 以 ipvs 代理模式启动时, kube-proxy 将验证节点上是否安装了 IPVS 模块, 如果未安装, 则 kube-proxy 将回退到 iptables 模式.

ipvs 模式现在已经成为了一个标准.

ClusterIP

集群内部访问的 IP

clusterIP 主要在每个 node 节点使用 iptables / ipvs，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。

为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令，apiserver 接收到请求后将数据存储到 etcd 中。
kube-proxy：Kubernetes 的每个节点中都有一个叫做 kube-proxy 的进程，这个进程负责感知 service、pod 的变化，并将变化的信息写入本地的 iptables / ipvs 规则中。
iptables / ipvs：使用 NAT 等技术将 virtualIP 的流量转至 endpoint 中。

创建 myapp-deploy.yaml 文件

创建 Service 信息

Headless Service

有时不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP) 的值为 “None” 来创建 Headless Service。这类 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。

举个例子，假设您有一个 StatefulSet，需要每个 Pod 的 IP 地址，您可以使用 Headless Service 以便查询每个 Pod 的 DNS 记录，而无需使用 Service 的负载均衡功能。

另一个例子是，如果您使用外部负载均衡器，您可能希望将请求直接路由到每个 Pod 的 IP，而不是通过 Service 的 Cluster IP。这时你可以使用 Headless Service，而不需要为每个 Pod 配置单独的负载均衡规则。

要查询 Headless Service 中每个 Pod 的 DNS 记录，可以使用以下命令：

例如，在上述示例中，要查询 myapp-headless 服务中的每个 Pod 的 DNS 记录，可以使用以下命令：

NodePort

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

LoadBalancer

loadBalancer 和 nodePort 其实是同一种方式。区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用 cloud provider 去创建 LB 来向节点导流。

ExternalName

这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如：hub.atguigu.com）。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

当查询主机 my-service.defalut.svc.cluster.local（SVC_NAME.NAMESPACE.svc.cluster.local）时，集群的 DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。

若无法正常加载, 请点击查看 PDF 网页版本: Kubernetes Service.pdf

Kubernetes | Ingress 资料信息

Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx

Ingress-Nginx 官方网站：https://kubernetes.github.io/ingress-nginx/

部署 Ingress-Nginx

Ingress HTTP 代理访问

deployment、Service、Ingress Yaml 文件

Ingress HTTPS 代理访问

创建证书，以及 cert 存储方式