1. overview

In the last article, we introduced how to install and deploy traefik components through helm. Besides traefik, we also mentioned that the commonly used ingress controller s include Nginx, HAProxy, Kong and so on. In this article, we introduced how to install and deploy Nginx-ingress. Only after accumulating the experience of using different components, can we better compare its advantages and disadvantages and form the best one. Good practice.

2. Installation and deployment of nginx-ingress components

2.1 Find nginx-ingress through helm

# Step 1: Find nginx-ingress through helm
> helm search nginx-ingress
> helm inspect stable/nginx-ingress

2.2 Mirror Download and Upload

Some enterprises can't get Docker images from abroad because the server has no access strategy and firewall, so we need to prepare the images in advance and upload them to the private image warehouse.

# Step 2: Mirror preparation
> docker pull quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.1
> docker tag quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.1 registry.hankercloud.com/ingress-controller/nginx-ingress-controller:0.25.1
> docker push registry.hankercloud.com/ingress-controller/nginx-ingress-controller:0.25.1
> 
> docker pull k8s.gcr.io/defaultbackend-amd64:1.5
> docker tag k8s.gcr.io/defaultbackend-amd64:1.5 registry.hankercloud.com/google_containers/defaultbackend-amd64:1.5
> docker push registry.hankercloud.com/google_containers/defaultbackend-amd64:1.5

2.3 Component Deployment

In our last blog, we deployed traefik components in Deployment mode, and this time we deployed nginx-ingress components in DaemonSet mode.

# Step 3: Component deployment 
> helm install stable/nginx-ingress --name nginx-ingress --namespace=kube-system \
    --set fullnameOverride=nginx-ingress \
    --set controller.kind=DaemonSet \
    --set controller.daemonset.useHostPort=true \
    --set controller.metrics.enabled=true \
    --set controller.image.repository=registry.hankercloud.com/ingress-controller/nginx-ingress-controller \
    --set defaultBackend.image.repository=registry.hankercloud.com/google_containers/defaultbackend-amd64
# step4: check whether the deployment is successful
> helm list
> kubectl get all -n kube-system 
> kubectl logs $POD_NAME -n kube-system   

2.4 Load Balancing Configuration and Domain Name Resolution Processing

This time, we use DaemonSet to deploy nginx-ingress components, and use 80 and 443 interfaces of the host to receive http and https requests respectively. After we parse the corresponding domain name into the host IP of nginx-ingress Pod, we can access the corresponding domain name through the domain name.

However, the above configuration method can not achieve high availability. When the PC instance of nginx-ingress fails or its host fails, the corresponding domain name can not be accessed. Therefore, it is recommended to purchase load balancing devices in the public cloud and configure the corresponding list of back-end servers to achieve high availability.

2.5 Installation and Debugging

We deployed a wordpress application through helm above. In this paper, we continue to access domain names through this application, and input > curl-i http://10.0.0.182-H'Host: blog.hankercloud.com'in the local console. If we see a normal return, the deployment is successful.

3. Enterprise scenarios and Solutions

3.1 How to Separate Intranet from Intranet

• Step1: We first deploy two ingress components, one of which is to receive intranet access requests and the other is to receive extranet access requests. The corresponding configuration is as follows:

# Intranet nginx-ingress configuration statement:
spec:
  template:
    spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --default-backend-service=kube-system/nginx-ingress-default-backend
        - --election-id=ingress-controller-leader
        - --ingress-class=nginx
        - --configmap=kube-system/nginx-ingress-controller

# Outer Network nginx-ingress Configuration Statement:
spec:
  template:
    spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --default-backend-service=kube-system/nginx-ingress-external-default-backend
        - --election-id=ingress-controller-leader
        - --ingress-class=nginx-external
        - --configmap=kube-system/nginx-ingress-external-controller

The main difference between the two is that the values set by the parameter ingress-class are different.

• Step2: For domain names that need to be exposed to the public network, modify the definition of ingress, the corresponding configuration reference is as follows:

metadata:
  name: www
  annotations:
    kubernetes.io/ingress.class: "nginx-external"

• Step3: Check if the configuration is successful, execute kubectl exec ${POD_NAME} - n kube-system cat/etc/nginx/nginx.conf to see if the configuration file already contains the relevant configuration of the extranet domain name, and test and verify it locally.

4. References

https://kubernetes.github.io/ingress-nginx/deploy/

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/