{"id":305,"date":"2022-09-02T01:56:00","date_gmt":"2022-09-02T01:56:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=305"},"modified":"2022-09-02T01:56:00","modified_gmt":"2022-09-02T01:56:00","slug":"kubernetes-ingress-tutorial","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=305","title":{"rendered":"Kubernetes Ingress Tutorial: Beginners Series"},"content":{"rendered":"

In this Kubernetes ingress tutorial, you will learn the basic concepts of ingress<\/strong>, the native ingress resource object, and the concepts involved in ingress controllers<\/strong>.<\/p>\n

Kubernetes Ingress is a resource to add rules to route traffic from external sources to the applications running in the kubernetes cluster.<\/p>\n

Here are the topics that I will cover in this complete guide to Kubernetes Ingress:<\/p>\n

Note<\/strong>: Today, you can get 30% discount<\/strong> on Kubernetes CKA, CKAD, CKS, and KCNA certifications using code DCUBE30<\/strong> at kube.promo\/latest<\/a><\/p><\/blockquote>\n

What is Kubernetes Ingress?<\/h2>\n

The literal meaning: Ingress<\/strong> refers to the act of entering.<\/p>\n

It is the same in the Kubernetes world as well. Ingress means the traffic that enters the cluster and egress is the traffic that exits the cluster.<\/p>\n

\"Kubernetes<\/figure>\n

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

Let’s understand ingress with a high-level example.<\/p>\n

Without Kubernetes ingress, to expose an application to the outside world, you will add a service Type Loadbalancer<\/code><\/strong> to the deployments. Here is how it looks. (I have shown the nodePort just to show the traffic flow)<\/p>\n

\"Exposing<\/figure>\n

In the same implementation, with ingress, there is a reverse proxy layer (Ingress controller implementation) between the load balancer and the kubernetes service endpoint.<\/p>\n

Here is a very high-level view of ingress implementation. In later sections, we will see a detailed architecture covering all the key concepts.<\/p>\n

\"Kubernetes<\/figure>\n
\n
\ud83d\udca1<\/div>\n
Note:<\/strong><\/b> The AWS, GCP cloud ingress controller implementation differs a little. For example AWS loadbalancer<\/a> itself acts as a ingress controller. Refer to the GKE ingress setup<\/a> blog to understand more about GCP loadbalancer.<\/div>\n<\/div>\n

Before Kubernetes Ingress?<\/h2>\n

Before the Kubernetes Ingress was stable, a custom Nginx or an HAproxy kubernetes deployment would be exposed as a Loadbalancer service for routing external traffic to the internal cluster services.<\/p>\n

The routing rules are added as a configmap in the Nginx\/HAProxy pods. Whenever there is a change in dns or a new route entry to be added, it gets updated in the configmap, and pod configs are reloaded, or it gets re-deployed.<\/p>\n

Kubernetes ingress also follows a similar pattern<\/strong> by having the routing rules maintained as native Kubernetes ingress objects instead of a configmap.<\/p>\n

And in place of Nginx\/HAProxy, we have ingress controllers, a customized version of Nginx\/HAProxy, etc., which fetches the routing rules dynamically.<\/p>\n

Also, there were implementations using consu<\/a>l and other service discovery tools<\/a> to update DNS changes to Nginx or HAproxy without downtime, which brings the exact implementation as ingress.<\/p>\n

When it comes to openshift, the router (HAproxy implementations) concept made it easy to expose service endpoints outside the cluster. All you have to do is make a router config (Openshift YAML object), and the openshift router takes care of everything. It is similar to Kubernetes ingress.<\/p>\n

How Does Kubernetes Ingress work?<\/h2>\n

If you are a beginner and trying to understand ingress, there is possible confusion on how it works.<\/p>\n

For example, You might ask, hey, I created the ingress rules, but I am not sure how to map it to a domain name or route the external traffic to internal deployments.<\/p>\n

You need to be very clear about two key concepts to understand that.<\/p>\n

    \n
  1. Kubernetes Ingress Resource:<\/strong> Kubernetes ingress resource is responsible for storing DNS routing rules in the cluster.<\/li>\n
  2. Kubernetes Ingress Controller:<\/strong> Kubernetes ingress controllers (Traefik\/HAProxy etc.) are responsible for routing by accessing the DNS rules applied through ingress resources.<\/li>\n<\/ol>\n
    \"ingress<\/figure>\n

    Let’s look at both the ingress resource and ingress controller in detail.<\/p>\n

    Kubernetes Ingress Resource<\/h2>\n

    The Kubernetes Ingress resource is a native kubernetes resource where you specify the DNS routing rules. This means, that you map the external DNS traffic to the internal Kubernetes service endpoints.<\/p>\n

    It requires an ingress controller for routing the rules specified in the ingress object. Let’s have a look at a very basic ingress resource.<\/p>\n

    apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: test-ingress\n  namespace: dev\nspec:\n  rules:\n  - host: test.apps.example.com\n    http:\n      paths:\n      - backend:\n          serviceName: hello-service\n          servicePort: 80<\/code><\/pre>\n
    The above declaration means, that all calls to test.apps.example.com<\/code> should hit the service named hello-service<\/code> residing in the dev namespace.<\/p>\n
    As you can see, all it has is routing rules. You can add multiple routing endpoints for path-based routing, you can add TLS configuration, etc.<\/p>\n
    Key things to understand about ingress objects.<\/p>\n
      \n
    1. An ingress object requires an ingress controller for routing traffic.<\/li>\n
    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.<\/li>\n<\/ol>\n
      Now, let’s understand the ingress controller.<\/p>\n
      Kubernetes Ingress Controller<\/h2>\n
      Ingress controller is not a native Kubernetes implementation<\/strong>. This means It doesn’t come default in the cluster.<\/p>\n
      We need to set up an ingress controller for the ingress rules to work. There are several open-source and enterprise ingress controllers available.<\/p>\n
      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<\/a> exposed to a service type Loadbalancer.<\/p>\n
      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<\/strong> added to the annotation.<\/p>\n
      How Does an Ingress Controller Work?<\/h2>\n
      Nginx is one of the widely used ingress controllers.<\/p>\n
      So let’s take an example of Nginx ingress controller implementation to understand how it works.<\/p>\n
      \"\"<\/figure>\n
        \n
      1. The nginx.conf<\/code> file inside the Nginx controller pod is a lua template that can talk to Kubernetes ingress API<\/strong> and get the latest values for traffic routing in real-time. Here is the template file<\/a>.<\/li>\n
      2. The Nginx controller talks to Kubernetes ingress API to check if there is any rule created for traffic routing.<\/li>\n
      3. If it finds any ingress rules, the Nginx controller generates a routing configuration inside \/etc\/nginx\/conf.d<\/code> location inside each nginx pod.<\/li>\n
      4. For each ingress resource you create, Nginx generates a configuration inside \/etc\/nginx\/conf.d<\/code> location.<\/li>\n
      5. The main \/etc\/nginx\/nginx.conf<\/code> file contains all the configurations from etc\/nginx\/conf.d.<\/code><\/li>\n
      6. If you update the ingress object with new configurations, the Nginx config gets updated again and does a graceful reload of the configuration.<\/li>\n<\/ol>\n
        If you connect to the Nginx ingress controller pod using exec and check the \/etc\/nginx\/nginx.conf<\/code> file, you can see all the rules specified in the ingress object applied in the conf file.<\/p>\n
        Ingress & Ingress Controller Architecture<\/h2>\n
        Here is the architecture diagram that explains the ingress & ingress controller setup on a kubernetes cluster.<\/p>\n
        It shows ingress rules routing traffic to two payment<\/code> & auth<\/code> applications<\/p>\n
        Now if you look at the architecture, it will make more sense and you will probably be able to understand how each ingress workflow works.<\/p>\n
        \"ingress
        Click to View in HD<\/span><\/figcaption><\/figure>\n
        List of Kubernetes Ingress Controller<\/h2>\n
        Following are the commonly used ingress controllers<\/strong> available for Kubernetes.<\/p>\n
          \n
        1. Traefik<\/a><\/li>\n
        2. HAproxy<\/a><\/li>\n
        3. Contour<\/a><\/li>\n
        4. GKE Ingress Controller for GKE<\/a><\/li>\n
        5. AWS ALB Ingress Controller Fro AKS<\/a><\/li>\n
        6. Azure Application Gateway Ingress Controller<\/a><\/li>\n<\/ol>\n
          Learnk8s has created a great document comparing all the available ingress controllers. Take a look at the comparison document<\/a>.<\/p>\n
          Deploy Your First Ingress Controller<\/h2>\n
          To understand the ingress and ingress controller better, you should get your hands dirty with an implementation.<\/p>\n
          I have published a detailed guide on setting up an Nginx ingress controller.<\/p>\n
          I have also covered some essential concepts like ingress admission controllers in detail.<\/p>\n
          Also, I have given step-by-step manifest deployment and explanation to get a deep understanding.<\/p>\n
          Check out the Nginx ingress controller setup guide.<\/a><\/p>\n
          Kubernetes Ingress FAQs<\/h2>\n
          Is Ingress a load balancer?<\/h3>\n
          Ingress is not a load balancer. It contains all the routing rules, custom headers, and TLS configurations. The ingress controller acts as a load balancer.<\/p>\n
          Why do I need an ingress controller?<\/h3>\n
          The ingress controller is responsible for the actual routing of external traffic to kubernetes service endpoints. Without an ingress controller, the routing rules added to the ingress will not work.<\/p>\n
          What is the difference between ingress and Nginx?<\/h3>\n
          Ingress is a kubernetes object. Nginx is used as an ingress controller (Reverse proxy).<\/p>\n
          Can we route traffic to multiple paths using ingress?<\/h3>\n
          Yes. With a single ingress definition, you can add multiple path-based routing configurations.<\/p>\n
          Does ingress support TLS configuration?<\/h3>\n
          Yes. You can have TLS configurations in your ingress object definition. The TLS certification will be added as a Kubernetes secret and referred to in the ingress object.<\/p>\n
          Conclusion<\/h2>\n
          In this Kubernetes Ingress Tutorial<\/strong>, we have seen how ingress works in Kubernetes. and its associated components. Choosing an ingress controller for production depends on various factors and requirements.<\/p>\n
          You can use the ingress controller comparison document <\/a>as a reference to choose an ingress controller.<\/p>\n
          Maybe just started learning about ingress or currently using ingress in projects.<\/p>\n
          Either way, drop a comment below and let me know your thoughts.<\/p>\n
          The advanced implementation of ingress<\/strong> is Gateway API. Please read our detailed Gateway API tutorial<\/a> for beginners to know more.<\/p>\n
          Also, if you are learning Kubernetes, check out my 30+ comprehensive Kubernetes tutorials<\/a>.<\/p>\n
          \n
          Ngu\u1ed3n:<\/strong> Kubernetes Ingress Tutorial: Beginners Series \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
          Source: https:\/\/devopscube.com\/kubernetes-ingress-tutorial\/<\/p>\n","protected":false},"author":1,"featured_media":306,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-305","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=305"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/305\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/306"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}