{"id":1065,"date":"2026-02-22T07:17:08","date_gmt":"2026-02-22T07:17:08","guid":{"rendered":"https:\/\/devopsschool.org\/blog\/uncategorized\/ingress\/"},"modified":"2026-02-22T07:17:08","modified_gmt":"2026-02-22T07:17:08","slug":"ingress","status":"publish","type":"post","link":"https:\/\/devopsschool.org\/blog\/ingress\/","title":{"rendered":"What is Ingress? Meaning, Examples, Use Cases, and How to use it?"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition<\/h2>\n\n\n\n<p>Ingress is the gateway and rule set that controls how external or cross-cluster traffic reaches services inside a networked platform such as Kubernetes or a cloud environment.<\/p>\n\n\n\n<p>Analogy: Ingress is like a building&#8217;s lobby with a receptionist, security scanner, and directional signs that decide which visitor goes to which office.<\/p>\n\n\n\n<p>Formal technical line: Ingress is a configurable control plane entity that maps external requests to internal service endpoints based on routing rules, TLS termination, host and path matching, and associated policies.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is Ingress?<\/h2>\n\n\n\n<p>What it is:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A boundary control layer that exposes internal services to external clients or other network zones.<\/li>\n<li>A mapping mechanism for hostnames, paths, ports, and protocols to backend services.<\/li>\n<li>Often implemented as a proxy, load balancer, or cloud-managed gateway with rules and policies.<\/li>\n<\/ul>\n\n\n\n<p>What it is NOT:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not a full application firewall by itself.<\/li>\n<li>Not a replacement for service-to-service mTLS or internal service mesh controls.<\/li>\n<li>Not always equivalent to the cloud provider&#8217;s global load balancer unless explicitly wired.<\/li>\n<\/ul>\n\n\n\n<p>Key properties and constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Terminates or forwards TLS, enforces routing rules, and may provide features like rate limiting, WAF, authentication hooks, and observability.<\/li>\n<li>Constrained by the platform: Kubernetes Ingress resources differ from cloud provider implementations.<\/li>\n<li>Performance and cost limits depend on implementation (throughput, concurrent connections, L7 features).<\/li>\n<li>Security boundaries depend on where TLS and auth are enforced.<\/li>\n<li>Requires careful lifecycle management for certificates, DNS, and scaling.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Edge entry point for user-facing traffic and API gateways.<\/li>\n<li>Integrated into CI\/CD pipelines for automated route updates and certificate rotation.<\/li>\n<li>Observability and SLO enforcement point for ingress SLIs.<\/li>\n<li>First responder in incident playbooks for traffic-related outages or degradations.<\/li>\n<\/ul>\n\n\n\n<p>Text-only diagram description (visualize this):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public Internet -&gt; DNS -&gt; Edge Load Balancer \/ Gateway -&gt; Ingress Controller -&gt; TLS termination -&gt; Routing rules based on host\/path -&gt; Service proxies -&gt; Application pods or instances -&gt; Upstream databases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Ingress in one sentence<\/h3>\n\n\n\n<p>Ingress is the configurable entry controller that routes, secures, and observes external traffic into your internal services according to declarative rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Ingress vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from Ingress<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Load Balancer<\/td>\n<td>Routes at network or transport layer often without L7 rules<\/td>\n<td>Confused with L7 routing features<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>API Gateway<\/td>\n<td>Focuses on API patterns and developer features<\/td>\n<td>Assumed to be identical to ingress<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>Service Mesh<\/td>\n<td>Handles service-to-service traffic inside cluster<\/td>\n<td>People expect mesh to manage external ingress<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>Edge Router<\/td>\n<td>Operates at perimeter with global policies<\/td>\n<td>Sometimes used interchangeably with ingress<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>Reverse Proxy<\/td>\n<td>Generic proxy that forwards requests<\/td>\n<td>Not always integrated with k8s CRDs<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>WAF<\/td>\n<td>Focused on request inspection and protection<\/td>\n<td>Assumed to be built into all ingress controllers<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>Kubernetes Ingress Resource<\/td>\n<td>Declarative object describing routing rules<\/td>\n<td>People expect the resource to provide runtime features<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>Ingress Controller<\/td>\n<td>The runtime that acts on ingress resources<\/td>\n<td>Confused with the resource itself<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>CDN<\/td>\n<td>Caches and serves content globally<\/td>\n<td>Mistaken as replacement for ingress<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>Network Policy<\/td>\n<td>Controls pod-to-pod network access<\/td>\n<td>Different scope from external routing<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<p>None<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does Ingress matter?<\/h2>\n\n\n\n<p>Business impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Revenue: User-facing outages due to ingress misconfiguration directly block conversions and transactions.<\/li>\n<li>Trust: TLS, correct host mapping, and consistent error handling influence user trust and brand perception.<\/li>\n<li>Risk: A single ingress misroute or vulnerable component can expose many services.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Incident reduction: Proper ingress observability reduces time to detect and remediate routing and TLS issues.<\/li>\n<li>Velocity: Declarative ingress controls allow safe automated deployments and rollback of routes.<\/li>\n<li>Operational complexity: Poor ingress design increases toil for certificate management, DNS adjustments, and scaling.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs\/SLOs: Ingress-related SLIs include request success rate, latency at the edge, TLS handshake success rate, and request routing correctness.<\/li>\n<li>Error budgets: Edge failures often consume error budget quickly; guardrails and canarying are important.<\/li>\n<li>Toil: Manual certificate renewal, ad hoc DNS changes, and undocumented routing rules create toil.<\/li>\n<li>On-call: Ingress incidents are high-severity because they can cause broad service impact; clear runbooks and fast mitigation playbooks are mandatory.<\/li>\n<\/ul>\n\n\n\n<p>Realistic &#8220;what breaks in production&#8221; examples:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>TLS certificate expired because automation failed -&gt; all HTTPS endpoints return TLS errors.<\/li>\n<li>Misconfigured path rule catches traffic meant for an API -&gt; incorrect backend receives and errors.<\/li>\n<li>High client connection rate overwhelms the ingress controller -&gt; timeouts and 502s.<\/li>\n<li>Cloud provider rate-limits control-plane API used for dynamic rule updates -&gt; traffic management changes fail.<\/li>\n<li>WAF rule blocks legitimate traffic after a release -&gt; degraded user access.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is Ingress used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How Ingress appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Edge network<\/td>\n<td>Global LB or edge gateway that terminates user TLS<\/td>\n<td>TLS handshakes timeouts request rates<\/td>\n<td>Cloud LB Edge Gateways<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Cluster\/L7 routing<\/td>\n<td>Ingress controller or API Gateway inside cluster<\/td>\n<td>Request latencies backend status codes<\/td>\n<td>Ingress controllers Gateways<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Serverless\/PaaS<\/td>\n<td>Route mapping in managed platform<\/td>\n<td>Cold start errors routing misses<\/td>\n<td>Platform router managed services<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Service mesh boundary<\/td>\n<td>Gateway that bridges mesh to external traffic<\/td>\n<td>Ingress-to-mesh latencies egress counts<\/td>\n<td>Mesh gateway proxies<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>CI\/CD<\/td>\n<td>Automated route updates during deploys<\/td>\n<td>Deployment-triggered config changes<\/td>\n<td>CI runners\/CD platforms<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>Observability<\/td>\n<td>Instrumentation point for edge metrics and traces<\/td>\n<td>Edge traces error rates TLS metrics<\/td>\n<td>APM tracing and metrics stacks<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>Security<\/td>\n<td>TLS auth WAF and rate limiting<\/td>\n<td>WAF blocks auth failures<\/td>\n<td>WAF and API security tools<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>Multi-cluster<\/td>\n<td>Global ingress aggregator and DNS control<\/td>\n<td>Geo routing errors failover metrics<\/td>\n<td>Global controllers DNS orchestration<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>None<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use Ingress?<\/h2>\n\n\n\n<p>When it\u2019s necessary:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Exposing internal HTTP\/HTTPS services to end users or partner systems.<\/li>\n<li>Centralized TLS termination and certificate management.<\/li>\n<li>Host\/path-based routing or virtual hosting requirements.<\/li>\n<li>Implementing edge policies like rate limits, authentication, and basic WAF.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Simple internal-only services with private endpoints.<\/li>\n<li>Very small environments where a cloud-managed LB per service is acceptable.<\/li>\n<li>When a CDN provides sufficient edge features and origin can be directly addressed.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid using a single ingress instance for all traffic without high availability and autoscaling.<\/li>\n<li>Don\u2019t rely on ingress for fine-grained service-to-service security; use service mesh or mTLS.<\/li>\n<li>Don\u2019t layer complex business logic into ingress routing rules.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you need host\/path-based L7 routing AND centralized TLS -&gt; Use Ingress.<\/li>\n<li>If you require per-service API management features like transformations and auth -&gt; Consider API gateway.<\/li>\n<li>If you need high internal south-north security between services -&gt; Use service mesh for microsegmentation.<\/li>\n<li>If you only need static caching and global CDN features -&gt; CDN-first, with ingress as origin.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Single ingress controller terminating TLS with static routes. Manual certificate updates.<\/li>\n<li>Intermediate: Automated cert management, canary releases for routes, basic rate limiting, integrated observability.<\/li>\n<li>Advanced: Multi-cluster\/global ingress orchestration, policy-as-code, runtime WAF, automated traffic shaping, integrated SLO enforcement.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does Ingress work?<\/h2>\n\n\n\n<p>Components and workflow:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>DNS maps a hostname to an edge IP or CDN.<\/li>\n<li>Client sends request to that hostname; edge gateway receives it.<\/li>\n<li>TLS may be terminated at edge; request headers are inspected for host\/path.<\/li>\n<li>Ingress controller consults routing rules and selects backend service.<\/li>\n<li>Request is proxied to service endpoint; load balancing and health checks apply.<\/li>\n<li>Response flows back through ingress; observability signals and metrics emitted.<\/li>\n<\/ol>\n\n\n\n<p>Data flow and lifecycle:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Design time: Define routing rules, TLS secrets, and policies.<\/li>\n<li>Deployment time: Controller picks up config, updates runtime routes.<\/li>\n<li>Runtime: Controller handles incoming connections, enforces limits, and monitors health.<\/li>\n<li>Change time: CI\/CD or API updates ingress rules; controller reconciles new state.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Split brain when controller config differs across replicas.<\/li>\n<li>Stale DNS causing traffic to old ingress IPs after scaling or migration.<\/li>\n<li>Misrouted host headers leading to wrong backend.<\/li>\n<li>Partial failure when backend health deteriorates and circuit-breakers don&#8217;t trigger.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for Ingress<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Single shared ingress controller\n   &#8211; Use when: Small cluster and few apps.\n   &#8211; Pros: Simple, low overhead.\n   &#8211; Cons: Blast radius on misconfig.<\/p>\n<\/li>\n<li>\n<p>Per-team or per-namespace ingress controllers\n   &#8211; Use when: Strong team autonomy and isolation needed.\n   &#8211; Pros: Limits blast radius, different policies per team.\n   &#8211; Cons: More management and resources.<\/p>\n<\/li>\n<li>\n<p>Edge CDN + origin ingress\n   &#8211; Use when: Static assets need caching and dynamic app requires routing.\n   &#8211; Pros: Offloads traffic and improves latency.\n   &#8211; Cons: Cache invalidation and origin complexity.<\/p>\n<\/li>\n<li>\n<p>API gateway in front of ingress\n   &#8211; Use when: Developer API management and complex auth required.\n   &#8211; Pros: Rich API features, analytics.\n   &#8211; Cons: Added latency and cost.<\/p>\n<\/li>\n<li>\n<p>Mesh gateway + ingress\n   &#8211; Use when: Internal mesh policies and external exposure needed.\n   &#8211; Pros: Unified security posture across boundary.\n   &#8211; Cons: Operational complexity and learning curve.<\/p>\n<\/li>\n<li>\n<p>Global ingress with multi-cluster failover\n   &#8211; Use when: High availability across regions is required.\n   &#8211; Pros: Geo failover and traffic steering.\n   &#8211; Cons: Complex DNS and consistency challenges.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>TLS expiry<\/td>\n<td>HTTPS errors in browser<\/td>\n<td>Expired cert<\/td>\n<td>Automate cert rotation<\/td>\n<td>TLS handshake failures<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>Misroute<\/td>\n<td>Wrong backend serves response<\/td>\n<td>Bad host\/path rule<\/td>\n<td>Validate rules in CI<\/td>\n<td>Increased 404 and anomalies<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Overload<\/td>\n<td>Timeouts 502s and 504s<\/td>\n<td>Insufficient ingress capacity<\/td>\n<td>Autoscale and rate limit<\/td>\n<td>Queue depth errors<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Controller crash<\/td>\n<td>No new connections accepted<\/td>\n<td>Bug or OOM<\/td>\n<td>Ensure HA controller set<\/td>\n<td>Controller crash logs<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>DNS stale<\/td>\n<td>Clients hit old IP<\/td>\n<td>DNS TTL not updated<\/td>\n<td>Lower TTL and orchestration<\/td>\n<td>DNS mismatch metrics<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>WAF false positive<\/td>\n<td>Legit requests blocked<\/td>\n<td>Overly strict rules<\/td>\n<td>Tune rules and whitelist<\/td>\n<td>Spikes in WAF blocks<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>Config drift<\/td>\n<td>Different behavior across zones<\/td>\n<td>Unsynced configs<\/td>\n<td>Centralize policy and reconcile<\/td>\n<td>Config version differences<\/td>\n<\/tr>\n<tr>\n<td>F8<\/td>\n<td>Health check flapping<\/td>\n<td>Frequent backend routing changes<\/td>\n<td>Misconfigured probes<\/td>\n<td>Stabilize probes and thresholds<\/td>\n<td>Rapid health events<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>None<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for Ingress<\/h2>\n\n\n\n<p>Below is a glossary of 40+ key terms. Each entry: term \u2014 definition \u2014 why it matters \u2014 common pitfall.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Ingress \u2014 Entry-layer routing mechanism for external requests \u2014 Core to exposing services \u2014 Mistaking resource for controller.<\/li>\n<li>Ingress Controller \u2014 Runtime that enforces ingress rules \u2014 Implements behavior \u2014 Treating resource as runtime.<\/li>\n<li>Load Balancer \u2014 Distributes traffic across endpoints \u2014 Scalability and HA \u2014 Assuming L7 features available.<\/li>\n<li>Edge Gateway \u2014 Perimeter device for traffic control \u2014 Security and routing \u2014 Overloading with internal policies.<\/li>\n<li>Reverse Proxy \u2014 Forwards client requests to servers \u2014 Central for TLS termination \u2014 Becoming a bottleneck.<\/li>\n<li>API Gateway \u2014 Manages APIs with features like auth \u2014 Developer gateway role \u2014 Adding latency for simple routes.<\/li>\n<li>TLS Termination \u2014 Decrypts HTTPS at edge \u2014 Simplifies backend certs \u2014 Misplaced trust boundaries.<\/li>\n<li>TLS Passthrough \u2014 Forwards encrypted traffic to backend \u2014 Backend terminates TLS \u2014 Complex for routing rules.<\/li>\n<li>Host-based routing \u2014 Routes by hostname \u2014 Virtual hosting \u2014 Missing host header rewrite.<\/li>\n<li>Path-based routing \u2014 Routes by URL path \u2014 Useful for microfrontends \u2014 Overly greedy path rules.<\/li>\n<li>SNI \u2014 Server Name Indication used in TLS \u2014 Enables multi-tenant TLS \u2014 Ignored causing wrong cert.<\/li>\n<li>Certificate Manager \u2014 Automates cert lifecycle \u2014 Reduces expiry risk \u2014 Misconfiguration of issuers.<\/li>\n<li>ACME \u2014 Protocol to issue certs (e.g., Let&#8217;s Encrypt) \u2014 Automation for public certs \u2014 Rate limits in staging.<\/li>\n<li>WAF \u2014 Web Application Firewall for request inspection \u2014 Blocks attacks \u2014 False positives blocking legit traffic.<\/li>\n<li>Rate Limiting \u2014 Throttles requests per client \u2014 Protects backends \u2014 Too strict impacting users.<\/li>\n<li>Circuit Breaker \u2014 Isolates failing backends \u2014 Prevents cascading failures \u2014 Too aggressive tripping.<\/li>\n<li>Health Check \u2014 Determines backend health \u2014 Ensures correct routing \u2014 Flaky checks cause churn.<\/li>\n<li>Canary Release \u2014 Gradual traffic rollout \u2014 Risk reduction during deploys \u2014 Poor metrics can hide issues.<\/li>\n<li>Blue\/Green \u2014 Two parallel environments for zero-downtime deploys \u2014 Fast rollback \u2014 Costly duplicate resources.<\/li>\n<li>Retry Policy \u2014 Retries failed requests \u2014 Improves resilience \u2014 May increase load on failing systems.<\/li>\n<li>Timeout \u2014 Limits request duration \u2014 Protects services \u2014 Too aggressive cuts valid requests.<\/li>\n<li>Circuit Breaker \u2014 Duplicate for emphasis \u2014 Important to avoid overload \u2014 Mis-tuned thresholds.<\/li>\n<li>Observability \u2014 Telemetry, logs, traces for ingress \u2014 Essential for troubleshooting \u2014 Sparse instrumentation.<\/li>\n<li>SLI \u2014 Service level indicator \u2014 Measure for SLOs \u2014 Measuring wrong signals.<\/li>\n<li>SLO \u2014 Service level objective \u2014 Targets for reliability \u2014 Unrealistic or missing SLOs.<\/li>\n<li>Error Budget \u2014 Allowance for failures \u2014 Guides releases \u2014 Burned by ingress-wide outages.<\/li>\n<li>DNS \u2014 Domain Name System mapping \u2014 Traffic steering via record changes \u2014 Long TTLs cause delay.<\/li>\n<li>Anycast \u2014 Network routing to nearest POP \u2014 Low latency global routing \u2014 Complexity in origin behavior.<\/li>\n<li>CDN \u2014 Content Delivery Network caches content \u2014 Reduces origin load \u2014 Cache coherency challenges.<\/li>\n<li>Mesh Gateway \u2014 Bridge between mesh and external traffic \u2014 Unified security \u2014 Requires mesh-compatible ingress.<\/li>\n<li>Service Account \u2014 Identity used by ingress controller \u2014 IAM for cloud integration \u2014 Overprivileged accounts.<\/li>\n<li>RBAC \u2014 Role-based access control for ingress config \u2014 Governance \u2014 Overly restrictive causing deploy fails.<\/li>\n<li>Annotation \u2014 Implementation-specific settings in k8s ingress \u2014 Provides extra features \u2014 Portability issues.<\/li>\n<li>CRD \u2014 Custom Resource Definition used by modern controllers \u2014 Rich config model \u2014 Controller-specific.<\/li>\n<li>Egress \u2014 Outbound traffic control \u2014 Complement to ingress \u2014 Confused with ingress scope.<\/li>\n<li>HostRewrite \u2014 Header modification for backend compatibility \u2014 Needed for legacy apps \u2014 Breaks authentication.<\/li>\n<li>Header Injection \u2014 Adding headers like X-Forwarded-For \u2014 Essential identity propagation \u2014 Leaking sensitive info.<\/li>\n<li>Connection Draining \u2014 Graceful connection handling during changes \u2014 Avoids connection drops \u2014 Misconfigured timeouts.<\/li>\n<li>Backpressure \u2014 Mechanism to slow clients when overloaded \u2014 Protects systems \u2014 Poor user experience if visible.<\/li>\n<li>Circuit Breaker \u2014 Note repeated term \u2014 Relevant across layers \u2014 Repeating causes confusion.<\/li>\n<li>Ambassadors \u2014 Edge proxies that route to clusters \u2014 Useful in multi-cluster \u2014 Adds latency.<\/li>\n<li>Health Probes \u2014 Heartbeat checks for service readiness \u2014 Prevents sending traffic to unhealthy pods \u2014 Too sensitive flapping.<\/li>\n<li>Observability Signal \u2014 Metric, log, trace \u2014 Basis for SLOs \u2014 Mixing up client vs server latencies.<\/li>\n<li>Zero Trust \u2014 Security model that verifies every request \u2014 Ingress is an enforcement point \u2014 Partial implementations create gaps.<\/li>\n<li>Mutual TLS \u2014 mTLS for mutual auth \u2014 Strengthens trust between client and ingress \u2014 Client cert management overhead.<\/li>\n<li>Ingress Class \u2014 Selector for which controller manages an ingress \u2014 Enables multi-controller setups \u2014 Confusion over defaults.<\/li>\n<li>Autoscaling \u2014 Dynamically scaling ingress runtime \u2014 Matches load \u2014 Scale latency and warm-up issues.<\/li>\n<li>Canary Analysis \u2014 Automated comparison of canary vs baseline \u2014 Improves confidence \u2014 Poor metrics cause false success.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure Ingress (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Edge request success rate<\/td>\n<td>% requests that succeed at ingress<\/td>\n<td>1 &#8211; (4xx+5xx \/ total)<\/td>\n<td>99.9%<\/td>\n<td>4xx may be client not server<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Edge p95 latency<\/td>\n<td>User perceived tail latency<\/td>\n<td>95th percentile of request durations<\/td>\n<td>&lt; 300ms<\/td>\n<td>Include network and backend time<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>TLS handshake success<\/td>\n<td>TLS handshake failures ratio<\/td>\n<td>TLS fails \/ TLS attempts<\/td>\n<td>&gt; 99.99%<\/td>\n<td>SNI and cert issues inflate failures<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Route correctness<\/td>\n<td>% requests served by expected backend<\/td>\n<td>Compare expected route vs actual<\/td>\n<td>100% for critical routes<\/td>\n<td>Requires tagging requests<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Connection error rate<\/td>\n<td>TCP\/HTTP connection errors<\/td>\n<td>error connections \/ attempts<\/td>\n<td>&lt; 0.1%<\/td>\n<td>Transient networks can spike<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Ingress CPU usage<\/td>\n<td>Controller resource pressure<\/td>\n<td>CPU usage per replica<\/td>\n<td>Keep below 70%<\/td>\n<td>Spiky bursts need autoscale<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>Ingress memory usage<\/td>\n<td>Controller memory pressure<\/td>\n<td>Memory per replica<\/td>\n<td>Keep headroom 30%<\/td>\n<td>Memory leaks affect stability<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>WAF blocked rate<\/td>\n<td>Valid vs blocked traffic<\/td>\n<td>Blocks \/ total requests<\/td>\n<td>Low but varies<\/td>\n<td>False positives common<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>Rate limit rejections<\/td>\n<td>Clients throttled<\/td>\n<td>Rejections \/ attempts<\/td>\n<td>Track per tier<\/td>\n<td>Aggressive rules create UX issues<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Config apply latency<\/td>\n<td>Time to apply config to runtime<\/td>\n<td>Config change to active time<\/td>\n<td>&lt; 30s<\/td>\n<td>Cloud API limits increase time<\/td>\n<\/tr>\n<tr>\n<td>M11<\/td>\n<td>Health check flaps<\/td>\n<td>Backend healthy\/unhealthy events<\/td>\n<td>Flap count per minute<\/td>\n<td>Minimal<\/td>\n<td>Misconfigured probes spike this<\/td>\n<\/tr>\n<tr>\n<td>M12<\/td>\n<td>Error budget burn rate<\/td>\n<td>Burn rate for ingress SLO<\/td>\n<td>Error budget consumed per period<\/td>\n<td>Monitor alert per policy<\/td>\n<td>Sudden incidents burn quickly<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>None<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure Ingress<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Prometheus<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Ingress: Metrics from ingress controller, LB, proxy stats.<\/li>\n<li>Best-fit environment: Kubernetes and cloud-native stacks.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable metrics endpoint on controller.<\/li>\n<li>Configure scrape jobs and relabeling.<\/li>\n<li>Create recording rules for SLIs.<\/li>\n<li>Configure alerting rules for error budgets.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible query language and ecosystem.<\/li>\n<li>Widely supported by controllers.<\/li>\n<li>Limitations:<\/li>\n<li>Storage retention and cardinality management needed.<\/li>\n<li>Query complexity at scale.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Grafana<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Ingress: Visualization of metrics and SLIs.<\/li>\n<li>Best-fit environment: Any environment with metrics.<\/li>\n<li>Setup outline:<\/li>\n<li>Connect to Prometheus or metrics source.<\/li>\n<li>Build dashboards for edge, on-call, executive.<\/li>\n<li>Configure alerting endpoints.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible dashboards and plugins.<\/li>\n<li>Alert manager integration.<\/li>\n<li>Limitations:<\/li>\n<li>Dashboard maintenance overhead.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 OpenTelemetry \/ Jaeger<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Ingress: Traces across ingress to backend.<\/li>\n<li>Best-fit environment: Distributed systems, microservices.<\/li>\n<li>Setup outline:<\/li>\n<li>Instrument controllers and services.<\/li>\n<li>Configure collectors and exporters.<\/li>\n<li>Define sampling and context propagation.<\/li>\n<li>Strengths:<\/li>\n<li>End-to-end tracing and latency breakdowns.<\/li>\n<li>Limitations:<\/li>\n<li>Sampling and storage costs.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Cloud Provider Monitoring (Varies)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Ingress: Managed LB and gateway metrics.<\/li>\n<li>Best-fit environment: Managed cloud services.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable provider monitoring.<\/li>\n<li>Link metrics to dashboards.<\/li>\n<li>Combine with application telemetry.<\/li>\n<li>Strengths:<\/li>\n<li>Direct provider integration.<\/li>\n<li>Limitations:<\/li>\n<li>Metric names and semantics vary.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Synthetic Monitoring (SaaS)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Ingress: Availability and journey checks from client perspective.<\/li>\n<li>Best-fit environment: Public-facing services.<\/li>\n<li>Setup outline:<\/li>\n<li>Define HTTP checks for endpoints.<\/li>\n<li>Schedule global probes and thresholds.<\/li>\n<li>Integrate alerts for failures.<\/li>\n<li>Strengths:<\/li>\n<li>Real-user perspective.<\/li>\n<li>Limitations:<\/li>\n<li>Probe coverage and cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for Ingress<\/h3>\n\n\n\n<p>Executive dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Overall edge request success rate (rolling 24h) \u2014 business health.<\/li>\n<li>Global request volume by region \u2014 traffic trends.<\/li>\n<li>Error budget burn rate \u2014 risk exposure.<\/li>\n<li>TLS cert expiry calendar \u2014 compliance.<\/li>\n<li>Why:<\/li>\n<li>For product and leadership view on availability and business impact.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Live request rate and error rate by backend \u2014 incident triage.<\/li>\n<li>Ingress controller pod health and resource usage \u2014 runtime health.<\/li>\n<li>Recent config changes and apply latency \u2014 suspect config causes.<\/li>\n<li>Top 10 routes by error rate \u2014 focused debugging.<\/li>\n<li>Why:<\/li>\n<li>Fast identification and mitigation during incidents.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Per-path latency histograms and traces \u2014 root cause latency.<\/li>\n<li>TLS handshake vs total latency breakdown \u2014 handshake issues.<\/li>\n<li>WAF block logs and sampled requests \u2014 analyze false positives.<\/li>\n<li>DNS resolution times and cached vs origin hits \u2014 DNS issues.<\/li>\n<li>Why:<\/li>\n<li>Deep dive troubleshooting and forensics.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What should page vs ticket:<\/li>\n<li>Page: Ingress-wide outage, TLS expiry less than 24 hours, sudden 10x error rate increase, controller crash.<\/li>\n<li>Ticket: Gradual increases in latency, config drift with non-critical impact.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>If error budget burn rate &gt; 5x for 1 hour, page and runbook.<\/li>\n<li>If &gt; 10x, trigger incident response and consider rollback.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Deduplicate alerts by route and region.<\/li>\n<li>Group alerts by controller instance and route owner.<\/li>\n<li>Suppression windows during known deployments.<\/li>\n<li>Use alert severity tiers and escalation policies.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; DNS control and ability to update records.\n&#8211; TLS certificate issuer (automated preferred).\n&#8211; CI\/CD pipeline with permissions to update ingress config.\n&#8211; Observability stack for metrics, logs, traces.\n&#8211; RBAC and identity for controller.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Export ingress controller metrics.\n&#8211; Add request-id propagation and correlate with traces.\n&#8211; Emit TLS and routing events.\n&#8211; Add health checks and readiness probes.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Centralize metrics to Prometheus or cloud metrics.\n&#8211; Forward ingress logs to centralized log store.\n&#8211; Collect traces with OpenTelemetry.\n&#8211; Collect WAF logs and rate-limit events.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLIs: edge success rate, latency p95, TLS success.\n&#8211; Set SLOs per customer-impacting service class.\n&#8211; Allocate error budgets and policy for automated rollout.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Build executive, on-call, debug dashboards.\n&#8211; Populate with SLIs and derived indicators.\n&#8211; Validate dashboards with synthetic tests.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Define alerts for SLOs and infra signals.\n&#8211; Configure escalation and contact routing by ownership.\n&#8211; Add automatic routing to rollback or circuit-breakers.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for common ingress incidents.\n&#8211; Automate certificate rotation, canary deployment of rules.\n&#8211; Script DNS failover and health check remediation.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Run synthetic tests for all routes.\n&#8211; Perform controlled chaos on ingress replicas and LB.\n&#8211; Execute game days for certificate expiry scenarios.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Postmortem after incidents with ownership.\n&#8211; Regular review of WAF rules and rate limits.\n&#8211; Track toil and automate recurring manual steps.<\/p>\n\n\n\n<p>Checklists<\/p>\n\n\n\n<p>Pre-production checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DNS entries created and TTL verified.<\/li>\n<li>TLS certs provisioned and auto-rotation tested.<\/li>\n<li>Health checks validated on backends.<\/li>\n<li>Observability hooks enabled for ingress.<\/li>\n<li>RBAC configured for deployments.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Autoscaling rules defined and tested.<\/li>\n<li>HA ingress controller with multi-zone replicas.<\/li>\n<li>Canary and rollback pipelines ready.<\/li>\n<li>Alerting for SLO violations configured.<\/li>\n<li>Chaos test passed in staging.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to Ingress:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Validate DNS resolution and IP assignment.<\/li>\n<li>Check TLS certificate validity and SNI mapping.<\/li>\n<li>Inspect controller logs and resource usage.<\/li>\n<li>Verify backend health and probe results.<\/li>\n<li>Rollback recent ingress config changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of Ingress<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Public website hosting\n&#8211; Context: Web app needs host-based routing.\n&#8211; Problem: Centralized TLS and multiple domains.\n&#8211; Why Ingress helps: Host routing and centralized certs reduce complexity.\n&#8211; What to measure: TLS success rate, p95 latency, error rate.\n&#8211; Typical tools: Ingress controller, cert manager, CDN.<\/p>\n<\/li>\n<li>\n<p>Multi-tenant SaaS platform\n&#8211; Context: Many customer hostnames and route rules.\n&#8211; Problem: Scalable routing, cert per customer.\n&#8211; Why Ingress helps: SNI and dynamic cert issuance at edge.\n&#8211; What to measure: Route correctness, cert issuance latency.\n&#8211; Typical tools: Controller with ACME integration, automation.<\/p>\n<\/li>\n<li>\n<p>API exposure for mobile clients\n&#8211; Context: API endpoints need auth, rate limits.\n&#8211; Problem: Protect against abuse and manage quotas.\n&#8211; Why Ingress helps: Rate limiting, auth hooks at edge.\n&#8211; What to measure: Rate limit rejections, authentication failures.\n&#8211; Typical tools: API gateway in front of ingress or advanced ingress.<\/p>\n<\/li>\n<li>\n<p>Canary deployments for critical services\n&#8211; Context: Need safe rollouts for routing changes.\n&#8211; Problem: Risk of breaking user flows.\n&#8211; Why Ingress helps: Gradual traffic shifting and observability at edge.\n&#8211; What to measure: Canary error rate vs baseline.\n&#8211; Typical tools: Ingress with canary annotations and monitoring.<\/p>\n<\/li>\n<li>\n<p>Multi-region failover\n&#8211; Context: Global user base requiring low latency.\n&#8211; Problem: Failover and traffic steering across regions.\n&#8211; Why Ingress helps: Global ingress plus DNS steering.\n&#8211; What to measure: Geo latency, failover success.\n&#8211; Typical tools: Global load balancer, multi-cluster ingress.<\/p>\n<\/li>\n<li>\n<p>Serverless front door\n&#8211; Context: Mix of serverless and containers.\n&#8211; Problem: Unified entry point without exposing raw functions.\n&#8211; Why Ingress helps: Routes to serverless endpoints and services.\n&#8211; What to measure: Cold start errors and routing success.\n&#8211; Typical tools: Platform router with ingress-like rules.<\/p>\n<\/li>\n<li>\n<p>Internal admin console access\n&#8211; Context: Sensitive admin UI accessible externally.\n&#8211; Problem: Secure access and authentication enforcement.\n&#8211; Why Ingress helps: Central auth and TLS at edge plus ACLs.\n&#8211; What to measure: Auth failures and access patterns.\n&#8211; Typical tools: Ingress with auth proxy and WAF.<\/p>\n<\/li>\n<li>\n<p>IoT device ingestion\n&#8211; Context: High-concurrency small requests.\n&#8211; Problem: Throttling and path routing for devices.\n&#8211; Why Ingress helps: Rate limiting and connection management.\n&#8211; What to measure: Connection error rate and throughput.\n&#8211; Typical tools: Scalable ingress with connection pooling.<\/p>\n<\/li>\n<li>\n<p>B2B partner APIs\n&#8211; Context: Partner systems integrate with APIs.\n&#8211; Problem: Authentication, IP allowlist, and SLA enforcement.\n&#8211; Why Ingress helps: Enforces partner-specific policies at edge.\n&#8211; What to measure: Auth success and SLA compliance.\n&#8211; Typical tools: Ingress with RBAC and IP filter modules.<\/p>\n<\/li>\n<li>\n<p>Blue\/Green deploys of monoliths\n&#8211; Context: Large monolith needing zero downtime release.\n&#8211; Problem: Seamless cutover between versions.\n&#8211; Why Ingress helps: Switch routes atomically and handle traffic shift.\n&#8211; What to measure: Error spikes during cutover.\n&#8211; Typical tools: Controller with weighted routing capabilities.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes: Multi-tenant ingress with automated certs<\/h3>\n\n\n\n<p><strong>Context:<\/strong> SaaS platform hosts app for multiple tenants in a k8s cluster.<br\/>\n<strong>Goal:<\/strong> Provide per-tenant custom domains with automated TLS provisioning and isolation.<br\/>\n<strong>Why Ingress matters here:<\/strong> Centralizes domain routing and TLS while integrating with k8s lifecycle.<br\/>\n<strong>Architecture \/ workflow:<\/strong> DNS -&gt; External LB -&gt; Ingress controller (per-namespace) -&gt; Backend services -&gt; Cert manager via ACME.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create IngressClass per controller and namespace.<\/li>\n<li>Configure cert-manager with ACME issuer.<\/li>\n<li>Add DNS automation to create records when Ingress resource is created.<\/li>\n<li>Add annotations for canary and rewrite rules.<\/li>\n<li>Implement RBAC for tenants to own their ingress resources.\n<strong>What to measure:<\/strong> Cert issuance success, route correctness, request latency, error budget.<br\/>\n<strong>Tools to use and why:<\/strong> Kubernetes ingress controller, cert-manager, Prometheus, Grafana.<br\/>\n<strong>Common pitfalls:<\/strong> Rate limits on ACME issuer, DNS TTL delay, misconfigured host rewrites.<br\/>\n<strong>Validation:<\/strong> Create test tenant, issue cert, probe endpoints, run load test.<br\/>\n<strong>Outcome:<\/strong> Automated per-tenant routing with minimal manual intervention.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless\/PaaS: Managed platform route gating<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A managed PaaS hosts serverless functions and containerized apps.<br\/>\n<strong>Goal:<\/strong> Unified ingress for both serverless and container origins, with auth and throttling.<br\/>\n<strong>Why Ingress matters here:<\/strong> Simplifies client routing and enforces platform-wide policies.<br\/>\n<strong>Architecture \/ workflow:<\/strong> CDN -&gt; Edge Gateway -&gt; Service router -&gt; Serverless functions \/ container services.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Configure platform router with upstream targets.<\/li>\n<li>Implement auth hook in ingress for token validation.<\/li>\n<li>Setup rate limiting tiers and quotas.<\/li>\n<li>Integrate metrics for cold start and routing latency.\n<strong>What to measure:<\/strong> Cold start rates, auth failures, throttled requests.<br\/>\n<strong>Tools to use and why:<\/strong> Managed platform router, WAF, metrics service.<br\/>\n<strong>Common pitfalls:<\/strong> Auth token propagation and inconsistent header handling.<br\/>\n<strong>Validation:<\/strong> Simulate spike in traffic, check throttling and auth flows.<br\/>\n<strong>Outcome:<\/strong> Unified front door with platform policy enforcement.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response &amp; postmortem: TLS expiry incident<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Production outage occurred due to expired certificate at edge.<br\/>\n<strong>Goal:<\/strong> Restore service quickly and prevent recurrence.<br\/>\n<strong>Why Ingress matters here:<\/strong> TLS is fundamental for service reachability.<br\/>\n<strong>Architecture \/ workflow:<\/strong> External DNS -&gt; Edge LB -&gt; Ingress -&gt; Backends.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Emergency: Replace cert and restart ingress pods if needed.<\/li>\n<li>Validate via synthetic checks and user verification.<\/li>\n<li>Runbook: Check automation logs for cert-manager and ACME issuer.<\/li>\n<li>Postmortem: Root cause analyze automation failure and reviewer signoffs.<\/li>\n<li>Fix: Add alert for cert expiry and test ACME renewal flow.\n<strong>What to measure:<\/strong> Time-to-recover, cert issuance latency, number of impacted endpoints.<br\/>\n<strong>Tools to use and why:<\/strong> Monitoring, cert manager logs, incident tracker.<br\/>\n<strong>Common pitfalls:<\/strong> Not testing renewal in staging, missing alert thresholds.<br\/>\n<strong>Validation:<\/strong> Simulate expiry in staging, verify alerts and automated rotation.<br\/>\n<strong>Outcome:<\/strong> New certs deployed and automation fixed.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost\/performance trade-off: CDN vs dynamic ingress<\/h3>\n\n\n\n<p><strong>Context:<\/strong> High bandwidth static assets and dynamic APIs causing costs.<br\/>\n<strong>Goal:<\/strong> Move static content to CDN while keeping dynamic routing through ingress.<br\/>\n<strong>Why Ingress matters here:<\/strong> Acts as origin and fallback for dynamic requests.<br\/>\n<strong>Architecture \/ workflow:<\/strong> CDN -&gt; Cache -&gt; Origin Ingress -&gt; Services.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Identify cacheable assets and set cache-control headers.<\/li>\n<li>Configure CDN to cache static paths and set TTLs.<\/li>\n<li>Update ingress to serve origin for uncached content and API.<\/li>\n<li>Monitor origin traffic reduction and latency changes.\n<strong>What to measure:<\/strong> Origin traffic volume, cache hit ratio, user latency.<br\/>\n<strong>Tools to use and why:<\/strong> CDN analytics, ingress metrics, synthetic tests.<br\/>\n<strong>Common pitfalls:<\/strong> Overly aggressive caching breaking dynamic content.<br\/>\n<strong>Validation:<\/strong> A\/B test and watch cache hit ratios and errors.<br\/>\n<strong>Outcome:<\/strong> Reduced origin load and improved performance with cost savings.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: Whole site down after deploy -&gt; Root cause: Bad ingress rule applied -&gt; Fix: Rollback config and validate rules in CI.<\/li>\n<li>Symptom: TLS errors for many users -&gt; Root cause: Expired cert -&gt; Fix: Renew certs, add expiry alerts and automation.<\/li>\n<li>Symptom: High 502s -&gt; Root cause: Backend health probe misconfigured -&gt; Fix: Correct probe path and thresholds.<\/li>\n<li>Symptom: Slow requests for specific routes -&gt; Root cause: Wrong host header rewrites -&gt; Fix: Add proper header rewrite rules.<\/li>\n<li>Symptom: Frequent WAF blocks -&gt; Root cause: Too-strict WAF policies -&gt; Fix: Tune rules and add whitelist for legitimate patterns.<\/li>\n<li>Symptom: Autoscale not triggering -&gt; Root cause: Missing metrics or wrong HPA target -&gt; Fix: Expose correct metrics and tune HPA.<\/li>\n<li>Symptom: DNS pointing to old IP -&gt; Root cause: High TTL -&gt; Fix: Lower TTL and coordinate cutover.<\/li>\n<li>Symptom: Rate limits causing user complaints -&gt; Root cause: Global throttle too aggressive -&gt; Fix: Differentiate tiers and increase limits.<\/li>\n<li>Symptom: Controller OOM -&gt; Root cause: Memory leak or insufficient limits -&gt; Fix: Increase limits and investigate leak.<\/li>\n<li>Symptom: Config apply slow -&gt; Root cause: Cloud API rate limits -&gt; Fix: Batch changes and implement backoff.<\/li>\n<li>Symptom: Observability gaps -&gt; Root cause: No request-id propagation -&gt; Fix: Add tracing headers and correlate logs.<\/li>\n<li>Symptom: Canary appears healthy but users report issues -&gt; Root cause: Insufficient canary traffic or metrics -&gt; Fix: Increase sampling and add user-journey checks.<\/li>\n<li>Symptom: Multi-cluster inconsistency -&gt; Root cause: Drift between configs -&gt; Fix: Centralized gitops and reconciliation.<\/li>\n<li>Symptom: Excessive cost from many LBs -&gt; Root cause: Per-service LBs instead of shared ingress -&gt; Fix: Consolidate using ingress or API gateway.<\/li>\n<li>Symptom: SSL SNI mismatch -&gt; Root cause: Incorrect SNI configuration -&gt; Fix: Correct host-to-cert mapping.<\/li>\n<li>Symptom: 404 on internal admin UI -&gt; Root cause: Path-based rule shadowing -&gt; Fix: Adjust path order and specificity.<\/li>\n<li>Symptom: High latency during release -&gt; Root cause: Ingress redeploy and cold caches -&gt; Fix: Use rolling updates and connection draining.<\/li>\n<li>Symptom: Missing geo routing -&gt; Root cause: DNS not configured for geo policies -&gt; Fix: Configure geo-aware DNS and health checks.<\/li>\n<li>Symptom: Alerts storm during deployment -&gt; Root cause: Not suppressing alerts during known deploys -&gt; Fix: Suppression windows and dedupe.<\/li>\n<li>Symptom: Incorrect client IP in logs -&gt; Root cause: Missing X-Forwarded-For or proxy header -&gt; Fix: Ensure header propagation at ingress.<\/li>\n<li>Symptom: Observability pitfall: conflating client latency and backend latency -&gt; Root cause: No trace context -&gt; Fix: Add tracing and break down latencies.<\/li>\n<li>Symptom: Observability pitfall: high cardinality metrics from dynamic hostnames -&gt; Root cause: Custom host label use in metrics -&gt; Fix: Normalize or aggregate hosts.<\/li>\n<li>Symptom: Observability pitfall: missing TLS handshake metrics -&gt; Root cause: Metrics not enabled -&gt; Fix: Enable TLS metrics on controller.<\/li>\n<li>Symptom: Observability pitfall: relying only on logs -&gt; Root cause: Lack of SLIs -&gt; Fix: Define SLIs and dashboards.<\/li>\n<li>Symptom: Admins having too many ingress controllers -&gt; Root cause: No governance -&gt; Fix: Define ownership and standard patterns.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ingress team or platform team should own controllers, cert automation, and global policies.<\/li>\n<li>App teams own their ingress resources and route correctness.<\/li>\n<li>Shared on-call rotation for controller runtime and app on-call for backend issues.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbooks: Step-by-step actions for known failures (TLS expiry, controller crash).<\/li>\n<li>Playbooks: High-level decision trees for complex incidents (multi-region failover).<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use canary or weighted routing for new ingress rules.<\/li>\n<li>Use automated rollbacks based on SLOs and health signals.<\/li>\n<li>Connection draining during pod terminate to avoid abrupt disconnections.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Automate certificate lifecycle, DNS updates, and health check tuning.<\/li>\n<li>Use policy-as-code to enforce best practices in CI\/CD.<\/li>\n<li>Automate remediation for common incidents like unhealthy pods.<\/li>\n<\/ul>\n\n\n\n<p>Security basics:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Terminate TLS at edge with strict ciphers.<\/li>\n<li>Use WAF for common threats, but tune to avoid false positives.<\/li>\n<li>Employ RBAC and least privilege for ingress management.<\/li>\n<li>Enforce header hygiene and limit sensitive header propagation.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review high-error routes, update WAF rules, check certificate expiries.<\/li>\n<li>Monthly: Load test critical routes, review SLOs, audit RBAC for ingress resources.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems related to Ingress:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Was ingress the primary failure point?<\/li>\n<li>Were telemetry and alarms sufficient to detect and diagnose the issue?<\/li>\n<li>Was the runbook followed and effective?<\/li>\n<li>What automation failed and why?<\/li>\n<li>Actions to reduce toil and prevent recurrence.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for Ingress (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>Ingress Controller<\/td>\n<td>Implements routing rules at cluster edge<\/td>\n<td>DNS cert manager observability<\/td>\n<td>Many controller choices exist<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Certificate Manager<\/td>\n<td>Automates TLS lifecycle<\/td>\n<td>ACME DNS providers ingress<\/td>\n<td>Rate limits require handling<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>WAF<\/td>\n<td>Inspects and blocks malicious requests<\/td>\n<td>CDN ingress logging<\/td>\n<td>Tune to avoid false positives<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>CDN<\/td>\n<td>Caches and accelerates content globally<\/td>\n<td>Origin ingress DNS<\/td>\n<td>Reduces origin cost and latency<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>API Gateway<\/td>\n<td>API management and auth<\/td>\n<td>OIDC backends ingress<\/td>\n<td>Adds policy features and overhead<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>Service Mesh Gateway<\/td>\n<td>Bridges mesh and external traffic<\/td>\n<td>Mesh control plane ingress<\/td>\n<td>Tight mesh integration needed<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Observability<\/td>\n<td>Metrics logs traces for ingress<\/td>\n<td>Prometheus Grafana tracing<\/td>\n<td>Essential for SLOs<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>DNS Provider<\/td>\n<td>Maps hostnames to ingress endpoints<\/td>\n<td>Automation CI\/CD monitoring<\/td>\n<td>TTL influences cutovers<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>CI\/CD<\/td>\n<td>Automates config deployments<\/td>\n<td>GitOps ingress controller<\/td>\n<td>Rollback and canary support<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Load Tester<\/td>\n<td>Simulates traffic patterns<\/td>\n<td>Observability ingress<\/td>\n<td>Validates capacity and throttles<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>None<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between Ingress and an API Gateway?<\/h3>\n\n\n\n<p>Ingress focuses on routing and basic L7 features; an API gateway provides richer API management like transformations and developer features.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can Ingress handle authentication?<\/h3>\n\n\n\n<p>Yes; many ingress controllers support auth hooks or integrate with external auth providers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Where should TLS be terminated?<\/h3>\n\n\n\n<p>At the edge for simplicity and performance, but passthrough can be used when end-to-end encryption is required.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you manage certificates at scale?<\/h3>\n\n\n\n<p>Automate with a certificate manager and ACME protocol and add monitoring for expiry.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should every service get its own load balancer?<\/h3>\n\n\n\n<p>Not necessary; use ingress or shared gateways to avoid per-service LB cost and complexity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you perform safe routing changes?<\/h3>\n\n\n\n<p>Use canary or weighted routing and monitor SLIs before scaling traffic.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What are common ingress performance bottlenecks?<\/h3>\n\n\n\n<p>CPU-bound TLS termination, queueing on proxy, slow backend responses, and insufficient autoscaling.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to debug misrouted traffic?<\/h3>\n\n\n\n<p>Check host and path rules, ingress annotations, and request headers; correlate with controller logs and traces.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is ingress a security boundary?<\/h3>\n\n\n\n<p>Partially; it enforces perimeter controls but should be complemented with internal security controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to handle multi-cluster ingress?<\/h3>\n\n\n\n<p>Use a global control plane and DNS steering for failover or a federated ingress control.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What telemetry is essential at ingress?<\/h3>\n\n\n\n<p>Request rates, error rates, latency percentiles, TLS success rates, and resource utilization.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to reduce alert noise during deploys?<\/h3>\n\n\n\n<p>Use suppression windows, grouped alerts, and route-based alerting thresholds.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can ingress do rate limiting by user?<\/h3>\n\n\n\n<p>Yes, with many controllers and gateways offering client- or token-based rate limiting.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to avoid WAF false positives?<\/h3>\n\n\n\n<p>Run WAF in detection mode, collect data, then incrementally enforce rules with whitelists.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is Ingress Class in Kubernetes?<\/h3>\n\n\n\n<p>Selector to bind ingress resources to the controlling controller; prevents conflicts in multi-controller setups.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to test ingress changes safely?<\/h3>\n\n\n\n<p>Use staging with production-like traffic, run synthetic tests, and canary in production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to measure ingress SLOs?<\/h3>\n\n\n\n<p>Define SLIs like edge success rate and p95 latency, then set SLOs based on business impact.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Who should own ingress?<\/h3>\n\n\n\n<p>A platform or ingress team for runtime; app teams for route definitions. Shared on-call responsibilities required.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Ingress is a foundational platform component that controls how traffic enters your systems, enforces key security and routing policies, and serves as a central observability and SLO enforcement point. Proper design, automation, and ownership reduce risk and increase delivery velocity.<\/p>\n\n\n\n<p>Next 7 days plan:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory current ingress endpoints, certs, and DNS TTLs.<\/li>\n<li>Day 2: Ensure basic observability for ingress metrics and logs.<\/li>\n<li>Day 3: Automate certificate renewal and add expiry alerts.<\/li>\n<li>Day 4: Implement CI checks for ingress rules and annotations.<\/li>\n<li>Day 5: Run a canary routing test and validate rollback.<\/li>\n<li>Day 6: Conduct a simulated TLS expiry game day in staging.<\/li>\n<li>Day 7: Draft runbooks for common ingress incidents and assign owners.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 Ingress Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>ingress<\/li>\n<li>ingress controller<\/li>\n<li>k8s ingress<\/li>\n<li>ingress gateway<\/li>\n<li>ingress vs api gateway<\/li>\n<li>edge ingress<\/li>\n<li>ingress TLS termination<\/li>\n<li>ingress routing<\/li>\n<li>ingress best practices<\/li>\n<li>\n<p>ingress security<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>ingress controller metrics<\/li>\n<li>ingress observability<\/li>\n<li>ingress SLO<\/li>\n<li>ingress runbook<\/li>\n<li>ingress autoscale<\/li>\n<li>ingress performance tuning<\/li>\n<li>ingress canary<\/li>\n<li>ingress certificate automation<\/li>\n<li>ingress CI\/CD<\/li>\n<li>\n<p>ingress troubleshooting<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>how to configure ingress in kubernetes<\/li>\n<li>how ingress differs from api gateway<\/li>\n<li>how to automate tls for ingress<\/li>\n<li>how to monitor ingress controller<\/li>\n<li>how to debug misrouted traffic in ingress<\/li>\n<li>how to scale ingress controller<\/li>\n<li>what is ingress class in kubernetes<\/li>\n<li>ingress vs load balancer which to use<\/li>\n<li>how to implement rate limiting at ingress<\/li>\n<li>how to handle cert expiry for ingress<\/li>\n<li>how to perform canary routing with ingress<\/li>\n<li>how to integrate ingress with service mesh<\/li>\n<li>how to set up ingress for serverless apps<\/li>\n<li>how to perform ingress failover across regions<\/li>\n<li>how to secure ingress with WAF<\/li>\n<li>\n<p>how to propagate client IP through ingress<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>load balancer<\/li>\n<li>reverse proxy<\/li>\n<li>api gateway<\/li>\n<li>service mesh<\/li>\n<li>tls termination<\/li>\n<li>sni<\/li>\n<li>cert manager<\/li>\n<li>acme<\/li>\n<li>waf<\/li>\n<li>dns ttl<\/li>\n<li>cdn<\/li>\n<li>canary release<\/li>\n<li>blue green deploy<\/li>\n<li>circuit breaker<\/li>\n<li>rate limiting<\/li>\n<li>health check<\/li>\n<li>observability<\/li>\n<li>slis<\/li>\n<li>slos<\/li>\n<li>error budget<\/li>\n<li>tracing<\/li>\n<li>opentelemetry<\/li>\n<li>prometheus<\/li>\n<li>grafana<\/li>\n<li>rr dns<\/li>\n<li>anycast<\/li>\n<li>mTLS<\/li>\n<li>zero trust<\/li>\n<li>ingress class<\/li>\n<li>annotation<\/li>\n<li>crd<\/li>\n<li>pod probe<\/li>\n<li>readiness probe<\/li>\n<li>connection draining<\/li>\n<li>header rewrite<\/li>\n<li>x-forwarded-for<\/li>\n<li>synthetic monitoring<\/li>\n<li>game day<\/li>\n<li>runbook<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1065","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1065","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1065"}],"version-history":[{"count":0,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1065\/revisions"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}