七层路由机制-Ingress

本文涉及的产品
.cn 域名,1个 12个月
简介: 七层路由机制-Ingress

这一篇写的比较混乱,勉强看。

Ingress概念:

通俗来讲:Ingress和之前说的Service、Deployment一样,也是一个k8s的资源类型;Ingress用于实现域名的方式访问k8s的内部应用,Service可能更适于服务间访问。

这东西我们使用的k8s官方维护的本版,另外nginx官方也有一个版本,怎么用看个人。

Ingress支持多种方案:包括 Nginx、Haproxy、Traefik、istio等;在实际中Ingress上面可能还有一层公司的硬件层代理。

大概的流程图如下:

创建一个Ingress:

这个ingress使用Hlem方式创建,以后会写一篇helm的使用,现在不用管原理。

下面的资源我会提供:

  • Ingress-nginx使用的两个容器镜像下载地址:
  • 镜像地址:registry.cn-hangzhou.aliyuncs.com
  • 镜像:yyangs/ingress-nginx-controller;yyangs/ingress-nginx-kube-webhook-certgen
  • chart包链接:ingress-nginx-4.0.17
  • 首先我们先创建一个Helm(因为要使用helm创建)
[root@k8s-master01 ~]# wget https://get.helm.sh/helm-v3.8.0-linux-amd64.tar.gz
[root@k8s-master01 ~]# tar xf helm-v3.8.0-linux-amd64.tar.gz
[root@k8s-master01 ~]# mv linux-amd64/helm /usr/local/bin/helm
  • 创建一个仓库 ,方便安装ingress:ingress的APP VERSION版本最好要大于0.35,查看其下可用的包
[root@k8s-master01 ~]# helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
"ingress-nginx" has been added to your repositories
[root@k8s-master01 ~]# helm repo list
NAME          URL                                       
ingress-nginx https://kubernetes.github.io/ingress-nginx
[root@k8s-master01 ~]# helm search repo ingress-nginx
NAME                        CHART VERSION APP VERSION DESCRIPTION                                       
ingress-nginx/ingress-nginx 4.0.17        1.1.1       Ingress controller for Kubernetes using NGINX a...
  • 下载ingress包,将包解压到一个创建的目录中方便修改配置
[root@k8s-master01 ~]# helm pull ingress-nginx/ingress-nginx
ingress-nginx-4.0.17.tgz
[root@k8s-master01 ~]# mkdir /temp
[root@k8s-master01 ~]# mv ingress-nginx-4.0.17.tgz /temp/
[root@k8s-master01 ~]# cd /temp/
[root@k8s-master01 temp]# tar xf ingress-nginx-4.0.17.tgz 
# 进到ingress-nginx目录
[root@k8s-master01 temp]# cd ingress-nginx/
  • 修改values.yaml,基本每一行都代表一个位置
# 源位置
controller:
  name: controller
  image:
    registry: registry.cn-hangzhou.aliyuncs.com
    image: yyangs/ingress-nginx-controller
    ## digest: sha256:0bc88eb15f9e7f84e8e56c14fa5735aaa488b840983f87bd79b1054190e660de
# dns策略
  dnsPolicy: ClusterFirstWithHostNet
# 使用宿主机端口号,性能好
  hostNetwork: true
# 资源类型选择DaemonSet,会在指定节点上部署
  kind: DaemonSet
# 在有标签的node上部署
  nodeSelector:
    kubernetes.io/os: linux
    ingress: "true"
# 类型,本地环境使用
    type: ClusterIP
# 最后位置的另一处源位置
    patch:
      enabled: true
      image:
        registry: registry.cn-hangzhou.aliyuncs.com
        image: yyangs/ingress-nginx-kube-webhook-certgen
        ## digest: sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660

对上面的修改做一些说明:

  • 镜像源:他默认源是国外的,我们访问不到。所以我替换成了我的阿里源,如果做这个实验的小伙伴可以用我的源;最后一处的源也一样;注意把校验注释
  • 使用hostNetwork: true创建,配合资源类型选择DaemonSet性能更好
  • dns策略:如果使用hostNetwork,策略需要改成dnsPolicy: ClusterFirstWithHostNet
  • 执行yaml文件创建
# 创建一个命名空间
[root@k8s-master01 ingress-nginx]# kubectl create ns ingress-nginx
namespace/ingress-nginx created
# 因为要在指定node上创建,所以给一台机器创建一个标签
[root@k8s-master01 ingress-nginx]# kubectl label nodes k8s-master03 ingress=true
node/k8s-master03 labeled
# 执行helm创建,那个名称自定义,之前出了一点问题,所以换个名字。
[root@k8s-master01 ~]# cd /temp/ingress-nginx/
您在 /var/spool/mail/root 中有新邮件
[root@k8s-master01 ingress-nginx]# helm install nginx-ingress -n ingress-nginx .
[root@k8s-master01 temp]# kubectl get pod -n ingress-nginx -o wide 
NAME                                           READY   STATUS    RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATES
nginx-ingress-ingress-nginx-controller-lrs9s   1/1     Running   0          22h   192.168.10.4   k8s-master03   <none>           <none>

可以看到这个Pod已经起来了,并且部署在master03节点上,也就是有ingress=ture标签的节点上,这样对ingress进行扩容或缩容的时候就会方便很多。

比如当你想扩容的时候只需要在想扩容的节点打上对应的标签,就会自动部署一个新的Pod,就像下面这条命令。

kubectl label node k8s-master02 ingress=true

当我不想要这个Pod的时候,缩容也会比较简单,去掉标签就可以了,可以看出标签的强大之处,减号等于删除标签的意思。

kubectl label node k8s-master02 ingress-

hostNetwork方式部署的ingress,会在宿主机启动一个进程,我们去部署Pod的节点看一下,

[root@k8s-master03 ~]# ss -tpln | grep 80
LISTEN     0      16384  192.168.10.4:2380                     *:*                   users:(("etcd",pid=1703,fd=7))
LISTEN     0      16384        *:80                       *:*                   users:(("nginx",pid=106434,fd=19),("nginx",pid=106427,fd=19))
LISTEN     0      16384        *:80                       *:*                   users:(("nginx",pid=106433,fd=11),("nginx",pid=106427,fd=11))
LISTEN     0      16384     [::]:80                    [::]:*                   users:(("nginx",pid=106433,fd=12),("nginx",pid=106427,fd=12))
LISTEN     0      16384     [::]:80                    [::]:*                   users:(("nginx",pid=106434,fd=20),("nginx",pid=106427,fd=20))
[root@k8s-master03 ~]# ps aux | grep nginx
root       2622  0.0  0.1   8852  5456 ?        Ss   01:12   0:00 nginx: master process nginx -g daemon off;
101        2759  0.0  0.0   9272  2456 ?        S    01:12   0:00 nginx: worker process
101        2760  0.0  0.0   9272  2456 ?        S    01:12   0:00 nginx: worker process
root      25605  0.0  0.0 112840  2292 pts/0    S+   15:19   0:00 grep --color=auto nginx
101      106347  0.0  0.0    208     4 ?        Ss   09:08   0:00 /usr/bin/dumb-init -- /nginx-ingress-controller --publish-service=ingress-nginx/nginx-ingress-ingress-nginx-controller --election-id=ingress-controller-leader --controller-class=k8s.io/ingress-nginx --ingress-class=nginx --configmap=ingress-nginx/nginx-ingress-ingress-nginx-controller --validating-webhook=:8443 --validating-webhook-certificate=/usr/local/certificates/cert --validating-webhook-key=/usr/local/certificates/key
101      106359  0.1  1.1 743048 44956 ?        Ssl  09:08   0:25 /nginx-ingress-controller --publish-service=ingress-nginx/nginx-ingress-ingress-nginx-controller --election-id=ingress-controller-leader --controller-class=k8s.io/ingress-nginx --ingress-class=nginx --configmap=ingress-nginx/nginx-ingress-ingress-nginx-controller --validating-webhook=:8443 --validating-webhook-certificate=/usr/local/certificates/cert --validating-webhook-key=/usr/local/certificates/key
101      106427  0.0  0.9 145100 36332 ?        S    09:08   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /etc/nginx/nginx.conf
101      106433  0.0  1.0 157128 40848 ?        Sl   09:08   0:06 nginx: worker process
101      106434  0.0  1.0 157128 41000 ?        Sl   09:08   0:07 nginx: worker process
101      106435  0.0  0.7 143072 29120 ?        S    09:08   0:00 nginx: cache manager process

运行之后,接下来尝试简单的使用:

传统架构中发布服务,需要配置修改nginx的配置文件;在k8s中ingress与其他资源类型一样,通过yaml去声明一个ingress的实例。

官方网址:ingress-controller官方文档详细内容可以看这。

使用官网上一个例子先认识一下ingress

vim ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
  name: example
spec:
  ingressClassName: nginx
  rules:  # 可以配置多个rules
  - host: foo.bar.com # 域名匹配
    http:
      paths:  # 相当于nginx的location配合,同一个host可以配置多个paths
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc # 代理的哪个svc
            port: 
              number: 80

这里说一下上面这个实例的一些说明:

从rules开始向下是定义前后端连接的规则:

  • host:代表基于域名访问,客户端通过这个域名访问后端资源
  • http.paths:相当于nginx的location中匹配规则
  • pathType:Prefix:路径类型,路径由“/”符号分隔为一个个元素,匹配规则为逐个元素进行前缀匹配,默认ImplementationSpecific,还有一种是Exact。
  • backend:定义后端
  • service下定义后端的地址,包括代理的svc和端口号
    ————————————————————————————————

这里我遇到一个问题:

[root@k8s-master01 ~]# kubectl create -f ingress.yaml 
Error from server (InternalError): error when creating "ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": failed to call webhook: Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s": service "ingress-nginx-controller-admission" not found

创建的时候报错:yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes. io"这个。

我查看了下网上说应该是删除之前创建的资源时没删干净。

[root@k8s-master01 ~]# kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io 
NAME                                    WEBHOOKS   AGE
ingress-nginx-admission                 1          3d

然后查看下果然有个ingress-nginx-admission,删除后在创建就成功了

[root@k8s-master01 ~]# kubectl delete -A validatingwebhookconfigurations.admissionregistration.k8s.io ingress-nginx-admission 
validatingwebhookconfiguration.admissionregistration.k8s.io "ingress-nginx-admission" deleted

————————————————————————————————

执行ingress.yaml文件,这次就创建成功了。

[root@k8s-master01 ~]# kubectl create -f ingress.yaml 
ingress.networking.k8s.io/exmple created
[root@k8s-master01 ~]# kubectl get ingress
NAME     CLASS    HOSTS         ADDRESS   PORTS   AGE
exmple   <none>   foo.bar.com             80      10m

ingress也是可以配置多域名的

就是增加一个host实例。

# 第一个域名
  - host: foo.bar.com 
    http:
      paths:  
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port: 
              number: 80
# 第二个域名
  - host: foo2.bar.com 
    http:
      paths:  
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-2
            port: 
              number: 80

然后更新yaml文件就好了

[root@k8s-master01 ~]# kubectl replace -f ingress.yaml


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
7月前
|
存储 域名解析 负载均衡
负载均衡是什么,负载均衡有什么作用
负载均衡是什么,负载均衡有什么作用
|
7月前
|
Kubernetes 负载均衡 应用服务中间件
深入理解 Kubernetes Ingress:路由流量、负载均衡和安全性配置
深入理解 Kubernetes Ingress:路由流量、负载均衡和安全性配置
1326 1
|
2月前
|
Kubernetes 负载均衡 网络协议
在K8S中,负载均衡器有何作用?
在K8S中,负载均衡器有何作用?
就是要你懂负载均衡--lvs和转发模式
> 本文希望阐述清楚LVS的各种转发模式,以及他们的工作流程和优缺点,同时从网络包的流转原理上解释清楚优缺点的来由,并结合阿里云的slb来说明优缺点。 如果对网络包是怎么流转的不太清楚,推荐先看这篇基础:[程序员的网络知识 -- 一个网络包的旅程](https://www.atatech.org/articles/80573) ,对后面理解LVS的各个转发模式非常有帮助。
12200 0
|
编解码 运维 负载均衡
envoy代理转发与L5 Cluster 负载均衡
envoy代理转发与L5 Cluster 负载均衡
169 0
envoy代理转发与L5 Cluster 负载均衡
|
7月前
|
负载均衡 算法
Envoy 负载均衡与限流设计
【2月更文挑战第29天】Envoy负载均衡策略包括优先级、恐慌阈值、区域感知和资源限制。它按优先级分配流量,使用恐慌阈值避免健康节点过载,实现区域内的首选服务选择,并通过资源管理限制上游集群的连接和请求数。此外,Envoy提供全局限流功能,在网络和HTTP层面对通信进行控制,确保服务器稳定性。
|
7月前
|
负载均衡 网络协议 应用服务中间件
SLB四层转发和七层转发
SLB四层转发和七层转发详细介绍
762 0
|
Kubernetes 网络协议 应用服务中间件
k8s七层代理Ingress-controller高并发优化
k8s七层代理Ingress-controller高并发优化
|
负载均衡 Kubernetes 安全
Istio Ambient Mesh 四层负载均衡实现剖析
前言k8s通过service将相同类型的工作负载组织成为一组集群,并提供了负载均衡的能力,可以将请求随机路由到集群中的端点。然而在Istio Ambient Mesh中,为了实现四层安全,Istio Ambient Mesh通过配置iptables规则,将流量拦截到ztunnel组件,以便实现4层流量的加密处理后再向对端ztunnel发出,最终对端ztunnel再将流量转发至目标工作负载,而这样一
458 1
|
Prometheus Kubernetes Cloud Native
一文带你了解 Istio 流量路由
当我们尝试在 Kubernetes 中使用 NodePort 或 LoadBalancer 类型的服务设施配置进行通信时,Istio 或许是一个非常流行、新兴的开源服务网格产品,其能够用于通信管理、可观察性、错误处理及安全性等。作为微服务架构体系的一部分,为了无需过多地使用重复的逻辑填充每个微服务代码,我们可以利用 Istio 服务网格在一个地方完成所有这些事情。
179 0

相关实验场景

更多