kubernetes ingress - ghdrako/doc_snipets GitHub Wiki

• Compare Avaliable Ingress Controlers

In Kubernetes, Ingress is a native object that allows you to access your services externally by defining a set of rules. Using a reverse proxy, an Ingress controller implements these defined rules and routes external traffic to your services.

• https://devopscube.com/setup-prometheus-monitoring-on-kubernetes/

An ingress controller is a service where all the incoming traffic land. Once it lands, traffic is forwarded to the respective application based on rules.

Standard Kubernetes Ingress solutions provide load balancing only at layer 7 (HTTP or HTTPS traffic) and route transactions from outside of the cluster to Services within the cluster.

An Ingress cannot work without an Ingress controller. The Ingress controller evaluates the collection of rules defined by an Ingress that determine traffic routing. One example of a production-grade Ingress controller is the F5 NGINX Ingres Controler

$ minikube addons enable ingress
$ kubectl get pods -n ingress-nginx

The Ingress controller runs as a Pod in the namespace ingress-nginx:

Ingress rules

Rules defined by an Ingress object follow the three criteria

Type	Example	Description
An optional host	mycompany.abc.com	If a host is provided, then the rules apply to that host. If no host is defined, then all inbound HTTP(S) traffic is handled.
A list of paths	/corellian/api	Incoming traffic must match the host and path to correctly forward the traffic to a Service.
The backend	corellian:8080	A combination of Service name and port.

apiVersion: v1
kind: Service
metadata:
  name: apache-svc
spec:
  selector:
    app: apache
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

kubectl create -f apache-svc.yaml command. Proceed with creating ingress rules. The following is the YAML for it.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apache
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: apache-svc
            port:
              number: 8080

Once this is created, the ingress controller is told that whatever traffic is coming for domain apache.mario.com should be routed to the apache service.

Ingress is a native Kubernetes resource like pods, deployments, etc. Using ingress, you can maintain the DNS routing configurations. The ingress controller does the actual routing by reading the routing rules from ingress objects stored in etcd.

Without Kubernetes ingress, to expose an application to the outside world, you will add a service Type Loadbalancer to the deployments.

ingress add a reverse proxy layer (Ingress controller implementation) between the load balancer and the kubernetes service endpoint.

Note: The AWS, GCP cloud ingress controller implementation differs a little. The loadbalancer itself acts as a ingress controller. Refer to the GKE ingress setup blog to understand more.

Key things to understand about ingress objects.

1. An ingress object requires an ingress controller for routing traffic.
2. And most importantly, the external traffic does not hit the ingress API, instead, it will hit the ingress controller service endpoint configured directly with a load balancer.

Kubernetes Ingress Controller

Ingress controller is not a native Kubernetes implementation. This means It doesn’t come default in the cluster.

We need to set up an ingress controller for the ingress rules to work. There are several open-source and enterprise ingress controllers available.

An ingress controller is typically a reverse web proxy server implementation in the cluster. In kubernetes terms, it is a reverse proxy server deployed as kubernetes deployment exposed to a service type Loadbalancer.

You can have multiple ingress controllers in a cluster mapped to multiple load balancers. Each ingress controller should have a unique identifier named ingress-class added to the annotation.

In Kubernetes, a Service is an abstraction through which a set of Pods are exposed as a network service. When these services need to be consumed by other applications, they need to be made externally accessible. Kubernetes supports ClusterIP for consuming services internally from within the cluster, NodePort for consuming the service outside the cluster but within the network, LoadBalancer for consuming the services externally via the cloud load balancer, and there are also options for exposing an internal-facing load balancer for internal traffic outside of the Kubernetes cluster.

how configure Istio to expose a service using the Kubernetes Ingress resource

Kubernetes Ingress is a way to provide access to ClusterIP services in the cluster. Ingress defines the addressed host accepted by Ingress, along with a list of URIs and the services to which the request needs to be routed.

Along with defining Ingress, we also need to define Ingress controllers, which are another Kubernetes resource that is responsible for handling the traffic as per the specification defined in the Ingress resource. The following illustrates the relationship between Ingress, Ingress controllers, and Services. Please note that Ingress is a logical construct – that is, a set of rules enforced by the Ingress controller.

In this kind of Ingress configuration, although we are using Istio to manage the Ingress, we are limited by the spec of Kubernetes Ingress, which allows Ingress controllers to perform limited functions such as load balancing, SSL termination, and name-based virtual hosting. When using the Kubernetes Ingress resource type, we are not leveraging a wide range of functionality provided by Istio to manage Ingress. When using Istio, it is recommended to use the Istio Gateway CRD to manage Ingress