关于k8s:Kubernetes你需要掌握的-Service-和-Ingress

37次阅读

共计 6138 个字符，预计需要花费 16 分钟才能阅读完成。

大家好，我是小菜，一个渴望在互联网行业做到蔡不菜的小菜。可柔可刚，点赞则柔，白嫖则刚！
死鬼~ 看完记得给我来个三连哦！

本文次要介绍 k8s 中的网络设置

如有须要，能够参考

如有帮忙，不忘 点赞 ❥

微信公众号已开启，小菜良记，没关注的同学们记得关注哦！

k8s 咱们曾经从 NameSpace、Pod、PodController到 Volumn 都介绍过了，置信看完的小伙伴们也会很有播种的~ 那么明天咱们持续来到 k8s 的课堂，这节咱们将要来说下 k8S 搭建完服务后如何拜访！

首先咱们要分明什么是Service 和 Ingress。简略来说，这两个组件都是用来做流量负载的。那么什么又是流量负载呢？当咱们在就集群外部曾经通过 pod 部署了咱们的应用服务，那么下一步要干啥？那就是让用户拜访到咱们的应用服务，这个才是最重要的，不然你部署完了，用户却拜访不了，那岂不是无用功~

一、Service

在 k8s 中，pod 是应用程序的载体，咱们能够通过 pod 的 IP 来拜访咱们的应用程序，然而咱们曾经分明了 pod 是具备生命周期的，一旦 pod 呈现问题，pod 控制器将会将 pod 销毁进行从新创立。那么这个时候 pod 的 Ip 就会发生变化，因而利用 pod IP 拜访应用程序的形式间接 pass了，那么为了解决这个问题，k8s 引入了 Service 的资源概念，通过这个资源，能够整合多个 pod，提供一个对立的入口地址，通过拜访 Service 的入口地址就能拜访到前面的 pod 服务！

Service 不是凭空出现的，不晓得你是否还记得 Node 节点上的要害组件 kube-proxy！关键点来了哦~ 咱们看个老图回顾一下：

这张图有看过之前的博文都不会生疏，是的！kube-proxy 在这外面起到了关键性的作用，每个 Node 节点上都运行着一个 kube-proxy 服务过程，当创立 Service 的时候会通过 api-server 向 etc 写入创立的 service 的信息，而 kube-proxy 会基于监听的机制发现这种 Service 的变动，而后 它会将最新的 Service 信息转换成对应的拜访规定

到这里，应该对 Service 有个大略的概念，起码晓得了它的用途，接下来咱们无妨更加深刻的理解一下~

1）工作模式

kube-proxy 反对 3 种工作模式，如下：

1. userSpace

这个模式比较稳定，然而效率比拟低！在 userSpace 模式下，kube-proxy 会为每一个 Service 创立一个监听端口，当有申请发往Cluster IP 的时候，会被 Iptables 规定重定向到 kube-proxy 监听的端口上，kube-proxy 会依据 LB 算法抉择一个 Pod 提供服务并建设起连贯。

这个模式下，kube-proxy 充当的角色是一个 四层负责均衡器，因为 kube-proxy 运行在 userSpace 模式下，在进行转发解决的时候会减少内核和用户空间之间的数据拷贝，因而效率比拟低。

2. iptables

在 iptables 模式下，kube-proxy 会为 Service 后端的每个 pod 都创立对应的 iptable 规定，间接将发往 Cluster IP 的申请重定向到一个 pod IP 上。该模式下 kube-proxy 不承当四层负载均衡器的角色，只负责创立 iptables 的规定。该模式的有点便是较 userspace 模式来说效率更高，然而不能提供灵便的 LB 策略。当后端 Pod 不可用的时候也无奈进行重试。

3. ipvs

这种模式与 iptables 模式形似，kube-proxy 会监控 pod 的变动并且创立相应的 ipvs 规定。然而 ipvs 规定绝对于 iptables 来说转发效率更高，而且反对更多的 LB 算法。

实际

下面理解到 3 种工作模式。咱们来简略试一下 ipvs 的作用。首先筹备一份资源清单：

这份清单上半局部是创立一个 Pod 控制器，下半局部是创立一个 Service。

而后咱们输出 ipvsadm -Ln命令即可看到 ipvs规定策略：

10.108.230.12 是 service 提供的拜访入口，当拜访这个入口的时候，能够发现前面有三个 pod 的服务在期待调用，kube-proxy 会基于 rr（轮询）的策略，将申请散发到其中一个 pod 下来，这个规定会同时在集群内的所有节点上都生成，所以在任何一个节点上拜访都能够！

此模式必须装置 ipvs 内核模块，否则会升高为 iptables

开启 ipvs：

  1. kubectl edit cm kube-proxy -n kube-system

编辑后保留（:wq）退出

  1. kubectl delete pod -l k8s-app=kube-proxy -n kube-system
  2. ipvsadm -Ln

2）Service 应用

下面曾经介绍完了 Service 的几种工作模式。上面咱们进入 Service 的应用阶段。咱们下面曾经做了简略的实际，创立了一个 Deploy，一个 Service，而后咱们能够通过 serviceIp + targetPort 或 nodeIp + nodePort拜访资源

然而在学习 Service 的应用，仅仅这个是不够的，Service 又分为 5 种类型，上面将一一介绍。

1. ClusterIP

咱们先看下 ClusterIP 类型的 Service 的资源清单：

通过创立后测试拜访 clusterIp + port

咱们再查看下 ipvs 规定，能够看到该 service 曾经能够转发到对应的 3 个 pod 上

接下来咱们能够通过 describe 指令查看该 service 有哪些信息：

扫了一遍发现 Endpoints 和 Session Affinity 都是咱们之间没有见过的。那这个又是个什么货色呢？

Endpoint

Endpoint 是 k8s 中的一个资源对象，存储在 etcd 中，用来记录一个 service 对应的所有 Pod 的拜访地址，它是依据 service 配置文件中 selector 形容产生的。一个 Service 由一组 Pod 组成，这些 Pod 通过 Endpoint 裸露进去，能够说 Endpoint 是理论实现服务的端口的汇合。艰深来说，Endpoint 是 service 和 pod 之间的桥梁

既然是一个资源，那么咱们就能够获取到

负载散发

咱们下面曾经胜利的实现了通过 Service 拜访到 Pod 资源，那么咱们再做一些批改，别离进入 3 个 pod 编辑 usr/share/nginx/index.html 文件：

# pod01
Pod01 :  ip - 10.244.1.73
# pod02
Pod01 :  ip - 10.244.1.73
# pod03
Pod03 :  ip - 10.244.2.63

而后咱们再次尝试通过 curl 10.96.10.10:80命令查看后果：

眼尖的你是否有发现，者中负载散发策略不就是 轮询 吗！对于 Service 的拜访，k8s 提供了两种负载散发策略：

  • 如果未定义散发策略，默认应用 kube-proxy 的策略，比方随机、轮询
  • 基于客户端地址的会话放弃模式，即来自同一个客户端发动的所有申请都会转发到固定的一个 pod 上。而这里就须要用到咱们下面提到的没有见过的货色 sessionAffinity

之前咱们用 ipvsadm -Ln 命令查看散发策略的时候，外面有个 rr 字段不晓得你有没有留神到，没错，这个 rr 值得就是轮询的意思

如果咱们想要开启会话放弃的散发策略，那么只须要在 spec 中增加 sessionAffinity:ClientIP 选项

再次通过 ipvsadm -Ln 命令查看散发策略就能够发现后果曾经发生变化了

咱们简略测试一下：

这样子就曾经实现了 会话放弃 的散发策略！

留神：ClusterIp 的 Service，不反对内部拜访，也就是说通过浏览器拜访是不失效的，只能在集群外部拜访

2. HeadLiness

很多服务都须要反对定制化，如果将产品定位为服务，那么这个产品毋庸是胜利。在某些场景中，开发人员并不想要应用 service 提供的负载平衡性能，而是心愿本人来管制负载平衡策略。针对这种状况的产生，k8s 也是很好的反对了，引入了 HeadLiness Service，这类 Service 不会调配 ClusterIp，如果想要拜访 service，只能通过 Service 域名进行查问。

咱们来看下 HeadLiness 的资源清单模板：

惟一跟 ClusterIp 不同的便是 clusterIP: None 属性的变动。

通过创立后能够发现，ClusterIP 并未调配，咱们持续查看 Service 的详情

通过详情咱们能够发现 Endpoints 曾经失效了，而后咱们任意进入到一个 pod 中，查看域名解析状况：

能够看到域名也曾经解析实现，默认域名为service 名称. 命名空间.svc.cluster.local

3. NodePort

下面的两个 service 类型，都是只能在集群外部能力拜访，然而咱们部署服务必定是想让用户通过集群内部能够应用的。那么这个时候就须要用到咱们结尾创立的 service 类型，那就是 NodePort service。

这种类型的 Service 的工作原理也不难，其实 就是将 service 的端口映射到 Node 的一个端口上 ，而后通过 NodeIp+NodePort 进行拜访

看了原理图是不是感觉恍然大悟啦。那么来看看是怎么通过资源清单创立的：

咱们通过以上资源清单创立 service，而后拜访：

能够看出通过两种形式都是能够拜访的，咱们也能够在浏览器试试看：

这后果也是如咱们所愿！

不要感觉到这里就曾经称心如意了哦，尽管说曾经能够胜利让用户拜访到了~ 咱们趁热打铁持续再理解剩下的两种类型~

4. LoadBalancer

LoadBalancer 听名字就晓得跟负载平衡无关。这个类型与 NodePort 很类似，目标都是向内部裸露一个端口，次要的区别在于 LoadBalancer 会在集群的内部再做一个负载均衡器，而这个设施是须要外部环境反对的，外部环境发送到这个设施的申请，会被设施负载之后转发到集群中。

图中有个 Vip 的概念，这里的 Vip 指的是 Vitual IP，也就是虚构 IP，内部用户通过拜访这个虚构 IP，能够负载到咱们不同的 service 上，达到负载平衡和高可用的特点

5. ExternalName

ExternalName 类型的 service 是用于引入集群内部的服务，它通过 externalName 属性指定内部一个服务的地址，而后在集群外部拜访此 service 就能够拜访到内部服务了。

资源清单：

创立后咱们能够查看域名解析，发现曾经解析胜利：

dig @10.96.0.10 svc-externalname.cbuc-test.svc.cluster.local

二、Ingress

1）工作模式

下面咱们曾经讲完了 Service 几种类型的用法，咱们曾经通晓了想让内部用户拜访到咱们 pod 中的服务有两种类型的 service 是反对的，别离是：NodePort和LoadBalancer，然而其实认真剖析一下，咱们不难发现这两种 service 的毛病:

  • NodePort：会占用集群机器的很多端口，当集群服务变多的时候，这个毛病就越发显著
  • LoadBalancer：每个 Service 都须要一个 LB，比拟麻烦和浪费资源，并且须要 k8s 之外的负载平衡设施反对

这种毛病当然不只是咱们可能发现，作为 k8s 的启动者早已意识到了，紧接着便推出了 Ingress 的概念。Ingress 仅须要一个 NodePort或 LB 就能够满足裸露多个 Service 的需要：

实际上，Ingress 就相当于一个 7 层的负载均衡器，是 K8s 对反向代理的一个形象，它的工作原理相似于 Nginx，能够了解成在 Ingress 里 建设诸多的隐射规定 ，而后 Ingress Controller 通过监听这些配置规定转化成 Nginx 的反向代理配置，而后对外提供该服务。这边波及到了两个重要的概念：

  • Ingress：K8s 中的一个资源对象，作用是定义申请如何转发到 service 的规定
  • Ingress Controller：具体实现反向代理及负载平衡的程序，对 Ingress 定义的规定进行解析，依据配置的规定来实现申请转发，有很多种实现形式，如 Nginx、Contor、Haproxy等

Ingress 控制器 有很多中能够实现申请转发的形式，咱们通常上也会抉择咱们比拟相熟的 Nginx 作为负载，接下来咱们就以 Nginx 为例，咱们先来理解一下其工作原理：

  1. 用户编写 Ingress Service规定，阐明每个域名对应 K8s 集群中的哪个Service
  2. Ingress 控制器会动静感知到 Ingress 服务规定的变动，而后生成一段对应的 Nginx 反向代理配置
  3. Ingress控制器会将生成的 Nginx 配置写入到一个运行中的 Nginx 服务中，并动静更新
  4. 而后客户端通过拜访域名，实际上 Nginx 会将申请转发到具体的 Pod 中，到此就实现了整个申请的过程

理解了工作原理，咱们就来落地实现~

2）Ingress 应用

1. 环境搭建

在应用 Ingress之前，咱们须要先搭建一个 Ingress 环境

步骤一：
# 拉取咱们须要的资源清单
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
步骤二：
# 创立资源
kubectl apply -f ./
步骤三：

查看资源是否创立胜利

到这里咱们就曾经筹备好了 Ingress 环境，接下来来到测试环节~

咱们筹备了两个Service，两个 Deployment，和创立了 6 个正本的Pod

如果到当初还筹备不出这些资源的小伙伴得回头做功课了哦~

大抵结构图如下：

那咱们当初就筹备一个 Ingress 来达到以下的后果

筹备 Ingress 的资源清单：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-htpp
  namespace: cbuc-test
spec:
  rules:
  - host: dev.cbuc.cn
    http: 
      paths:
      - path: /
        backend:
          serviceName: svc-nodeport-dev
          servicePort: 80
  - host: pro.cbuc.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: svc-nodeport-pro
          servicePort: 80

通过创立后咱们还须要在咱们电脑的本地 hosts 增加域名映射：

而后在网页上通过 域名 +nodePort 的形式就能够拜访到了

到这里咱们就实现了Ingress 的拜访形式！

END

到当初为止，咱们也曾经讲完了 K8s 的应用过程，从最根本的 nameSpace 到这节的网络配置，不晓得你学废了么~！k8s 曾经告一段落，咱们下个章节会

出写什么花色呢？那么记得关注点起来~

明天的你多致力一点，今天的你就能少说一句求人的话！

我是小菜，一个和你一起学习的男人。 💋

微信公众号已开启，小菜良记，没关注的同学们记得关注哦！

正文完
k8s
发表至： k8s
2021-06-07
 0
关于k8s:YurtTunnel-详解｜如何解决-K8s-在云边协同下的运维监控挑战
关于k8s:k8s常用指令
关于k8s:Jenkins-X-3x-alpha初见面
关于k8s:Kubernetes-部署-Nebula-图数据库集群