Ingress七层路由机制实现域名的方式访问k8s

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七层路由机制实现域名的方式访问k8s的详细内容,更多关于Ingress七层路由机制域名访问k8s的资料请关注我们其它相关文章!

(0)

相关推荐

  • k8s部署ingress-nginx的方法步骤

    目录 前言 一.部署配置Ingress 二.使用https 前言 k8s集群服务部署好之后,需要对外提域名访问,这时候就需要ingress-nginx了,今天来给大家分享一下 一.部署配置Ingress 1.获取配置文件 #文件已下载到本地 https://github.com/kubernetes/ingress-nginx/tree/nginx-0.20.0/deploy 2.准备镜像 unzip ingress-nginx-nginx-0.20.0.zip cd ingress-nginx

  • 一篇文章搞懂K8S高级特性

    目录 K8S高级特性 高级特性 总结 kubectl排查服务问题 K8S真的放弃Docker了吗? K8S高级特性 K8S中还有一些高级特性有必要了解下,比如弹性扩缩应用(见上文).滚动更新(见上文).配置管理.存储卷.网关路由等. 在了解这些高级特性之前有必要先看几个K8S的核心概念: ReplicaSet ReplicaSet确保任何时间都有指定数量的Pod副本在运行.通常用来保证给定数量的.完全相同的Pod的可用性.建议使用Deployment来管理ReplicaSet,而不是直接使用.

  • Kubernetes(k8s)基础介绍

    之前我一直想学习Kubernetes,因为它听起来很有意思(如果你是希腊人,你会觉得这个名字很有问题),但我从来没有机会,因为我没有任何东西需要运行在集群中.而最近,我的工作中开始逐步涉及Kubernetes相关的事情,所以这次我抓住机会,开始查资料,但后来我发现目前所有的资料(包括官方教程)都过于冗长,结构也不合理,这让我一开始有点沮丧. 经过几天的研究,我开始逐步理解Kubernetes的核心理念,并且把他部署到了生产环境中.因为我的简历现在说自己是个"Kubernetes专家",

  • Ingress七层路由机制实现域名的方式访问k8s

    Ingress概念: 通俗来讲:Ingress和之前说的Service.Deployment一样,也是一个k8s的资源类型:Ingress用于实现域名的方式访问k8s的内部应用,Service可能更适于服务间访问. 这东西我们使用的k8s官方维护的本版,另外nginx官方也有一个版本,怎么用看个人. Ingress支持多种方案:包括 Nginx.Haproxy.Traefik.istio等:在实际中Ingress上面可能还有一层公司的硬件层代理. 大概的流程图如下: 创建一个Ingress: 这

  • 基于域名的方式访问Istio服务网格中的多个应用程序的方法详解

    目录 1.为什么要使用域名访问部署在Istio中的程序 2.通过域名的方式访问Istio网格中的应用程序 2.1.配置Gateway和VirtualService资源 2.1.1.修改httpbin程序的Gateway和VirtualService资源 2.1.2.修改bookinfo程序的Gateway和VirtualService资源 2.1.3.修改nginx程序的Gateway和VirtualService资源 2.2.配置LB代理Istio的IngressGateway 3.基于域名来

  • linux负载均衡总结性说明 四层负载和七层负载有什么区别

    在常规运维工作中,经常会运用到负载均衡服务.负载均衡分为四层负载和七层负载,那么这两者之间有什么不同? 废话不多说,详解如下: 一.什么是负载均衡 1)负载均衡(Load Balance)建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽.增加吞吐量.加强网络数据处理能力.提高网络的灵活性和可用性.负载均衡有两方面的含义:首先,大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间:其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点

  • 网络防火墙功夫深入到第七层

    编者按在短短的几年里,防火墙的功能重心从网络层发展到了应用层.本文阐述了这种变迁的技术背景,以及未来的防火墙技术走向. 应用层攻击挑战传统防火墙 最近两年来,攻击者的兴趣明显从端口扫描和制造拒绝服务攻击(DoS Attack)转向了针对Web.E-mail甚至数据库等主流应用的攻击.传统的防火墙仅仅检查IP数据包的包头,而忽略了内容--如果用信件来做比喻,也就是只检查了信封而没有检查信纸.因此对这类应用层的攻击无能为力.可以说,仅仅靠第三层和第四层的IP地址和协议端口过滤的防火墙产品早已走到了尽

  • windows第七层负载均衡_基于IIS的ARR负载均衡详解

    载均衡有很多种方法,有硬件负载均衡,软件负载均衡,还可以从域名解析下手. 不过,今天只讲软件负载均衡. 软件负载均衡一般分两种,从网络协议来讲(tcp/ip),主要集中在第四层和第七层进行负载均衡. 第四层就是基于IP进行负载均衡.后面还有一篇文章讲这个. 第七层就是应用层.比如各种的WEB服务器.今天就讲讲IIS的负载均衡. 第七层的Web负载均衡,很多web服务器都支持,比如IIS,Nginx,apache等.现在主要讲一下windosw下IIS如何使用负载均衡 IIS使用ARR反向代理,实

  • nginx七层负载均衡配置详解

    目录 一.负载均衡介绍 二.nginx下载安装 1.下载nginx源码包 2.安装并启用 三.nginx七层负载均衡配置 real server设置: 客户端设置: 四.nginx扩充调度算法(sticky) 1.下载扩展包 2.编译前做一些优化: 3.重新编译 一.负载均衡介绍 1)四层负载均衡 所谓四层就是基于IP+端口的负载均衡 四层负载均衡,是指OSI七层模型中的传输层,传输层已经支持TCP/IP的控制,所以只需要对客户端的请求进行TCP/IP协议的包转发就可以实现负载. 2)七层负载均

  • 详解通过 OSI 七层模型打开计算机网络大门

    目录 正文 分层的体系结构 协议的分层 OSI参考模型 应用层 表示层 会话层 传输层 网络层 链路层 物理层 正文 最近为了准备面试,又再看了一遍 图解TCP/IP,发现很多知识点看了就忘,并没有形成一个系统知识,那么今天开始通过一系列的文章来系统总结一下计算机网络,在接下来的文章中会对重要的那几个模型进行讲解. 分层的体系结构 在开始组织关于因特网体系结构的想法之前,我们先看看一个人类社会与之类比的例子,实际上,在日常生活中我们一直都与复杂系统打交道. 想象一下有人请你描述比如航班系统的情况

  • AngularJS入门教程之路由机制ngRoute实例分析

    本文实例讲述了AngularJS路由机制ngRoute.分享给大家供大家参考,具体如下: 引言 在我们介绍路由之前我们首先谈一下SPA,所以SPA就是我们现在经常说的单页应用single page APP,为了实现无刷新的视图切换我们之前的做法就是利用AJAX从后取出数据然后渲染在前台页面HTML中,但是AJAX有一个致命的缺点就是不能实现浏览器的后退按钮失效,为了解决这个问题我们通常使用hash,监听hashchange事件来进行视图切换,另一个方法是用HTML5的history API,通过

  • Zend Framework框架路由机制代码分析

    本文分析了Zend Framework框架路由机制代码.分享给大家供大家参考,具体如下: 在框架中,有关路由的调用关系为: 1.apache的mod_rewrite模块把请求路由到框架的启动脚本,一般是index.php: 2.前端控制器Zend_Controller_Front通过dispatch函数进行请求分发: 3.路由器Zend_Controller_Router_Rewrite通过route函数处理路由,对路由器中已有的路由规则,按照加入顺序的逆序(类似于栈,后进先出)对每个route

  • ThinkPHP路由机制简介

    本文实例讲述了ThinkPHP路由机制.分享给大家供大家参考,具体如下: ThinkPHP 支持 URL 路由功能,要启用路由功能,需要设置ROUTER_ON参数为true.开启路由功能后,系统会自动进行路由检测,如果在路由定义里面找到和当前URL匹配的路由名称,就会进行路由解析和重定向.路由功能需要定义路由定义文件,位于项目的配置目录下面,文件名为 routes.php 定义格式: Return Array( 'RouteName'=>array('模块名称','操作名称','参数定义','额

随机推荐