preface

In Kubernetes, the IP addresses of services and pods can only be used within the cluster network and are not visible to applications outside the cluster. To enable external applications to access services within the cluster, Kubernetes currently provides the following solutions:

• NodePort
• LoadBalancer
• Ingress

The three schemes, considering the NodePort is open external port directly, this need to manage all service open ports, the intent of the originally used k8s slightly against with us, our purpose is to foreign service access, internal can not for each service’s server and port management, while minimizing operational pressure, load balancing, Therefore, this solution is generally not chosen to realize external exposure services, while LoadBalancer requires cloud service support, which is generally required to pay, and considering the cost is not within the reference scope. Therefore, the last straw of Ingress, based on security and cost considerations, meets the needs of most people. Basic deployment reference: HELM 3.0 deployed nginx – ingress.

Introduction of Ingress

In the Kubernetes cluster, we know that the IP of service and pod are only accessible within the cluster. If external applications want to access services within the cluster, requests from outside the cluster need to be load-balanced to the NodePort exposed by the service on the Node, which is then forwarded by the Kube-Proxy component to the relevant POD. Ingress is a set of routing rules for requests to enter the cluster. Generally speaking, it provides an entrance for external access to the cluster and forwards external HTTP or HTTPS requests to the internal service of the cluster.

Ingress Access principle

The Ingress proxy is not a pod service, but a pod. The Ingress proxy is a pod service, so that the pod information can be obtained through the service.  

The access principle is as follows:

Ingress implements production environment service exposure solutions

Ingress usually exposes the service using http://domain/path. For production environments, a layer of Nginx agents has been configured to open application portals through port 80/443

The specific access principle is as follows:

When the service is deployed to K8S, can we use the original solution?

Solution 1: Use the nginx-ingress reverse proxy to replace the original Nginx

The specific implementation logic is as follows:

Solution 2: Use nginx-ingress to implement reverse proxy and connect upstream to the original Nginx service

The specific implementation logic is as follows:

The specific implementation

Open nginx-ingress port 80/443

According to our normal use, the server cluster where nginx-ingress resides does not open to the Internet. However, for easy use, we open the service to the Intranet using fixed IP through externalIPs. Other services/applications can access the nginx via HTTP/https://externalIPs/xxx can – ingress.

The configuration is as follows:

spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 31314
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
      nodePort: 30491
  selector:
    app: nginx-ingress
    component: controller
    release: nginx-ingress
  clusterIP: 10.100221.205.
  type: LoadBalancer
  externalIPs:
    - 192.1681.123.
  sessionAffinity: None
  externalTrafficPolicy: Cluster
Copy the code

Ingress rule writing

Write an Ingress rule that opens the service through Ingress. Note that the difference between this rule and the normal Ingress rule is the spec.rules.host option. Generally, we fill in our domain name, such as www.test.com, but we use plan 2 here, so there is no need to fill in this option. According to the following configuration, when accessing the test service, we only need to access the IP address we filled in the previous step, and the specific path is: http://192.168.1.123/test, so write access to the test service, realize the nginx – ingress through unified IP access services. We can configure the above service address to the upstream nginx proxy.

spec:
  rules:
    - http:
        paths:
          - path: /test
            backend:
              serviceName: test
              servicePort: 8080
Copy the code

Resolve ingress 308 issue

Ingress-nginx: if the ingress rule does not specify host, the default value of ingress-nginx is HTTPS. Therefore, you will encounter the problem of always accessing the 308 redirect.

Nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress configmap: nginx-ingress

data:
  compute-full-forwarded-for: 'true'
  enable-vts-status: 'false'
  forwarded-for-header: X-Forwarded-For
  ssl-redirect: 'false'
  use-forwarded-headers: 'true'
Copy the code

Then you can complete seamless docking production upstream ~~~