A Guide to Choosing an Ingress Controller, Part 3: Open Source vs. Default vs. Commercial

This is the third blog post in our series on how to choose a Kubernetes Ingress controller.

• How to Choose a Kubernetes Ingress Controller, Part 1: Identify Your Requirements
• How to Choose a Kubernetes Ingress Controller, Part 2: Risks and Future-Proofing
• How to Choose a Kubernetes Ingress Controller, Part 3: Open Source vs Default vs Commercial (this post)
• How to Choose a Kubernetes Ingress Controller, Part 4: NGINX Ingress Controller Options (coming soon)

Congratulations! After reading Part 1 and Part 2 of our series, you’re almost ready to select an Ingress controller. Let’s recap where we’ve been so far:

• In Part 1, we discuss how to identify your requirements, including performance, budget, use cases, architecture, and ownership.
• In Part 2, we talk about risks that you might introduce by selecting the wrong Ingress controller and outline key areas where you can future‑proof your selection.

Ingress controllers fall into three categories: open source, default, and commercial. Each has its use cases, and it’s important to be clear on your short‑ and long‑term needs before making a selection. In this blog, we cover the pros and cons of each category.

Open Source Ingress Controllers

Many open source Ingress controllers are maintained by a community of users and volunteer developers, though some also have dedicated engineering teams. Two of the most popular open source Ingress controllers are based on NGINX – one is maintained by the Kubernetes community and the other is led by the core NGINX engineering team and open sourced. For further comparison of NGINX‑based Ingress Controllers, see Part 4 of our series.

• Pros:
  • Free and community‑driven – Many people and organizations choose open source projects not only because of the unbeatable price (free!), but also because they prefer community‑developed tech.
  • Feature velocity – These Ingress controllers are more likely to be on the cutting edge of feature innovation.
• Cons (shared with open source projects in general):
  • Cost (time) – They lack “out of the box” tooling for easy setup and scalability, so you end up spending time on customizations and workarounds for your specific needs.
  • Risky – There can be issues with stability, security, and reliability (due to the emphasis on feature velocity and the volunteer nature of contributors). Patches for Common Vulnerabilities and Exposures (CVEs) may never come, or might arrive months after the CVE is publicly disclosed, giving hackers plenty of time to attack your Ingress controller.
  • Minimal or no support – Most are “self‑solve”…it’s just you and the docs. If you run into problems you can’t solve yourself, it can be difficult (or impossible) to get help – just about your only choice is to post your problem on community forums and hope other members of the community (a) bother to respond and (b) know of a solution.
• Summary: When organizations first start experimenting with Kubernetes, they often choose an open source Ingress controller, for convenience or because the docs promise you can get up and running quickly for free. This can work beautifully when you’re getting started, in testing, or running low‑volume production.

Default Ingress Controllers

Although many default Ingress controllers are based on open source technology, we categorize them separately because they’re developed and maintained by a company that provides a full Kubernetes platform (and often support in managing it). Examples from this category include public cloud Ingress controllers, Rancher, and Red Hat OpenShift router.

• Pros:
  • Free or low cost – The low price tag is a compelling reason to use these products. They’re already integrated into the platform, a definite time‑saver when you’re first getting started.
  • Reliable and supported – Because they’re maintained by a dedicated engineering team, they may be more reliable than community‑maintained Ingress controllers. Commercial support is typically included or available at an extra cost.
• Cons:
  • Infrastructure lock‑in – Default ingress controllers are not infrastructure‑agnostic, so you can’t take them or your configurations from cloud to cloud. That means you need different Ingress controllers for each deployment environment, which causes tool sprawl, increases the learning curve for your teams, and makes the Ingress controller more difficult to secure.
  • Basic features – They usually lack the advanced traffic management and security capabilities necessary for large scale deployments.
  • Unpredictable costs (time and money) – While initial costs are nil or low, they can increase dramatically and unpredictably as your application grows. This can take the form of time required to build functionality into your app that’s missing from the Ingress controller’s minimal feature set – and of course you have to regression‑test that functionality every time you update the app. Another drawback of some default tools is huge jumps in your cloud bill as your app becomes more popular, due to throughput charges that seem innocuous at first.
• Summary: A default Ingress controller is a popular choice for teams that are newer to Kubernetes and using a managed platform such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher, and Red Hat OpenShift Container Platform. As their apps mature and teams grow, organizations often choose to add an enterprise‑grade Ingress controller to their stack, rather than replacing the default tool.

Commercial Ingress Controllers

These Ingress controllers are licensed products that are designed to support large production deployments. One example is the NGINX Plus-based version of F5 NGINX Ingress Controller, which we’ll discuss more in Part 4.

• Pros:
  • Large feature set – Commercial Ingress controllers include robust feature sets that support advanced traffic management and scalability for large deployments. There may be integrations with other production‑grade products, such as a WAF or service mesh.
  • Scalable – Organizations often find these options to be time‑savers since they tend to have more “out-of-the-box” capabilities that don’t require customization or workarounds. They can easily be added to automation pipelines to allow your infrastructure to grow as needed.
  • Reliable and supported – One of the main benefits of commercial products is that they’re stable, which means extensively tested at each release, with regular software updates and security patches as needed. Full commercial support is typically available in various tiers, so you can often get confidential help within minutes or hours of encountering a critical problem.
• Cons:
  • Slower development – Because stability is important for commercial Ingress controllers, their feature velocity might lag a little bit behind their open source counterparts.
  • Cost (money) – The reality of commercial products is they cost money. For organizations that have more developer cycles than cash, the cost can be a deal breaker until that situation changes.
• Summary: As organizations scale, the choice of Ingress controller becomes more important based on the complexity of their teams and apps. Once an organization reaches a high degree of complexity, a commercial Ingress controller makes sense because it can reduce management complexity and accelerate time to market for new product features.

Next Step: Evaluate the Options

At this stage in your journey, you’re ready to home in on some Ingress controllers to try by eliminating options that can’t meet your needs. One great place to start your high‑level feature comparison is learnk8s, which provides a free comparison table of the Ingress controllers they’ve evaluated.

As you’re researching Ingress controllers, you’ll likely notice that many options are based on NGINX. For an overview of the NGINX‑based choices, check out the final blog in this series, A Guide to Choosing an Ingress Controller, Part 4: NGINX Ingress Controller Options, coming soon.