Kubernetes(十一)Kubernetes ingress的实现原理

已于 2022-05-07 21:54:28 修改
阅读量3.9k 收藏 4
点赞数 2
分类专栏： kubernetes 文章标签： kubernetes
于 2022-04-01 23:16:31 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liu_weiliang10405/article/details/123910339
版权

#博学谷IT学习技术支持#

一、Ingress概念

Kubernetes关于服务的暴露主要是通过NodePort方式，通过绑定宿主机的某个端口,然后进行pod的请求转发和负载均衡，但这种方式下缺陷是：

Service可能有很多个，如果每个都绑定一个node主机端口的话，主机需要开放外围一堆的端口进行服务调用，管理混乱无法应用很多公司要求的防火墙规则。

理想的方式是通过一个外部的负载均衡器，绑定固定的端口，比如80,然后根据域名或者服务名向后面的Service ip转发，Nginx很好的解决了这个需求，但问题是如果有新的服务加入，如何去修改Nginx的配置，并且加载这些配置？ Kubernetes给出的方案就是Ingress，Ingress包含了两大主件Ingress Controller和Ingress。

  • Ingress解决的是新的服务加入后，域名和服务的对应问题，基本上是一个ingress的对象，通过yaml进行创建和更新进行加载。

  • Ingress Controller是将Ingress这种变化生成一段Nginx的配置，然后将这个配置通过Kubernetes API写到Nginx的Pod中，然后reload.（注意：写入 nginx.conf 的不是service的地址，而是service backend 的 pod 的地址，避免在 service 在增加一层负载均衡转发）

从上图中可以很清晰的看到，实际上请求进来还是被负载均衡器拦截，比如 nginx，然后 Ingress Controller 通过跟 Ingress 交互得知某个域名对应哪个 service，再通过跟 kubernetes API 交互得知 service 地址等信息；综合以后生成配置文件实时写入负载均衡器，然后负载均衡器 reload 该规则便可实现服务发现，即动态映射

了解了以上内容以后，这也就很好的说明了我为什么喜欢把负载均衡器部署为 Daemon Set；因为无论如何请求首先是被负载均衡器拦截的，所以在每个 node 上都部署一下，同时 hostport 方式监听 80 端口；那么就解决了其他方式部署不确定 负载均衡器在哪的问题，同时访问每个 node 的 80 都能正确解析请求；如果前端再 放个 nginx 就又实现了一层负载均衡。

Ingress使用

二、部署配置Ingress

！！！以下部署方法已经过时，新版本已经更新至0.9-beta1，不需要部署default-backend，具体部署文档参考：https://kubernetes.github.io/ingress-nginx/deploy/

2.1 部署文件介绍、准备

第一步： 获取配置文件位置

https://github.com/kubernetes/ingress-nginx/tree/nginx-0.20.0/deploy

第二步： 下载部署文件

提供了两种方式 ：

  • 默认下载最新的yaml
  • 指定版本号下载对应的yaml

  1. 默认下载最新的yaml

    wget  https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml

  1. 指定版本号下载对应的yaml
    如下载ingress-nginx 0.17.0对应的yaml

    wget  https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.17.0/deploy/mandatory.yaml

部署文件介绍

  1. namespace.yaml
    创建一个独立的命名空间 ingress-nginx
  2. configmap.yaml
    ConfigMap是存储通用的配置变量的，类似于配置文件，使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，并且支持K8S集群中所有通用的操作调用方式。
    从数据角度来看，ConfigMap的类型只是键值组，用于存储被Pod或者其他资源对象（如RC）访问的信息。这与secret的设计理念有异曲同工之妙，主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。
    ConfigMap可以保存环境变量的属性，也可以保存配置文件。
    创建pod时，对configmap进行绑定，pod内的应用可以直接引用ConfigMap的配置。相当于configmap为应用/运行环境封装配置。

pod使用ConfigMap，通常用于：设置环境变量的值、设置命令行参数、创建配置文件。

  1. default-backend.yaml
    如果外界访问的域名不存在的话，则默认转发到default-http-backend这个Service，其会直接返回404：

  2. rbac.yaml
    负责Ingress的RBAC授权的控制，其创建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding

  3. with-rbac.yaml
    是Ingress的核心，用于创建ingress-controller。前面提到过，ingress-controller的作用是将新加入的Ingress进行转化为Nginx的配置

这里，我们先对一些重要的文件进行简单介绍。

default-backend.yaml

default-backend的作用是，如果外界访问的域名不存在的话，则默认转发到default-http-backend这个Service，其会直接返回404：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app: default-http-backend
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: default-http-backend
  template:
    metadata:
      labels:
        app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissible as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: gcr.io/google_containers/defaultbackend:1.4
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi
---

apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: ingress-nginx
  labels:
    app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: default-http-backend

rbac.yaml

rbac.yaml负责Ingress的RBAC授权的控制，其创建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding。在上文《Kubernetes(一) 跟着官方文档从零搭建K8S》 中，我们已对这些概念进行了简单介绍。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
        - events
    verbs:
        - create
        - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

with-rbac.yaml

with-rbac.yaml是Ingress的核心，用于创建ingress-controller。前面提到过，ingress-controller的作用是将新加入的Ingress进行转化为Nginx的配置。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx 
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ingress-nginx
  template:
    metadata:
      labels:
        app: ingress-nginx
      annotations:
        prometheus.io/port: '10254'
        prometheus.io/scrape: 'true'
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.14.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --annotations-prefix=nginx.ingress.kubernetes.io
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
          - name: http
            containerPort: 80
          - name: https
            containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          securityContext:
            runAsNonRoot: false

如上，可以看到nginx-ingress-controller启动时传入了参数，分别为前面创建的default-backend-service以及configmap。

2.2 部署ingress

第一步： 准备镜像，从这里mandatory.yaml查看需要哪些镜像

已经准备好， 可以直接点击下载

镜像名称版本下载地址
k8s.gcr.io/defaultbackend-amd641.5registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64
quay.io/kubernetes-ingress-controller/nginx-ingress-controller0.20.0registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/nginx-ingress-controller

如：
docker pull registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/nginx-ingress-controller:0.20.0
将镜像上传到自己的私有仓库，以供下面的步骤使用（或者给镜像打tag）。

第二步： 更新mandatory.yaml中的镜像地址

替换成自己的镜像地址（或者给镜像打tag）：

  1. 替换defaultbackend-amd64镜像地址（或者给镜像打tag）

    sed -i 's#k8s.gcr.io/defaultbackend-amd64#registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64#g' mandatory.yaml

  2. 替换nginx-ingress-controller镜像地址（或者给镜像打tag）

    sed -i 's#quay.io/kubernetes-ingress-controller/nginx-ingress-controller#registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/nginx-ingress-controller#g' mandatory.yaml

第三步： 部署nginx-ingress-controller

kubectl apply -f mandatory.yaml

第四步： 查看ingress-nginx组件状态？

  1. 查看相关pod状态

    kubectl get pods -n ingress-nginx -o wide



    [root@master ingress-nginx]# kubectl get pods -n ingress-nginx -owide
NAME                                       READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE
default-http-backend-7f594549df-nzthj      1/1     Running   0          3m59s   192.168.1.90    slave1   <none>
nginx-ingress-controller-9fc7f4c5f-dr722   1/1     Running   0          3m59s   192.168.2.110   slave2   <none>
[root@master ingress-nginx]#

  2. 查看service状态

    [root@master ingress-nginx]# kubectl get service -n ingress-nginx
NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
default-http-backend   ClusterIP   10.104.146.218   <none>        80/TCP    5m37s
[root@master ingress-nginx]#

测试default-http-backend 是否起作用？

系统自动安装了一个default-http-backend pod， 这是一个缺省的http后端服务， 用于返回404结果，如下所示：

三、创建自定义Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kibana-ingress
  namespace: default

spec:
  rules:
  - host: myk8s.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kibana
          servicePort: 5601

其中：

  • rules中的host必须为域名，不能为IP，表示Ingress-controller的Pod所在主机域名，也就是Ingress-controller的IP对应的域名。
  • paths中的path则表示映射的路径。如映射/表示若访问myk8s.com，则会将请求转发至Kibana的service，端口为5601。

创建成功后，查看：

[root@k8s-node1 ingress]# kubectl get ingress -o wide
NAME             HOSTS       ADDRESS   PORTS     AGE
kibana-ingress   myk8s.com             80        6s

我们再执行kubectl exec nginx-ingress-controller-5b79cbb5c6-2zr7f -it cat /etc/nginx/nginx.conf -n ingress-nginx，可以看到生成nginx配置，篇幅较长，各位自行筛选：

    ## start server myk8s.com
    server {
        server_name myk8s.com ;

        listen 80;

        listen [::]:80;

        set $proxy_upstream_name "-";

        location /kibana {

            log_by_lua_block {

            }

            port_in_redirect off;

            set $proxy_upstream_name "";

            set $namespace      "kube-system";
            set $ingress_name   "dashboard-ingress";
            set $service_name   "kibana";

            client_max_body_size                    "1m";

            proxy_set_header Host                   $best_http_host;

            # Pass the extracted client certificate to the backend

            # Allow websocket connections
            proxy_set_header                        Upgrade           $http_upgrade;

            proxy_set_header                        Connection        $connection_upgrade;

            proxy_set_header X-Real-IP              $the_real_ip;

            proxy_set_header X-Forwarded-For        $the_real_ip;

            proxy_set_header X-Forwarded-Host       $best_http_host;
            proxy_set_header X-Forwarded-Port       $pass_port;
            proxy_set_header X-Forwarded-Proto      $pass_access_scheme;

            proxy_set_header X-Original-URI         $request_uri;

            proxy_set_header X-Scheme               $pass_access_scheme;

            # Pass the original X-Forwarded-For
            proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;

            # mitigate HTTPoxy Vulnerability
            # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
            proxy_set_header Proxy                  "";

            # Custom headers to proxied server

            proxy_connect_timeout                   5s;
            proxy_send_timeout                      60s;
            proxy_read_timeout                      60s;

            proxy_buffering                         "off";
            proxy_buffer_size                       "4k";
            proxy_buffers                           4 "4k";
            proxy_request_buffering                 "on";

            proxy_http_version                      1.1;

            proxy_cookie_domain                     off;
            proxy_cookie_path                       off;

            # In case of errors try the next upstream server before returning an error
            proxy_next_upstream                     error timeout invalid_header http_502 http_503 http_504;
            proxy_next_upstream_tries               0;

            # No endpoints available for the request
            return 503;

        }

        location / {

            log_by_lua_block {

            }

            port_in_redirect off;

            set $proxy_upstream_name "";

            set $namespace      "default";
            set $ingress_name   "kibana-ingress";
            set $service_name   "kibana";

            client_max_body_size                    "1m";

            proxy_set_header Host                   $best_http_host;

            # Pass the extracted client certificate to the backend

            # Allow websocket connections
            proxy_set_header                        Upgrade           $http_upgrade;

            proxy_set_header                        Connection        $connection_upgrade;

            proxy_set_header X-Real-IP              $the_real_ip;

            proxy_set_header X-Forwarded-For        $the_real_ip;

            proxy_set_header X-Forwarded-Host       $best_http_host;
            proxy_set_header X-Forwarded-Port       $pass_port;
            proxy_set_header X-Forwarded-Proto      $pass_access_scheme;

            proxy_set_header X-Original-URI         $request_uri;

            proxy_set_header X-Scheme               $pass_access_scheme;

            # Pass the original X-Forwarded-For
            proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;

            # mitigate HTTPoxy Vulnerability
            # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
            proxy_set_header Proxy                  "";

            # Custom headers to proxied server

            proxy_connect_timeout                   5s;
            proxy_send_timeout                      60s;
            proxy_read_timeout                      60s;

            proxy_buffering                         "off";
            proxy_buffer_size                       "4k";
            proxy_buffers                           4 "4k";
            proxy_request_buffering                 "on";

            proxy_http_version                      1.1;

            proxy_cookie_domain                     off;
            proxy_cookie_path                       off;

            # In case of errors try the next upstream server before returning an error
            proxy_next_upstream                     error timeout invalid_header http_502 http_503 http_504;
            proxy_next_upstream_tries               0;

            # No endpoints available for the request
            return 503;

        }

    }
    ## end server myk8s.com

设置host

首先，我们需要在Ingress-controller的Pod所在主机上（这里为k8s-node1），将上面提到的域名myk8s.com追加入/etc/hosts文件：

192.168.56.101 myk8s.com

除此之外，如果想在自己的Windows物理机上使用浏览器访问kibana，也需要在C:\Windows\System32\drivers\etc\hosts文件内加入上述内容。设置后，分别在k8s-node1和物理机上测试无误即可：

liu_weiliang10405
关注
  • 2
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Ingress实现
zhaoyangjian724的专栏
03-20 152
k8s ingress原理
weixin_40548182的博客
04-28 588
转发自 https://blog.csdn.net/weixin_46837396/article/details/119896694 Ingress（以Nginx为例）的工作原理如下： 用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置 Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新 到此为止，其实真正在工作的就是一个Ng
k8s ingress实现方案
leechm的博客
08-29 2182
前言： 对于我们传统的SVC来说，它只支持四层反向代理，但是如果遇到七层的话，就无法去实现，如下： 假如说，我们有如上的一个集群，我们现在想要对整个集群，或者是Apache进行https的加密访问，也就是我们的客户端想要跟我们的Apache进行HTTPS访问，我们完全不需要在每一台Apache上配置我们的HTTPS，我们只需要在NGINX上开启HTTPS认证即可。。。。当我们的客户访问到NGINX的时候，由于NGINX和客户端之间是加密访问，NGINX因为本地没有数据，它会向后端进行反向代理，反向代理
Kubernetes（k8s）Ingress原理
匠人精神，持之以恒！
10-07 1828
文章目录一、概述1）LoadBlancer Service2）NodePort Service3）Ingress二、Ingress-nginx介绍1）Ingress-nginx组成2）Ingress-nginx工作原理 一、概述 Kubernetes 暴露服务的有三种方式，分别为 LoadBlancer Service、NodePort Service、Ingress。官网对 Ingress 的定义为管理对外服务到集群内服务之间规则的集合，通俗点讲就是它定义规则来允许进入集群的请求被转发到集群中对应服务上
kubernetes 服务发现 ingress
03-11
kubernetes 服务发现 ingress文件
Kubernetes ingress yaml文件包
最新发布
09-21
Kubernetes ingress yaml文件包
Kubernetes 1.19.4安装Nginx-Ingress-Controller
12-17
Kubernetes 1.19.4安装Nginx-Ingress-Controller全套资源 包含以下内容： deploy.yml jettech-kube-webhook-certgen-v1.5.0.tar k8s.gcr.io-ingress-nginx-controller-v0.41.2.tar nginx-1.19.5.tar
021 Kubernetes ingress及Ingress Controller.mp4
05-07
021 Kubernetes ingress及Ingress Controller.mp4
Kubernetes圣经 THE KUBERNETES BIBLE 2023
04-17
全书680页主要详细讲述了使用多容器Pods和设计模式、使用ConfgMaps和...Kubernetes服务的Microsoft Azure上的Kubernete集群、使用Helm图表、身份验证和授权、调度Pod的高级技术、自动缩放Pods和节点、Ingress高级...
详解k8s组件Ingress边缘路由器并落地到微服务-kubernetes
02-25
Ingress英文翻译进入;进入权;进食，更准确的讲就是入口，即外部流量进入k8s集群必经之口。这到大门到底有什么作用？我们如何使用Ingress？k8s又是如何进行服务发现的呢？先看一张图：虽然k8s集群内部署的pod、server都有自己的IP，但是却无法提供外网访问，以前我们可以通过监听NodePort的方式暴露服务，但是这种方式并不灵活，生产环境也不建议使用。Ingresss是k8s集群中的一个API资源对象，扮演边缘路由器(edgerouter)的角色，也可以理解为集群防火墙、集群网关，我们可以自定义路由规则来转发、管理、暴露服务(一组pod)，非常灵活，生产环境建议使用这种方式。另
K8S-INGRESS原理，部署及应用
热门推荐
运维老炮
12-20 1万+
一. 题记 各位，总算回来！博客断更快一年了吧，这一年过的真不容易，和疫情一样。公司降薪换工作，到了新公司和我八字不合，差点给我整出来抑郁症，又开始换工作，刚稳定了两周，又出车祸了，被一个老大爷骑着三轮车怼成了骨折。自己遭罪又贴钱，倒了血霉了。这本命年真是不好过呀。还好到年底了，这一年就要结束了。小太爷又回来了！回来就好，回来就继续写博客吧，就这命了！我记得k8s原理我写到了pod原理这块，先放放，刚做了ingress，先学这个吧，这个有点意思。 我打算用三...
1W字长文：K8S Ingress 原理和实操
架构师尼恩
03-29 1888
SVC、Ingress原理和实操，是云原生的基础知识。这里尼恩给大家 调优，做一下Ingress 的系统化、体系化的梳理，并收入尼恩的《K8S学习圣经》。
k8s nginx ingress原理解读
zjy_love_java的博客
02-24 3148
阅读本文需要以下知识为前提 了解k8s基本架构，k8s基本资源清单 用自己的k8s实验环境 首先了解ingress解决了什么问题 k8s内部项目暴露外部访问，只用一个固定端口,暴露多个服务。相对于：LoadBlancer Service、NodePort Service更灵活更方便。 pod漂移后的ip变化，自动识别pod ip 修改nginx配置不用reload加载 实现灰度发布（根据流量或者http请求头进行灰度） 架构介绍 ingress controller 入口流量控制器。Kubern
k8s ingress原理及ingress-nginx部署测试
xiaxia2022的博客
09-26 981
ingress 原理 service的三种方式ClusterIP、NodePort与LoadBalance，这几种方式都是在service的维度提供的，service的作用体现在两个方面，对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制，对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。但是，单独用service暴露服务的方式，在实际生产环境中不太合适：ClusterIP的方式只能在集群内部访问。NodePor...
【精品】k8s的Ingress通俗讲解
Friendsofthewind的博客
11-12 1348
1、了解ingress的原理2、掌握helm安装ingress的方法。
K8S原理剖析：网络模型原理剖析和实践
琦彦
01-01 1978
大纲 网络模型与CNI Service Ingress DNS Network Policy 网络模型与CNI 一个Pod一个IP - 每个Pod独立IP， Pod内所有容器共享网络namespace（同一个IP） - 容器之间直接通信，不需要NAT - Node和容器直接通信，不需要NAT - 其他容器和容器自身看到的IP是一样的 集群内访问走Service，集群外访...
【k8s系列十四】nginx-ingress原理
BASK2312的博客
11-05 2859
现在所有的app再上线之前都必须进行加密，这里的加密不是说对应用加密，而是对请求加密，比如https加密请求。如果我们使用的是clusterIp类型， clusterIp是四层协议，那么就不能再svc层加密，这时必须在每一个app上进行加密。也就是每台服务器都要配置https加密协议这样的问题是，每次上线一个app，都要对app进行加密。很多重复操作。那么，我们能不能换一种方案，就实现一次加密呢？
k8s ingress
学亮编程手记
06-14 298
kubernetes ingress
03-16
Kubernetes Ingress是一种Kubernetes API对象，用于管理入站网络流量。它允许将流量路由到Kubernetes集群中的不同服务，并提供了负载均衡、SSL终止、路径路由和基于名称的虚拟主机等功能。Ingress可以使用不同的控制器实现，如Nginx、Traefik、HAProxy等。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值