Написать в техподдержку Позвонить нам
Admin Panel Logout

In this article:

    Ingress controller

    Ingress Controller

    When creating a PaaS Kubernetes cluster, you can choose from the pre-installed NGINX Ingress Controller services. If it was selected, then after creating the cluster, the ingress controller will be deployed automatically

    The Ingress controller consists of 2 components - a controller that interacts with the Kubernetes API server and a reverse proxy server. The controller receives data about ingress objects from the API server and, based on them, configures the operation of the reverse proxy.

    Important

    For ingress to work as Kubernetes objects, an ingress controller is required in the cluster. Ingress objects will not work without it.

    After creating a cluster, the ingress controller rises in it as a pod located in the ingress-nginx namespace. Its presence can be checked with the command:

     $ kubectl get pods -n ingress-nginx
    NAME READY STATUS RESTARTS AGE
    nginx-ingress-controller-8696859596-74fwj 1/1 Running 0 7d21h
    nginx-ingress-default-backend-7c57f78d75-nmq5f 1/1 Running 0 7d21h

    The ingress-controller is accessible from the outside through the nginx-ingress-controller service, which has the LoadBalancer type, it can be found in the list of services in the ingress-nginx namespace, its "white" address can be found there:

     $ kubectl get svc -n ingress-nginx
    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGE
    nginx-ingress-controller LoadBalancer 10.254.23.44 89.208.85.23 80: 30080 / TCP, 443: 30443 / TCP 61d
    nginx-ingress-controller-metrics ClusterIP 10.254.101.237 <none> 9913 / TCP 61d
    nginx-ingress-default-backend ClusterIP 10.254.33.216 <none> 80 / TCP 61d

    Ingress

    Ingress is a Kubernetes object that describes the rules for proxying traffic from an external source to services within the K8S cluster.

    Let's look at an example.
    Let's create an nginx-pod in a cluster with an Nginx web server that will display the "Hello World!"
    Let's create a test-service service that will direct traffic to under nginx-pod.
    Let's create a test-ingress ingress that will proxy traffic to the test-service .

    The manifest for the pod and its configmap (which will act as the configuration file for the web server):

     ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: my-configmap
    data:
    default.conf: |
    server {
    listen 80 default_server;
    server_name _;
    
    
    default_type text / plain;
    
    
    location / {
    return 200 "\ n'Hello World! '\ n";
    }
    }
    ---
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx-pod
    labels:
    app: my-app
    spec:
    containers:
    - image: nginx: 1.12
    name: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: config
    mountPath: /etc/nginx/conf.d/
    volumes:
    - name: config
    configMap:
    name: my-configmap

    In the config map we will describe the configuration for the nginx web server, and in the pod we will mount this config map in /etc/nginx/conf.d/ . For the pod, let's set the label app: my-app.

    Service Manifest:

     ---
    apiVersion: v1
    kind: Service
    metadata:
    name: test-service
    spec:
    selector:
    app: my-app
    ports:
    - protocol: TCP
    port: 80
    targetPort: 80

    Let's create a service that listens on port 80 and routes traffic to port 80 over TCP. As a selector, we will specify the label of our pod app: my-app .

    Ingress manifest:

     ---
    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
    name: test-ingress
    annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    spec:
    rules:
    - http:
    paths:
    - path: / testpath
    backend:
    serviceName: test-service
    servicePort: 80

    Let's describe the ingress, specifying that when the path / testpath is passed, traffic is directed to the test-service service on port 80.

    Let's create all the described objects by executing the command for each manifest:

     $ kubectl apply -f <object.yaml>

    Then let's check them:

     $ kubectl get configmap
    NAME DATA AGE
    my-configmap 1 173m
    $ kubectl get pods
    NAME READY STATUS RESTARTS AGE
    nginx-pod 1/1 Running 0 173m
    $ kubectl get svc
    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGE
    kubernetes ClusterIP 10.254.0.1 <none> 443 / TCP 62d
    test-service ClusterIP 10.254.175.104 <none> 80 / TCP 3h58m
    $ kubectl get ing
    NAME HOSTS ADDRESS PORTS AGE
    test-ingress * 80 3h27m

    Now, to check, we will execute a request to the public address of the nginx-ingress-controller service along the path / testpath:

     $ curl -k https://89.208.85.23/testpath
    
    'Hello World!'

    Note

    In this example, everything was created for http traffic, but the preinstalled ingress controller has a redirect from http to https, so https was used for verification.

    Was this article helpful?