--- tags: - k8s - l1 - flashcard-deck - api-gateway --- [Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [API Gateways & Ingress](../../../../library/portal/topics.md) | **Domain:** Kubernetes id category difficulty tags question answer source_path api-gateway/64785c3b0be0 api-gateway easy api-gateway, ingress, architecture What does an ingress controller do in Kubernetes? An ingress controller is a dynamically-configured reverse proxy that watches the Kubernetes API for Ingress or Gateway API resources, generates proxy configuration, routes incoming requests to the correct backend Service based on hostnames and paths, and handles TLS termination.\n\nRemember: ingress controller = 'smart front door for your cluster.' It watches Kubernetes API for route changes and reconfigures its proxy automatically.\n\nExample: nginx-ingress, Traefik, HAProxy Ingress, Kong Ingress, and Contour are popular implementations. training/library/topics/api-gateways/primer.md api-gateway/05dac13339fd api-gateway easy api-gateway, tls, termination What are the three TLS modes for ingress and when do you use each? Termination: TLS ends at ingress, HTTP to backend — most common and simplest. Re-encryption: TLS at ingress, new TLS connection to backend — when backends require TLS. Passthrough: ingress forwards raw TCP, backend handles TLS — for end-to-end encryption requirements.\n\nRemember: TTP — Termination (most common), re-encryption (Transit TLS), Passthrough (end-to-end). Mnemonic: 'TLS Terminates, Transits, or Passes.' training/library/topics/api-gateways/primer.md api-gateway/af7be895831d api-gateway easy api-gateway, routing What is the difference between host-based and path-based routing in an ingress? Host-based routing directs traffic based on the hostname (api.example.com -> api-service, web.example.com -> web-service). Path-based routing uses URL paths on the same host (example.com/api -> api-service, example.com/web -> web-service). Most production setups combine both.\n\nRemember: host-based = virtual hosting (like Apache VirtualHost). Path-based = URL routing. Most setups combine both. training/library/topics/api-gateways/primer.md api-gateway/1cfe3abc29fd api-gateway medium api-gateway, rate-limiting How do you configure rate limiting at the ingress layer in nginx-ingress? Use annotations: nginx.ingress.kubernetes.io/limit-rps for requests per second per IP, limit-rpm for requests per minute, limit-connections for concurrent connections per IP, and limit-whitelist to exempt internal IP ranges (e.g., 10.0.0.0/8). Rate limiting at the edge protects backends from overload and abuse.\n\nGotcha: annotation-based rate limiting is per-IP. Behind a NAT or proxy, all users share one IP — add X-Forwarded-For awareness or use a smarter gateway. training/library/topics/api-gateways/primer.md api-gateway/0a5a72f28286 api-gateway medium api-gateway, auth, edge How does external authentication work at the ingress layer? The ingress controller forwards each request to an auth service URL before routing to the backend. If the auth service returns 200 OK, the request proceeds to the backend with auth response headers (e.g., X-User-ID, X-User-Email) injected. If it returns 401, the client gets a 401. This pushes authentication to the ingress so individual services don't each implement it.\n\nRemember: pushing auth to the ingress layer (edge authentication) means individual services don't implement auth — reducing code duplication and security surface area. training/library/topics/api-gateways/primer.md api-gateway/1b25bf6a1185 api-gateway medium api-gateway, cert-manager How does cert-manager automate TLS certificate management with ingress? Create a ClusterIssuer pointing to Let's Encrypt with an ACME solver (http01 or dns01). Add the annotation cert-manager.io/cluster-issuer to your Ingress resource and specify a secretName under tls. cert-manager automatically provisions, renews, and stores the certificate in the specified Kubernetes secret. Set up once, stop manually managing certs.\n\nRemember: cert-manager automates the entire TLS lifecycle: request, validate (HTTP-01 or DNS-01), issue, store, and renew. Set up once, forget about cert expiry. training/library/topics/api-gateways/primer.md api-gateway/ec153e82b970 api-gateway medium api-gateway, annotations Why are annotation typos particularly dangerous in ingress controller configuration? Ingress controllers use annotations for controller-specific features (timeouts, rate limiting, CORS, auth, body size, etc.). Typos in annotation names fail silently — the configuration is simply ignored without any error. This means a misspelled rate-limiting annotation provides zero protection, and you might not discover the gap until an incident occurs.\n\nRemember: ingress controller = 'smart front door for your cluster.' It watches Kubernetes API for route changes and reconfigures its proxy automatically.\n\nExample: nginx-ingress, Traefik, HAProxy Ingress, Kong Ingress, and Contour are popular implementations. training/library/topics/api-gateways/primer.md api-gateway/deca61d9530f api-gateway hard api-gateway, comparison Compare Nginx Ingress, Traefik, Kong, and Envoy/Istio across key features. Nginx: annotation-based config, basic per-IP rate limiting, low complexity, best for standard web apps. Traefik: CRDs + annotations, built-in web UI, low-medium complexity, best for dynamic services. Kong: CRDs + plugins, advanced Redis-backed rate limiting, JWT/OAuth/OIDC auth, medium complexity, best for API management. Envoy/Istio: CRDs with full service mesh, advanced traffic splitting, Kiali dashboard, high complexity, best for service mesh architectures.\n\nRemember: the ingress layer is your cluster's front door. Every request passes through it — making it the ideal place for cross-cutting concerns: TLS, auth, rate limiting, and observability. training/library/topics/api-gateways/primer.md api-gateway/61f91c4b8957 api-gateway hard api-gateway, gateway-api What advantages does the Gateway API have over the traditional Ingress resource? Gateway API is the successor to Ingress with: role-oriented design (separate Gateway resource for infra teams from Routes for app teams), native traffic splitting for canary and blue-green deployments, header-based routing, request/response manipulation, and cross-namespace references. It provides these capabilities without relying on controller-specific annotations.\n\nRemember: Gateway API = 'Ingress v2.' Role-oriented (infra team owns Gateway, app team owns Routes), with native canary and header-based routing — no annotation hacks. training/library/topics/api-gateways/primer.md api-gateway/5f7f77a519d5 api-gateway hard api-gateway, canary, gateway-api How do you implement canary deployments using the Gateway API HTTPRoute resource? Define an HTTPRoute with multiple backendRefs under the same rule, each with a weight. For example, api-v1 with weight 90 and api-v2 with weight 10 sends 10% of traffic to the canary. This is native to the Gateway API spec — no controller-specific annotations required. Adjust weights to gradually shift traffic as confidence in the new version increases.\n\nRemember: canary at the ingress layer means traffic splitting without application changes. Adjust weights to control rollout speed. Combine with monitoring for automated rollback. training/library/topics/api-gateways/primer.md --- ## Wiki Navigation ### Related Content - [API Gateways & Ingress](../../../../library/topics/api-gateways/index.md) (Topic Pack, L2) — API Gateways & Ingress