10、Ingress资源

发表于： 2019年11月19日 2023年1月30日
分类： Kubernetes

Ingress
Ingress配置示例
Ingress Controller
Ingress Controller实践
方式一NodePort
方式二hostPort
方式三hostNetwork
Ingress实践
Ingress资源类型
Ingress annotations
Ingress配置实践
访问流程
ingress配置https

TOC

Ingress

    官方文档：https://kubernetes.io/zh/docs/concepts/services-networking/ingress/
    Ingress仅用于定义流量转发和调度的通用格式的配置信息，他们需要转换为的特定的具有http协议转发和调度功能的应用程序，例如Nginx、Haproxy、Traefik等的配置文件，并由相应的应用程序生效相应的配置后完成流量转发；
    无论是Service的iptables还是ipvs，他们都是四层调度，如果我们有多个Pod，又需要向外部提供https服务，那这个时候我们就需要在每一个Pod上面配置https服务，每一个Pod上面都需要配置证书、私钥等信息，这时候管理起来极其麻烦，因此我们应该让我们的调度器能够实现https卸载，但很显然四层调度是没这功能的，因为我们就需要引入一个七层调度器，但是七层调度器它不在内核工作，而Service此前之所以能够拦截每一个客户端的请求并且能正常代理给后端被调用的Endpoint，恰恰因为它在每一个节点的内核上，所以它能够拦截每一个对ClusterIP的访问，但是如果需要工作在七层，七层是一个应用进程， 那么这个进程就需要部署在Kubernetes之上表现为一个Pod，一个客户端访问访问另外一个Pod要经由一个七层Pod，那就比较麻烦了；
    因为正常情况下，Pod和Pod之间都在一个网段当中，他们可以彼此通信，但是这些Pod可能会随时变更的，而Service之所以能够做到，原因在于每一个节点上的内核空间当中都存有iptables或ipvs规则，所以我们每一个客户端访问ClusterIP时，能够被拦截住，但是现在不使用Service，那么就很难做到在每一个节点本地当一个客户端访问某一个Pod服务时，能直接被拦截了，但是现在需要做到的是一个Pod作为客户端视图与服务端进行通信时，要让它经由另外一个Pod代理才行，因为我们的代理服务器是一个七层应用，而七层应用部署在Kubernetes之上，它一定是一个Pod程序，所以正常的Pod和Pod之间的通信要被另外一个Pod所拦截才能完成，这就很麻烦了；
    为此我们的Kubernetes专门提供了一种资源类型，它其实就是一种七层流量的路由规则，它能够把来自于客户端对某一个URL的访问转换为当前集群上的一个特定的Pod的访问，Ingress就是让你使用一种通用格式，你只需要告诉Ingress把哪个URL代理给哪个URL，Ingress就可以自动转换为其他格式，比如转换为Nginx格式、Haproxy格式、Httpd格式等，自动转换；
    为什么需要转换呢，因为上面说过，我们必须部署一个Pod，来实现七层代理，这个Pod跑的可能是Nginx也可能是Haproxy，给了用户很多选择，所以你不论在跑什么，只要是Kubernetes支持的，作为管理来讲，只需要按需定义一个Ingress资源来它就能够让这个七层Pod从API Server中实时监控代理信息，并且还可以把代理信息拉到本地，自动由于这个Pod控制器转为适用为代理程序的配置格式，并且还能自动Reload并立即生效，而这个Pod也被成为控制器，它有一个特殊称呼叫Ingress Controller；
    因此我们要使用七层代理在Kubernetes之上，需要经由两个步骤来完成，第一需要先有一个Ingress Controller存在，而这个Ingress Controller和Pod Controller不一样，Ingress Controller没有被打包到Controller Manager当中，它自己需要作为一个守护进程运行，而在Kubernetes之上除了kubelet和Docker之外，剩下的系统级服务既可以运行为系统级的守护进程，也可以运行为一个Pod，所以Ingress Controller到底是运行在系统之上使用Systemctl进程管理还是运行为一个Pod没什么区别；
    Ingress Controller没有被打包到Controller Manager当中是因为它很复杂，它随时需要变动，为了便于配置它，所以我们不得不把他配置为Pod方式，因为这样才便于配置，要运行为系统级守护进程，那么我们Ingress资源发生变化以后，底层的守护进程是没办法和我们的Apiserver进程联动的，这也是把它运行为一个Pod的主要原因；
    所以在Kubernetes之上要想使用七层代理，需要两个组件，第一个组件是Ingress Controller事先把它部署并运行在Kubernetes集群之上的，第二我们可以为Pod和Pod之间的互相访问不再使用Service做四层代理，而是借助这个Pod Controller做七层代理，但是这个七层代理到底怎么配置我们需要借助Ingress定义；
    Ingress也是一个标准的Kubernetes资源对象，只不过这个对象是用来管理集群外部请求到Service的请求，尤其是HTTP，所以从某种意义上来讲，Ingress主要作用就是把集群外部的流量引入集群内部。集群外部的请求先请求我们的Ingress Pod由这个Pod再用七层代理的方式代理给集群之上的其他正常提供服务的后端应用Pod，假如说我当前集群上部署了多个应用，我们不可能为每一个应用都提供一个Ingress Pod来代理，所以以Nginx为例，我们可以定义多个upstream并使用虚拟主机的方式来进行转发；

Ingress配置示例

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http: # 虚拟主机名称
      paths:
      - paths: /testpath # 前端路径；
        backend: # 映射的后端服务池
          serviceName: test # 关联到后端的Service资源，因为Ingress不支持标签选择器选择Pod，它需要借助Service的标签选择器匹配到的各个Pod对象将成为反代服务的后端，Service在此处发挥的作用仅仅是帮助我们的Ingress提供一个过滤器找到Pod，它并不是Ingress代理的后端，Ingress直达Pod；
          serevicePort: 80 # 对应的端口
# Ingress自身不支持使用标签选择器挑选真正提供服务的Pod对象，因此，它需要由Service对象的辅助来完成此类功能

    Ingress自身也是一个Pod，拿它怎么引入外部流量呢，要想让Pod其实引入集群外部的流量有三种，第一种是NodePort、第二种是HostPort、第三种是HostNetwork，在生产环境下，正常情况，你应该让你的集群当中应该有那么几个特殊的Node，这几个Node极具有，节点使用的机房私网地址也应该有公网地址，随后我们使用时，可以给这三个节点上部署一个Ingress Controller进程，这个Ingress Controller也应该由Pod Controller进程控制，这个Pod Controller可能是一个DaemonSet控制器也可能是一个Deployment控制器，可以用三个节点，打上污点或者使用节点选择器，使用DaemonSet控制Ingress Controller只运行在这几个节点，因此我们就可以确保Ingress Controller只运行这几个节点上了，其他节点不会运行，如果不想其他的Pod调度到这几个节点上来需要打污点。
    此后我们可以设定这三个节点的Pod网络使用HostPort，直接做映射，当客户端随意访问这几个节点的端口，由这个节点自己通过DNAT去转发给当前节点上的Ingress Pod，然后由Ingress Pod再转发给我们的后端Pod；
    还有一种方式，我们完全可以让Pod直接共享节点网络名称空间，这样Ingress Pod不论跑在哪个节点上都行，它直接与节点共享网络名称空间，那么这个时候用户通过节点的公网地址就直接访问到了Ingress Pod，这就实现了一次代理直达Pod；

Ingress Controller

    能理解Ingress定义的配置信息，并可将其转换为自身配置的应用程序即为Ingress Controller，但对于Ingress Controller来讲Nginx、Haproxy等这些代理程序，其实都不是云原生的(不是标准的Ingress Controller)，也就是说默认不是我们把Nginx跑为一个Ingress Pod就能与Api Server进程通信就能够把Ingress定义转为自身的配置的，默认他们是不支持的，所以Kubernetes自己把Nginx应用程序拿来做了改造，支持了Kubernetes能够运行为一个Ingress Controller，Haproxy也进行了转换，我们需要把这个改造后的应用程序，部署在集群上，它才能够成为一个完整意义上的Ingress Controller提供服务；
改造后的Github：https://github.com/kubernetes/ingress-nginx

Ingress Controller实践

    配置清单地址：<a href="https://github.com/kubernetes/ingress-nginx">https://github.com/kubernetes/ingress-nginx</a>

方式一NodePort

    使用Service类型为NodePort的方式直接代理，NodePort只负责转发请求；

# 给node打标签，待会儿让ingress Controller运行在指定的node上需要用到 
[root@node1 ~]# kubectl label nodes node2.cce.com node-name=node2
node/node2.cce.com labeled
[root@node1 ~]# kubectl label nodes node3.cce.com node-name=node3
node/node3.cce.com labeled
# 配置kubernetes官方github
[root@node1 ~]# cat mandatory.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

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

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: 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
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: 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
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        node-name: node2  # 此处指定只在node2上创建ingress controller
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          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: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown
---
# 部署Ingress Controller部署完成只是说明有了七层代理的功能，要想使用我们还需要去配置它，并且现在还不能接入集群外部流量
[root@node1 ~]# kubectl apply -f mandatory.yaml 
namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.apps/nginx-ingress-controller created
# 定义Service，并且指定selector挑选ingress Controller，网络类型为NodePort直接将node的IP映射到ingress Controller Pod
[root@node1 ~]# cat service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: ingress-service
  namespace: ingress-nginx
  annotations:
    application.kubernetes.io/service: web
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 30880
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
    nodePort: 30443
    # 测试访问

方式二hostPort

    由于配置比较长就不在此处贴了，见附件，hostPort的方式，其实就是Ingress Controller前面不再需要一个Service做四层负载，而是直接在定义Ingress Controller的时候修改七层应用的那个Pod对象(也就是Ingress Controller里面的nginx那个Pod)的template.spec.containers里面加一个ports配置项，写入hostPort，由此用户的请求不再需要经过Service的代理，请求首先会达到hostPort也就是node节点上的端口，而后其请求会通过iptables或ipvs规则转发给Ingress Controller里面的80或者443端口；

方式三hostNetwork

    hostNetwork的方式和hostPort差不多，都是不需要前置Service，同时也都是利用node的网络来实现的，但是不同的是hostNetwork是直接与其所在的node共享网络名称空间，用户的请求是直达Ingress Controller并不需要经过转发，其配置主要是将IIngress Controller的时候修改七层应用的那个Pod对象(也就是Ingress Controller里面的nginx那个Pod)的template.spec.hostNetwork修改为True，这样Pod就不需要指定什么containerPort、hostPort；

Ingress实践

    通过以上的描述，可以看出，我们有时候可能需要用到七层代理功能于是就有了所谓的Ingress和Ingress Controller其中Ingress负责七层代理是如何实现的相关规则，而这个对应的规则必须转换为某一个真正能实现七层代理的应用程序配置，并由这个七层代理完成代理操作，因此我们就又需要在Kubernetes之上额外部署一个具有七层代理的应用程序，官方推荐使用nginx，我们把某一个基础的Ingress Controller部署在Kubernetes集群之上以后，它自己由于也是一个Pod，因此就需要经过精心规划以后，完成接入集群外部的流量，接入方式有三种，我们可以使用Deployment进行管理Pod，并为Pod设定一个NodePort类型的Service，从而接入集群外部的流量，第二种方式我们可以直接使用hostPort，让每一个对应的Pod通过其所在其节点之上的端口映射方式从而接入集群外部的流量，第三种方式直接共享节点的网络名称空间，这个时候节点如果自己拥有公网地址那它甚至可以接入公网客户端请求，当然有些时候，我们的Kubernetes集群也许在部署在另外一个机房或者另外一个公有云集群之上的，它本身也不需要具有公网地址也需要接入外部机房的负载均衡器接入外部流量并调度给我们对应的Ingress Controller所在的节点之上的相关端口来实现用户访问接入；

Ingress资源类型

单一服务：指定backend就行了，默认访问就会直接访问到这个ingress资源；
路径映射：和nginx的location差不多，访问对应的url转发到指定的Pod资源；
虚拟主机：和同一个Nginx应用定义多个Server，每个Server转发到指定的Pod资源；
TLS虚拟主机：和虚拟主机类型，只不过它是基于https协议，需要指定端口还有证书，定义TLS虚拟主机我们需要额外定义一个Secret资源；

Ingress annotations

    对于Ingress来讲annotations是有特殊意义的，比如我们多个Ingress Controller有一个nginx一个haproxy那么我们如果只期望我们的Ingress配置只被nginx解析，那么这个时候我们可以使用annotations来操作，定义资源时可以指定annotations作为资源注解，对于Ingress来讲这些annotations，我们可以使用一个annotations叫做kubernetes.io来定义Ingress类别；
    Ingress规则当中可以实现很多的annotations来控制这个规则是如何被应用程序配置文件的，比如说我们nginx的流控，我们通过Ingress的annotations也可以实现速率限制等操作；
相关文档地址：<a href="https://github.com/kubernetes/ingress-nginx/tree/master/docs/user-guide/nginx-configuration">https://github.com/kubernetes/ingress-nginx/tree/master/docs/user-guide/nginx-configuration</a>

Ingress配置实践

        创建Ingress Controller，直接apply官方的Ingress Controller，见github里面的deploy，此处的Ingress Controller就使用上面的NodePort类型；

# 创建资源
[root@node1 ~]# cat ingress.yaml 
# 创建Service，此Service主要是辅助Ingress挑选Pod
apiVersion: v1
kind: Service
metadata:
  name: ingress-service
  namespace: ingress-web
spec:
  selector:
    application.name: nginx
  ports:
  - name: http
    port: 80
    targetPort: 80
---
# 创建后端Pod池
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: ingress-web
spec:
  replicas: 3
  selector:
    matchLabels:
      application.name: nginx
  template:
    metadata:
      name: backend
      namespace: ingress-web
      labels:
        application.name: nginx
    spec:
      containers:
      - name: backend-node
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
---
# 创建Ingress配置，此配置会直接提交到Ingress Controller并动态修改里面七层应用的配置
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web-ingress
  namespace: ingress-web
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / # 这个annotations主要的作用是url重定向
    kubernetes.io/ingress.class: "nginx" # 指定ingress的类别为Nginx
spec:
  rules:
  - host: www.cce.com
    http:
      paths:
      - path: /
        backend:
          serviceName: ingress-service
          servicePort: 80
进入ingress Controller查看配置是否生效
[root@node1 ~]# kubectl exec -it -n ingress-nginx nginx-ingress-controller-568867bf56-t8zpw /bin/bash # 直接进入Pod
[root@node1 ~]# kubectl exec -it -n ingress-nginx nginx-ingress-controller-568867bf56-t8zpw grep 'server_name.*node1.cce.com' /etc/nginx/nginx.conf
                server_name node1.cce.com ; # 使用grep已经匹配到说明配置已经生效
测试访问
[root@node1 ~]# curl http://www.cce.com:30880/hostname.html
web-84dd646bcb-xm49d
[root@node1 ~]# curl http://www.cce.com:30880/hostname.html
web-84dd646bcb-kmndm
[root@node1 ~]# curl http://www.cce.com:30880/hostname.html
web-84dd646bcb-xcws8

访问流程

    ingress要想接入外部流量就需要一个Service，这个Service是没办法引入集群外部流量的，所以这里给它的类型设置为NodePort类型，然后这个Service自己有端口，它分别提供80调度给后端的80，443调度给ingress Controller的443，所以用户的请求先访问任何一个节点的30880，先会转发给这个Service的80端口， 然后由Service的80再转给ingress Controller里面的nginx的80，nginx就直接把请求调度给后端的Pod，而我们使用Pod控制器来控制，同时为了能让我们的ingress Controller识别是哪几个Pod，那还需要借助一个Service，把后端的Service归成一组，通过这个Service，我们的ingress Controller就知道是哪几个Pod；

ingress配置https

    七层代理的核心在于就是它能够帮助我们做一个七层的ssl会话卸载器，接下来就尝试做一个ssl类型的ingress；
# 使用Let’ s Encrypt SSL做的真实证书

[root@node3 ~]# ls
fullchain1.pem privkey1.pem
# 将证书转为kubernetes的secret资源，只要转为secret资源才能够被kubernetes引用，需要放在指定的namespace中
[root@node3 ~]# kubectl create secret tls doorta -n ingress-web --cert=fullchain1.pem --key=privkey1.pem
[root@node3 ~]# kubectl describe secrets -n ingress-web doorta
Name: doorta
Namespace: ingress-web
Labels: <none>
Annotations: <none>

Type: kubernetes.io/tls

Data
====
tls.crt: 3558 bytes
tls.key: 1704 bytes
# 配置Pod
[root@node1 ~]# cat ingress.yaml 
# 创建Service，此Service主要是辅助Ingress挑选Pod
apiVersion: v1
kind: Service
metadata:
  name: ingress-service
  namespace: ingress-web
spec:
  selector:
    application.name: nginx
  ports:
  - name: http
    port: 80
    targetPort: 80
---
# 创建后端Pod池
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: ingress-web
spec:
  replicas: 3
  selector:
    matchLabels:
      application.name: nginx
  template:
    metadata:
      name: backend
      namespace: ingress-web
      labels:
        application.name: nginx
    spec:
      containers:
      - name: backend-node
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
---
# tls的方式配置，默认会启用http和https，并且端口已经限定为80和443
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web-ingress-tls
  namespace: ingress-web
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /cce
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - blog.doorta.com
    secretName: doorta
  rules:
  - host: blog.doorta.com
    http:
      paths:
      - path: /
        backend:
          serviceName: ingress-service
          servicePort: 80  # 这里是对应Service的端口
# 测试访问
[root@node1 ~]# curl https://blog.doorta.com:30443/hostname.html
web-84dd646bcb-8rw9w
[root@node1 ~]# curl https://blog.doorta.com:30443/hostname.html
web-84dd646bcb-jvgqh
[root@node1 ~]# curl https://blog.doorta.com:30443/hostname.html
web-84dd646bcb-9n8kx

附件列表

cce

142

Ingress

Ingress配置示例

Ingress Controller

Ingress Controller实践

方式一NodePort

方式二hostPort

方式三hostNetwork

Ingress实践

Ingress资源类型

Ingress annotations

Ingress配置实践

访问流程

ingress配置https

附件列表

cce

发表回复