(개념) Ingress Controller 선택방법 Part1, 너의 요구사항을 인식해라

참고 : https://www.cncf.io/blog/2021/10/20/a-guide-to-choosing-an-ingress-controller-part-1-identify-your-requirements/

 

●What’s an Ingress Controller?

An Ingress controller is a specialized load balancer that manages the Layer 4 and 7 traffic entering Kubernetes clusters, and potentially the traffic exiting them. So that we’re all on the same page, here are the terms we use at NGINX (and they’re largely the same across the industry):

• Ingress traffic – Traffic entering a Kubernetes cluster
• Egress traffic – Traffic exiting a Kubernetes cluster
• North‑south traffic – Traffic entering and exiting a Kubernetes cluster (also called ingress‑egress traffic)
• East‑west traffic – Traffic moving among services within a Kubernetes cluster (also called service-to-service traffic)
• Service mesh – A traffic management tool for routing and securing service-to-service traffic

 

 

●Ingress Controller가 필요한 이유

쿠버네티스 서비스에 외부에서 접근이 필요할 경우, Ingress Controller를 통해 Connectivity Rule을 정의할수 있다. 

- Ingress Controller는 Kube-Proxy Distribution-Model을 대체한다.  그리고 APP delivery controller나 리버스 프록시 와 같은 추가적인 통제기능을 제공한다. 

- 서비스의 개별 POD에 대한 모니터링하고 지능적인 라우팅과 BlackHoled 상태로 빠지는 것을 방지한다.

- TLS통신 또는 Outgoing Traffic을 limit할 수 있는 egress Rule을 만들수 있다.

 

• Accepts traffic from outside the Kubernetes environment, potentially modify (shape) it, and distribute it to pods running inside the environment. The Ingress controller replaces the default kube-proxy traffic distribution model, giving you additional controls like those that application delivery controllers (ADCs) and reverse proxies provide in non‑Kubernetes environments.
• Monitors the individual pods of a service, guaranteeing intelligent routing and preventing requests from being “black‑holed“.
• Implements egress rules to enhance security with mutual TLS (mTLS) or limit outgoing traffic from certain pods to specific external services.

●What Problems Do You Want the Ingress Controller to Solve?

어떤 경우에 IC를 써야할지 USE CASE는 다음과 같다.

 

1) Load balancing (HTTP2, HTTP/HTTPS, SSL/TLS termination, TCP/UDP, WebSocket, gRPC)
- Traffic control (rate limiting, circuit breaking, active health checks)

 

2) Traffic splitting (debug routing, A/B testing, canary deployments, blue‑green deployments)

마치 MVC의 컨트롤러 분기 같은 경로에 따른 분기처리 

 

↓쿠버네티스 IG에 다양한 기능을 부여해서 복잡하게 쓰는걸 권장한다는 내용입니다.

But there’s no reason to settle for a “one‑trick pony” – most Ingress controllers can do more than manage traffic. By using the Ingress controller to solve multiple problems, not only do you reduce the size and complexity of your stack, but you can also offload non‑functional requirements from the apps to the Ingress controller. Let’s look at four non‑traditional Ingress controller use cases that can help make your Kubernetes deployments more secure, agile, and scalable while making more efficient use of your resources.

3) Monitoring and Visibility
메트릭 모니터링 과 같은 서비스에 적용해서 사용하라
Lack of visibility into the Kubernetes cluster is one of the biggest challenges in production environments, contributing to difficulty with troubleshooting and resiliency. Because Ingress controllers operate at the edge of your Kubernetes clusters and touch every bit of traffic, they’re well situated to provide data that can help you troubleshoot (and even avoid) two common problems: slow apps and resource exhaustion in the Kubernetes cluster or platform. For Ingress controller to improve visibility, it needs to:

 

Provide metrics in real time so you can diagnose what’s happening “right now”
Be able to export metrics to popular visibility tools, like Prometheus and Grafana, that plot values over time to help you predict traffic surges and other trends

 

4) API Gateway

Unless you’re looking to perform request‑response manipulation in Kubernetes, it’s very likely that the Ingress controller can double as your API gateway. Depending on its feature set, an Ingress controller might be able to provide core API gateway functions including TLS termination, client authentication, rate limiting, fine‑grained access control, and request routing at Layers 4 through 7.

5) Authentication and Single Sign‑On

Offloading authentication of login credentials from your Kubernetes services to your Ingress controller can solve two issues.

Enable users to log into multiple apps with a single set of credentials by implementing single‑sign on (SSO) with OpenID Connect (OIDC).
Eliminate the need to build authentication functionality into each application, allowing your developers to focus on the business logic of their apps.

6) Web Application Firewall Integration ← WAF 수준은 아니고.. 큰 의미는 없음
It’s not that an Ingress controller can serve as a web application firewall (WAF), but rather that the WAF can be consolidated with the Ingress controller. Although a WAF can be deployed at many places outside and within Kubernetes, for most organizations the most efficient and effective location is in the same pod as the Ingress controller. This use case is perfect when security policies are under the direction of SecOps or DevSecOps and when a fine‑grained, per‑service or per‑URI approach is needed. It means you can use the Kubernetes API to define policies and associate them with services. Further, the Ingress controller’s role‑based access control (RBAC) functionality can enable SecOps to enforce policies per listener while DevOps users set policies per Ingress resource.