Kubernetes进阶之ingress-nginx

Kubernetes进阶之ingress-nginx

目录:
一 从外部访问应用最佳方式
二 配置管理
三 数据卷与数据持久卷
四 再谈有状态应用部署
五 K8S 安全机制

说在前面的话,选择nodeport的方式去暴露端口,那你需要得去判断暴露的端口有没有被占用,再创建新的应用会判断端口有没有被分配出去
nodeport本身是基于默认的iptables的代理模式做的网络转发,也就是SANT,DANT,基于四层的,做七层是做不了的,性能差一点,因为它需要防火墙的转发和过滤。

一、从外部访问应用最佳方式

  1. Pod与Ingress的关系
    ? 通过Service相关联
    ? 通过Ingress Controller实现Pod的负载均衡

    • 支持TCP/UDP 4层和HTTP 7层
  2. Ingress Controller
    controller类似装的k8s组件,时常的要去api去交互,时常去获取api的相关的信息,刷新自己的规则,类似与其他控制器
    ingress,k8s设计了一个比较全局性的负载均衡器,准确的来说Ingress它是k8s中的一个规则,实现这个规则就是使用的这个控制器,一般称为ingress控制器
    ingress控制器主要做的工作就是,它访问到这个控制器,它帮你转发的具体pod,也就是集群池,关联的哪些应用,哪些pod的IP,会帮你关联出来,暴露的端口80,443

    1.部署Ingress Controlle
    部署文档:https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md
  3. 创建Ingress规则,为你的应用暴露一个端口,暴露一个域名,让用户去访问这个ingress controller控制器就可以了
    3.控制器选择类型
    https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
    注意事项:
    ? 镜像地址修改成国内的: zhaocheng172/nginx-ingress-controller:0.20.0
    ? 使用宿主机网络:hostNetwork: true
    [[email protected] demo]# wget  https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml
    [[email protected] demo]# kubectl apply -f mandatory.yaml
    [[email protected] demo]# kubectl get pod -n ingress-nginx
    NAME                                        READY   STATUS    RESTARTS   AGE
    nginx-ingress-controller-5654f58c87-r5vcq   1/1     Running   0          46s

    分配给node2上面了,我们可以用netstat去查看我们监听的端口80/443

    [[email protected] demo]# kubectl get pod -n ingress-nginx -o wide
    NAME                                        READY   STATUS    RESTARTS   AGE     IP              NODE        NOMINATED NODE   READINESS GATES
    nginx-ingress-controller-5654f58c87-r5vcq   1/1     Running   0          3m51s   192.168.30.23   k8s-node2   <none>           <none>
    [[email protected] demo]# vim ingress.yaml
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
    name: example-ingress
    spec:
    rules:
    - host: www.dagouzi.com
    http:
      paths:
      - backend:
          serviceName: deployment-service
          servicePort: 80
    [[email protected] demo]# kubectl create -f ingress.yaml
    [[email protected] demo]# kubectl get ingress -o wide
    NAME              HOSTS             ADDRESS   PORTS   AGE
    example-ingress   www.dagouzi.com             80      49m

    测试访问,这里我是写到了我的hosts文件中,要是做域名解析的话也是解析我们ingress的IP

    这种类型呢,只能给我们ingress-nginx分配到一个节点上,如果我们的ingress-nginx挂了就肯定访问不到我们的应用服务了
    要是解决这个问题,我们就可以将副本进行扩容,使用DaemonSet的形式可以使我们的节点都能起一个pod,把副本删除,因为这里不需要副本
    ,需要把之前的资源删除才能修改

    [[email protected] demo]# kubectl delete -f mandatory.yaml
    [[email protected] demo]# kubectl get pod -n ingress-nginx -o wide
    NAME                             READY   STATUS    RESTARTS   AGE   IP              NODE        NOMINATED NODE   READINESS GATES
    nginx-ingress-controller-4s5ck   1/1     Running   0          38s   192.168.30.22   k8s-node1   <none>           <none>
    nginx-ingress-controller-85rlq   1/1     Running   0          38s   192.168.30.23   k8s-node2   <none>           <none>

    查看我们的监听端口,node1/node2,上面都有,不过这样的实例,比较适合小型的集群
    一般我们还可以在这样DaemonSet控制器前面再跑两个基于4层的负载均衡器
    User-->lb(vm-nginx/lvs/haproxy)--->node1/node2的IP,再使用算法,进行轮询,---->pod

    [[email protected] ~]# netstat -anpt |grep 80
    tcp        0      0 0.0.0.0:18080           0.0.0.0:*               LISTEN      63219/nginx: master
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      63219/nginx: master
    tcp        0      0 127.0.0.1:33680         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33700         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33696         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33690         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:18080         127.0.0.1:33580         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33670         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33660         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33676         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33666         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33686         127.0.0.1:18080         TIME_WAIT   -
    tcp        0      0 127.0.0.1:33656         127.0.0.1:18080         TIME_WAIT   -
    tcp6       0      0 :::18080                :::*                    LISTEN      63219/nginx: master
    tcp6       0      0 :::80                   :::*                    LISTEN      63219/nginx: master
    [[email protected] ~]# netstat -anpt |grep 443
    tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      63219/nginx: master
    tcp        0      0 192.168.30.22:34798     192.168.30.21:6443      ESTABLISHED 1992/kube-proxy
    tcp        0      0 192.168.30.22:44344     10.1.0.1:443            ESTABLISHED 6556/flanneld
    tcp        0      0 192.168.30.22:44872     192.168.30.21:6443      ESTABLISHED 1718/kubelet
    tcp        0      0 192.168.30.22:58774     10.1.0.1:443            ESTABLISHED 63193/nginx-ingress
    tcp6       0      0 :::443                  :::*                    LISTEN      63219/nginx: master

基于https形式进行访问

[[email protected] cert]# cat cfssl.sh
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfssl
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o /usr/local/bin/cfssl-certinfo
chmod +x /usr/local/bin/cfssl /usr/local/bin/cfssljson /usr/local/bin/cfssl-certinfo
[[email protected] cert]# sh cfssl.sh
[[email protected] cert]# ls
certs.sh  cfssl.sh
[[email protected] cert]# chmod +x certs.sh
[[email protected] cert]# sh certs.sh 

为我们的域名生成证书,一个key,一个pem

[[email protected] cert]# ls
blog.ctnrs.com.csr       blog.ctnrs.com-key.pem  ca-config.json  ca-csr.json  ca.pem    cfssl.sh
blog.ctnrs.com-csr.json  blog.ctnrs.com.pem      ca.csr          ca-key.pem   certs.sh

把我们的key放入到我们的k8s中,使用ingress的时候使用这个key

[[email protected] cert]# kubectl create secret tls blog-ctnrs-com --cert=blog.ctnrs.com.pem --key=blog.ctnrs.com-key.pem
[[email protected] cert]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
blog-ctnrs-com        kubernetes.io/tls                     2      3m1s
default-token-m6b7h   kubernetes.io/service-account-token   3      9d

[[email protected] demo]# vim ingress-https.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
    - blog.ctnrs.com
    secretName: blog-ctnrs-com
  rules:
    - host: blog.ctnrs.com
      http:
        paths:
        - path: /
          backend:
            serviceName: deployment-service
            servicePort: 80
[[email protected] demo]# kubectl create -f ingress-https.yaml
ingress.extensions/tls-example-ingress created
[[email protected] demo]# kubectl get ingress
NAME                  HOSTS             ADDRESS   PORTS     AGE
example-ingress       www.dagouzi.com             80        3h26m
tls-example-ingress   blog.ctnrs.com              80, 443   5s


这里提示不安全,因为我们是用自签的证书进行认证的,如果我们把买的证书替换了就可以正常去访问了

小结:
暴露外部访问的两种方式
User --> lb(外部的负载均衡+keepalived) -->ingress controller (node1/node2)---->pod
User --》 node(vip ingress controller+keepalived主备)-->pod
Ingress(http/https) --> service --->pod

原文地址:https://blog.51cto.com/14143894/2435578

时间: 2024-11-02 13:54:52

Kubernetes进阶之ingress-nginx的相关文章

Kubernetes进阶之secret及configmap配置管理

Kubernetes进阶之secret及configmap配置管理 目录: 一 从外部访问应用最佳方式 二 配置管理 三 数据卷与数据持久卷 四 再谈有状态应用部署 五 K8S 安全机制 二.配置管理Pod使用secret两种方式: ? 变量注入 (就是我们在写yaml的时候直接让它以变量的方式注入进去,注入pod中,去引用这个变量,去做相关的处理)? 挂载(直接从volume的形式挂载到我们指定的目录下)Configmap与Secret类似,区别在于ConfigMap保存的是不需要加密配置信息

Kubernetes进阶之PersistentVolume 静态供给实现NFS网络存储

Kubernetes进阶之PersistentVolume 静态供给实现NFS网络存储网络存储 NFS是一种很早的技术,单机的存储在服务器方面还是非常主流的,但nfs唯一的就是缺点比较大就是没有集群版,做集群化还是比较费劲的,文件系统做不了,这是一个很大的弊端,大规模的还是需要选择一些分布式的存储,nfs就是一个网络文件存储服务器,装完nfs之后,共享一个目录,其他的服务器就可以通过这个目录挂载到本地了,在本地写到这个目录的文件,就会同步到远程服务器上,实现一个共享存储的功能,一般都是做数据的共

K8s Ingress Nginx 支持 Socket.io

Ingress 及 Ingress Controller 简介 Ingress:是k8s 资源对象,用于对外暴露服务,该资源对象定义了不同主机名(域名)及 URL 和对应后端 Service(k8s Service)的绑定,根据不同的路径路由 http 和 https 流量. Ingress Contoller:是一个pod服务,封装了一个Web前端负载均衡器,同时在其基础上实现了动态感知Ingress 并根据Ingress的定义动态生成前端web负载均衡器的配置文件,比如Nginx Ingre

Kubernetes中的Ingress

Ingress是什么 Ingress :简单理解就是个规则定义:比如说某个域名对应某个 service,即当某个域名的请求进来时转发给某个 service;这个规则将与 Ingress Controller 结合,然后 Ingress Controller 将其动态写入到负载均衡器配置中,从而实现整体的服务发现和负载均衡 Ingress Controller 实质上可以理解为是个监视器,Ingress Controller 通过不断地跟 kubernetes API 打交道,实时的感知后端 se

kubernetes service 和 ingress

一 总述 1 service 作用 POD 中运行的容器存在动态.弹性的变化(容器的重启IP地址会变化),因此便产生了service,其资源为此类POD对象提供一个固定.统一的访问接口及负载均衡能力,并借助DNS系统的服务发现功能,解决客户端发现容器难得问题 service 和POD 对象的IP地址在集群内部可达,但集群外部用户无法接入服务,解决的思路有:1 在POD上做端口暴露(hostPort)2 在工作节点上公用网络名称空间(hostNetwork)3 使用service 的NodePor

Kubernetes进阶之基于RBAC授权安全框架

K8S 安全机制 Kubernetes的安全框架 传输安全,认证,授权,准入控制 使用RBAC授权,我们作为一个用户如何去授权不同的同事去访问集群的权限,比如开发同事,可以访问哪个资源,哪个命名空间,测试同事可以访问哪些,通过这方面我们怎么去限制. 一.K8S的安全框架 ? 访问K8S集群的资源需要过三关:认证.鉴权.准入控制 ? 普通用户若要安全访问集群API Server,往往需要证书.Token或者用户名+密码:Pod访问,比如ingress控制器Ui的Dashboard都需要Servic

kubernetes进阶(01)pod

前言 本文是读书笔记,具体可参考 倪朋飞 先生的原文<kubernetes指南>,多谢原作者,致敬! Pod Pod是在K8s集群中运行部署应用或服务的最小单元,支持多个容器在一个Pod中共享网络地址和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务. 比如: 运行一个操作系统发行版的软件仓库:使用一个Nginx容器用来发布软件,另一个容器专门用来从源仓库做同步,这两个容器的镜像不太可能是一个团队开发的,但是他们一块儿工作才能提供一个微服务: 这种情况下,不同的团队各自开发

Kubernetes进阶之hostpath及emptyDir数据卷

K8s进阶之数据卷与数据持久卷目录: 一 从外部访问应用最佳方式 二 配置管理 三 数据卷与数据持久卷 四 再谈有状态应用部署 五 K8S 安全机制 三.数据卷与数据持久卷数据卷产生的背景为什么有数据卷,这里的数据卷和docker的数据卷还不太一样,实现的机制不是一套,数据卷说白了就是能帮助你持久化你pod重要的数据,如果你不持久化的话,pod删除里面临时产生的数据也会被删除,这不管是k8s中还是docker中,这都是一样的,所以k8s和docker都提供了这种volume的这种相关功能,就是为

Kubernetes进阶之StatefulSet有状态部署

K8s有状态应用部署目录:分为两类1.Headless Service2.StatefulSet ? 部署有状态应用 ? 解决Pod独立生命周期,保持Pod启动顺序和唯一性 稳定,唯一的网络标识符,持久存储 有序,优雅的部署和扩展.删除和终止 有序,滚动更新 应用场景:数据库 说在前面的话,像我们的Mysql或者Redis了,Zookerper等等这些适不适合部署在K8s中,其实呢不是太适合,但部署在里面也可以,比如部署一个Mysql来讲吧,部署到k8s中还是很容易的就一个Mysql实例,就像部