@raishin/vanguard-frontier-agentic 1.3.0 → 1.5.0

package/skills/kubernetes/kubernetes-live-network-architecture-mutation-guard/references/rollback-patterns.md

@@ -0,0 +1,103 @@
+# Rollback patterns
+
+Every permitted mutation has a documented rollback verb. The agent must surface the rollback verb in the response **before** executing the mutation, not after.
+
+The default rollback strategy across this guard is **`kubectl apply -f <baseline.yaml>`**, never `kubectl delete`. Apply re-establishes the prior state; delete removes the resource entirely (and may cascade-delete children).
+
+---
+
+## Service spec patches
+
+| Mutation | Rollback verb |
+|---|---|
+| `patch internalTrafficPolicy` | `kubectl apply -f /tmp/svc-<name>.before.yaml` |
+| `patch externalTrafficPolicy` | `kubectl apply -f /tmp/svc-<name>.before.yaml` |
+| `annotate topology-mode=Auto` | `kubectl annotate svc <name> -n <ns> service.kubernetes.io/topology-mode-` |
+| `patch trafficDistribution` | `kubectl patch svc <name> -n <ns> --type=json -p='[{"op":"remove","path":"/spec/trafficDistribution"}]'` |
+
+Post-rollback verification: `kubectl get endpointslice -n <ns> -l kubernetes.io/service-name=<name>` should show populated endpoints; `kubectl get svc <name> -n <ns> -o jsonpath='{.spec}'` should match `/tmp/svc-<name>.before.yaml`.
+
+---
+
+## CoreDNS Corefile patch
+
+```bash
+# Rollback
+kubectl apply -f /tmp/coredns.before.yaml
+
+# Force reload by deleting the oldest pod (rolling restart-equivalent;
+# the `reload` plugin will pick up the restored Corefile within 30s, but
+# evicting one pod accelerates recovery)
+kubectl -n kube-system delete pod -l k8s-app=kube-dns --field-selector status.phase=Running --limit=1
+
+# Verify
+kubectl -n kube-system logs -l k8s-app=kube-dns --tail=50 --since=2m | grep -i "reload"
+kubectl -n kube-system get pods -l k8s-app=kube-dns
+```
+
+If the rollback `apply -f` succeeds but a CoreDNS pod is in `CrashLoopBackOff` from a previous bad apply, do not delete the ConfigMap — the cluster may be running on the cached previous Corefile. Diagnose with `kubectl describe pod -n kube-system <coredns-pod>` and surface the error to the operator.
+
+---
+
+## NodeLocal DNSCache install rollback
+
+NodeLocal DNSCache is **not** trivially reversible — uninstalling it during traffic causes every Pod's DNS to fail until kube-proxy / Cilium iptables-redirect rules are also reverted. Treat the install as a maintenance-window-only operation.
+
+```bash
+# Pre-uninstall: confirm the cluster's kube-proxy mode and iptables-redirect rules
+kubectl -n kube-system get cm kube-proxy -o jsonpath='{.data.config\.conf}' | grep -i mode
+
+# Uninstall (drains the redirect rules first because the DaemonSet's preStop hook handles cleanup)
+kubectl delete -f /tmp/nodelocaldns-rendered.yaml --grace-period=60
+
+# Verify pods drained cleanly
+kubectl -n kube-system get pods -l k8s-app=node-local-dns
+# (should return no resources)
+
+# Verify DNS still works post-rollback
+kubectl run --rm -it --restart=Never dns-test --image=busybox:1.36 -- nslookup kubernetes.default
+```
+
+If any Pod's DNS fails immediately after the rollback, the iptables/IPVS redirect rules did not drain. The operator may need to flush conntrack and restart kube-proxy DaemonSet pods (which is itself a kube-system DaemonSet write — outside this guard's scope; refer to platform team).
+
+---
+
+## Gateway API resource rollback
+
+Apply-vs-delete distinction matters here. Routes that were just **created** (no prior state) should be rolled back by deletion of that single resource, not `apply -f`. Routes that were **patched** roll back via `apply -f baseline.yaml`.
+
+```bash
+# Patched resource — roll back to baseline
+kubectl apply -f /tmp/<resource>.before.yaml
+
+# Newly created resource — delete it (the agent is allowed to delete only its own creations)
+# NOTE: this guard's RBAC binding does NOT grant `delete` on Gateway API resources.
+# Newly-created Gateway API resources require operator-confirmed delete via a different principal.
+kubectl delete <kind>/<name> -n <ns>
+```
+
+For `Gateway` resources, post-rollback verification: `kubectl get gateway <name> -n <ns>` should return either the baseline state or `NotFound`. The associated controller's Pods should not show `Reconcile` errors in their logs.
+
+---
+
+## ClusterMesh peer Secret rollback
+
+```bash
+# Delete the peer secret
+kubectl delete secret <peer-cluster-name> -n kube-system
+
+# Verify ClusterMesh status reflects peer disconnection
+kubectl exec -n kube-system ds/cilium -- cilium clustermesh status
+```
+
+The kvstore replication state caches remote peer endpoint maps. Per `--clustermesh-cache-ttl` (default `0s` per upstream `docs.cilium.io`), the cache is **never revoked** after disconnect unless explicitly configured. Operators should pre-set a non-zero TTL before peering is established, otherwise rolling back the peer Secret leaves stale `ServiceImports` indefinitely.
+
+---
+
+## Universal rollback rules
+
+1. **Capture before write.** No baseline → no rollback → no mutation. The agent refuses if baseline capture failed.
+2. **Apply, don't delete, when in doubt.** Apply re-establishes the prior state idempotently. Delete cascades.
+3. **Verify after rollback.** A rollback is not complete until verification confirms the prior state holds.
+4. **Surface the rollback command before the mutation.** The user sees the rollback in the response shape **before** they approve the mutation, not after.
+5. **The rollback verb is part of the proposal, not a follow-up.** If the agent cannot produce a rollback, it cannot produce a mutation.

package/skills/kubernetes/kubernetes-live-rbac-mutation-guard/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: kubernetes-live-rbac-mutation-guard
 description: Guard live kubectl apply, create, or delete operations on Kubernetes RBAC objects — Roles, ClusterRoles, RoleBindings, ClusterRoleBindings — with privilege-escalation verb detection, scope assessment, current-state diff, and explicit approval before any write. Use only when an intentional RBAC mutation is requested against a confirmed cluster target.
+allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
   version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
 ---
 
 # Kubernetes Live RBAC Mutation Guard

package/skills/kubernetes/kubernetes-maestro/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: kubernetes-maestro
 description: Route Kubernetes tasks to the narrowest specialist or team of specialists from the catalog. Use when you do not already know the specialist. Not for direct Kubernetes answers; Maestro classifies, dispatches, and synthesizes only. Dispatches single agent for focused tasks, parallel team (max 4) for multi-domain tasks. Never auto-dispatches live-guard agents — requires explicit human confirmation with blast-radius and rollback before routing to any live mutation specialist.
+allowed-tools: Agent Skill Read Grep Glob
 metadata:
   author: "github: Raishin"
   version: "0.1.0"
+  updated: "2026-05-05"
+  category: ai
 ---
 
 # Kubernetes Maestro — Routing Skill

package/skills/kubernetes/kubernetes-maestro/references/safety-checklist.md

@@ -58,7 +58,7 @@ kubectl get application -n argocd <app-name> -o yaml | grep -A5 status
 
 ### Network Policy (kubernetes-live-network-policy-guard-agent)
 ```shell
-cilium monitor --type drop -n <namespace>        # Cilium: watch for drops
+kubectl -n kube-system exec ds/cilium -- cilium-dbg monitor --type drop  # Cilium: watch for drops (in-pod cilium-dbg)
 hubble observe --namespace <namespace>           # Hubble: traffic observation
 kubectl get cnp,ccnp,netpol -n <namespace>
 ```

package/skills/kubernetes/kubernetes-maestro/references/workflow-and-output.md

@@ -14,7 +14,9 @@ Use this reference when classifying a task or selecting the right specialist(s).
 | IRSA, workload identity, serviceAccountToken, OIDC trust, pod identity, azure workload identity, GKE WI, annotate serviceaccount, projected token, eks.amazonaws.com | kubernetes-workload-identity-review-agent | Workload identity review | No |
 | Istio, ambient mesh, waypoint, ztunnel, AuthorizationPolicy, PeerAuthentication, mTLS, RequestAuthentication, VirtualService, DestinationRule, HBONE | istio-ambient-mesh-review-agent | Istio mesh review | No |
 | apply AuthorizationPolicy, apply PeerAuthentication, change mTLS, delete DENY policy, enable PERMISSIVE, istioctl apply | kubernetes-live-mesh-policy-guard-agent | Live mesh policy mutation | YES |
-| Cilium, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, NetworkPolicy, ClusterMesh, egress gateway, Hubble, L7 policy, toCIDRSet | cilium-network-policy-review-agent | Cilium network policy review | No |
+| CNI choice, kube-proxy, kube-proxy mode, kube-proxy replacement, IPAM, MTU, encapsulation, VXLAN, Geneve, dual-stack, IPv6, Pod CIDR, Service CIDR, EndpointSlices, internalTrafficPolicy, externalTrafficPolicy, topology-aware routing, trafficDistribution, Ingress, Gateway API, GRPCRoute, HTTPRoute, GatewayClass, CoreDNS, NodeLocal DNSCache, ndots, Corefile, Submariner, MCS-API, ClusterMesh topology, ClusterMesh kvstore, conntrack, NodePort path | kubernetes-network-architecture-review-agent | Network architecture review | No |
+| apply Service patch internalTrafficPolicy, apply Service patch externalTrafficPolicy, annotate topology-mode, set trafficDistribution, patch CoreDNS Corefile, install NodeLocal DNSCache, apply Gateway API resource, apply HTTPRoute / GRPCRoute / TLSRoute / ReferenceGrant, create ClusterMesh peer Secret | kubernetes-live-network-architecture-mutation-guard-agent | Live network architecture mutation | YES |
+| Cilium policy, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, NetworkPolicy content, ClusterMesh policy, egress gateway policy, Hubble flow filter, L7 policy, toCIDRSet | cilium-network-policy-review-agent | Cilium network policy review | No |
 | apply CiliumNetworkPolicy, kubectl apply cnp, delete default-deny, change toCIDRSet, egress gateway policy | kubernetes-live-network-policy-guard-agent | Live network policy mutation | YES |
 | Argo CD, ArgoCD, Application, AppProject, ApplicationSet, sync window, argocd sync, gitops, app of apps, ApplicationSet | argocd-gitops-review-agent | Argo CD GitOps review | No |
 | argocd app sync, sync production, delete sync-window, expand AppProject, enable auto-sync, ApplicationSet cluster generator | kubernetes-live-argocd-sync-guard-agent | Live Argo CD sync guard | YES |
@@ -29,11 +31,12 @@ Use this reference when classifying a task or selecting the right specialist(s).
 | `admission-security` | PSA, PodSecurityAdmission, pod-security label, enforce, audit, warn, restricted, baseline, privileged, PSP migration, Kyverno, ClusterPolicy, PolicyException, mutate, generate, image verify |
 | `workload-identity` | IRSA, workload identity, serviceAccountToken, OIDC, pod identity, azure workload identity, GKE WI, projected token, bound service account |
 | `mesh` | Istio, ambient mesh, waypoint, ztunnel, AuthorizationPolicy, PeerAuthentication, mTLS, RequestAuthentication, VirtualService, DestinationRule, Envoy |
-| `network-policy` | Cilium, CiliumNetworkPolicy, NetworkPolicy, ClusterMesh, Hubble, egress gateway, L7 policy, CNI |
+| `network-architecture` | CNI choice, dataplane, kube-proxy mode, kube-proxy replacement, IPAM, MTU, encapsulation, dual-stack, IPv6, Pod CIDR, Service CIDR, Service routing surface, EndpointSlices, trafficPolicy, topology-aware routing, trafficDistribution, Ingress, Gateway API, GRPCRoute, HTTPRoute, CoreDNS, NodeLocal DNSCache, ndots, Corefile, multi-cluster topology, ClusterMesh topology and kvstore, Submariner, MCS-API, conntrack, NodePort path |
+| `network-policy` | Cilium policy semantics, CiliumNetworkPolicy, NetworkPolicy content, Hubble flow filter, egress gateway policy, L7 policy, ClusterMesh policy boundary |
 | `gitops` | Argo CD, ArgoCD, Application, AppProject, ApplicationSet, sync window, app of apps, GitOps, deployment sync |
 | `observability` | OpenTelemetry, OTEL, otelcol, collector, pipeline, receiver, processor, exporter, Instrumentation CR, TargetAllocator, tracing, metrics, logs |
 | `pki` | cert-manager, ClusterIssuer, Issuer, CertificateRequest, CertificateRequestPolicy, approver-policy, trust-manager, Bundle, ConfigMapBundle, certificate renewal, TLS cert, SPIFFE, cert-manager webhook |
-| `live-guard` | apply RBAC live, apply admission policy live, change mTLS live, apply network policy live, argocd sync production, requires human gate, production mutation |
+| `live-guard` | apply RBAC live, apply admission policy live, change mTLS live, apply network policy live, apply Service patch live, patch CoreDNS Corefile live, install NodeLocal DNSCache live, apply Gateway API resource live, create ClusterMesh peer Secret live, argocd sync production, requires human gate, production mutation |
 
 ## Specialist reference
 
@@ -65,11 +68,20 @@ Use this reference when classifying a task or selecting the right specialist(s).
 | `istio-ambient-mesh-review-agent` | Istio mesh review | Reviewing Istio ambient mesh waypoint config, AuthorizationPolicy, PeerAuthentication, mTLS mode, VirtualService/DestinationRule, or RequestAuthentication |
 | `kubernetes-live-mesh-policy-guard-agent` | Live mesh policy mutation | Applying or deleting AuthorizationPolicy or PeerAuthentication, changing mTLS mode, or enabling PERMISSIVE mode in a live cluster — gate required |
 
+### Network architecture
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `kubernetes-network-architecture-review-agent` | Network architecture review | Reviewing CNI choice, kube-proxy mode, kube-proxy replacement, IPAM, MTU and encapsulation, dual-stack, Pod / Service CIDR sizing (one-way doors), Service routing surface (EndpointSlices, internalTrafficPolicy / externalTrafficPolicy, topology-aware routing, `trafficDistribution`), Ingress vs Gateway API migration, CoreDNS Corefile, NodeLocal DNSCache architecture, multi-cluster topology (ClusterMesh topology, Submariner, MCS-API, ClusterMesh kvstore behavior), or troubleshooting connectivity at the dataplane / Service / DNS layer. Read-only; delegates NetworkPolicy content review and live mutations. |
+| `kubernetes-live-network-architecture-mutation-guard-agent` | Live network architecture mutation | Applying Service spec patches (`internalTrafficPolicy`, `externalTrafficPolicy`, `topology-mode`, `trafficDistribution`), patching CoreDNS Corefile (resourceName-locked `ConfigMap/coredns`), installing NodeLocal DNSCache, creating Gateway API resources (`Gateway`, `HTTPRoute`, `GRPCRoute`, `TLSRoute`, `ReferenceGrant`), or creating Cilium ClusterMesh peer `Secret` in a live cluster — gate required. **HARD REFUSE** one-way doors: CNI replacement, kube-proxy mode swap, MTU change, Pod / Service CIDR resize, namespace deletion, kube-system DaemonSet/Deployment writes, CRD operations. Cluster-side enforcement via least-privilege ServiceAccount per `docs/least-privilege-rbac.md`; pre-flight `kubectl auth can-i` matrix runs before any mutation. |
+
+**Scope boundary with policy / mesh / pod-spec specialists:** the architecture agent owns *design correctness, sizing, and operational traps* in dataplane, Service routing, DNS, and multi-cluster topology. It does NOT review NetworkPolicy content (→ `cilium-network-policy-review-agent`), mesh L7 (→ `istio-ambient-mesh-review-agent`), pod `securityContext` / hostNetwork (→ `kubernetes-pod-spec-review-agent`), or perform live mutations (→ `kubernetes-live-network-policy-guard-agent` / `kubernetes-live-mesh-policy-guard-agent`). When a task spans architecture + policy + mesh, dispatch the team in parallel; the architecture findings (kube-proxy replacement mode, CNI version, MTU, Envoy DaemonSet status) are independent inputs the policy and mesh specialists need.
+
 ### Network policy
 
 | Agent | Domain | Use when… |
 |---|---|---|
-| `cilium-network-policy-review-agent` | Cilium network policy review | Reviewing CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, ClusterMesh config, Hubble observability, or L7 policy rules |
+| `cilium-network-policy-review-agent` | Cilium network policy review | Reviewing CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, ClusterMesh policy semantics (`policy-default-local-cluster`), Hubble flow filter, or L7 policy rules. Architecture-level ClusterMesh design (topology, kvstore, CIDR overlap) is owned by `kubernetes-network-architecture-review-agent`. |
 | `kubernetes-live-network-policy-guard-agent` | Live network policy mutation | Applying or deleting CiliumNetworkPolicy, removing default-deny rules, changing toCIDRSet, or modifying egress gateway config in a live cluster — gate required |
 
 ### GitOps
@@ -170,7 +182,47 @@ Mode: parallel (2)
 
 ---
 
-### Live-guard gate example
+### Example 6: Holistic Kubernetes networking review (architecture + policy + mesh)
+
+**User request:** "Review our cluster's networking holistically — CNI choice, kube-proxy mode, our CiliumNetworkPolicies, and the Istio ambient mesh."
+
+**Routing:**
+```
+Route: kubernetes-network-architecture-review-agent, cilium-network-policy-review-agent, istio-ambient-mesh-review-agent
+Reason: Task spans network architecture (CNI, kube-proxy mode, dataplane, DNS), Cilium network policy content review, and Istio ambient mesh L7 review — three distinct networking concerns with non-overlapping scopes. Hard-ceiling 4 specialists; this stays under the limit.
+Mode: parallel (3)
+```
+
+`kubernetes-network-architecture-review-agent` reviews CNI choice, kube-proxy mode, IPAM, MTU, Pod / Service CIDR sizing as one-way doors, EndpointSlice topology, CoreDNS / NodeLocal DNSCache architecture, and ClusterMesh topology / kvstore behavior. `cilium-network-policy-review-agent` reviews CiliumNetworkPolicy default-deny posture, toCIDRSet rules, ClusterMesh policy semantics (`policy-default-local-cluster`), and L7 policy prerequisites — the L7 review depends on the architecture finding of whether Cilium kube-proxy replacement and Envoy DaemonSet are in place. `istio-ambient-mesh-review-agent` reviews waypoint configuration, AuthorizationPolicy, PeerAuthentication, and mTLS posture. The three outputs are scope-separated; the synthesizer surfaces architecture findings first because they may invalidate policy and mesh assumptions.
+
+**Sequencing note:** Architecture findings (kube-proxy replacement mode, Envoy DaemonSet running, MTU correctness) gate the *interpretation* of policy and mesh outputs but not their dispatch. Run in parallel; in the synthesis step, present architecture posture before policy and mesh — if architecture flags a one-way-door blocker, explicitly mark which policy and mesh recommendations may need to be re-scoped.
+
+---
+
+### Live-guard gate example: network architecture mutation
+
+**User request:** "Apply `service.kubernetes.io/topology-mode: Auto` annotation to the `frontend` Service in the `prod` namespace on the prod cluster."
+
+**Routing:**
+```
+Route: kubernetes-live-network-architecture-mutation-guard-agent
+Reason: Patching a Service annotation on a live production cluster is a live network architecture mutation — gate required even though the operation is reversible.
+Mode: live-guard-gate
+```
+
+**STOP — Live-guard gate. Before this dispatch can proceed, you must provide:**
+
+1. **Pre-flight RBAC self-check applied:** Confirm `skills/kubernetes/kubernetes-live-network-architecture-mutation-guard/references/least-privilege-rbac.yaml` is applied to the prod cluster, and that the agent's bound ServiceAccount has been pre-flight-tested with the `kubectl auth can-i` matrix from `references/rbac-pre-flight.md`. Every must-not row must return `no`; every must-be row must return `yes`.
+2. **Operator principal check:** Confirm your kubeconfig is **not** `cluster-admin` and **not** in `system:masters`. The agent will refuse if `kubectl auth can-i '*' '*' --all-namespaces` returns `yes` for your principal.
+3. **Blast-radius assessment:** Which workloads currently consume the `frontend` Service? Cross-zone traffic patterns may shift if `topology-mode: Auto` populates hints with insufficient endpoints per zone.
+4. **Rollback path:** `kubectl annotate svc frontend -n prod service.kubernetes.io/topology-mode-` (the `-` suffix removes the annotation) — confirmed reversible in under 30 seconds.
+5. **Explicit written confirmation:** Type "I confirm I understand the blast radius and rollback path. Proceed."
+
+For irreversible operations (CNI replacement, kube-proxy mode swap, MTU change, Pod / Service CIDR resize, namespace deletion, kube-system DaemonSet writes, CRD operations), the agent **HARD REFUSES** regardless of operator confirmation — these belong to a human-led cutover plan that the architecture review agent (`kubernetes-network-architecture-review-agent`) can produce but no agent in this repo will execute.
+
+---
+
+### Live-guard gate example: RBAC mutation
 
 **User request:** "Apply the new ClusterRoleBinding for the payments service account in the prod cluster."
 

package/skills/kubernetes/kubernetes-network-architecture-review/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: kubernetes-network-architecture-review
+description: Use this skill for Kubernetes cluster network architecture review across the dataplane (CNI choice, kube-proxy mode, IPAM, MTU, encapsulation, dual-stack), service routing surface (Service types, EndpointSlices, internalTrafficPolicy/externalTrafficPolicy, topology-aware routing, Ingress, Gateway API), in-cluster DNS (CoreDNS, NodeLocal DNSCache, ndots), multi-cluster topology (ClusterMesh, Submariner, MCS-API design choices), and connectivity observability and troubleshooting. Trigger when the user asks how to choose or change a CNI, why pod-to-pod or pod-to-service traffic fails, whether to migrate from Ingress to Gateway API, why DNS latency is high, how to size Pod or Service CIDRs, or how to design multi-cluster networking. Does NOT review NetworkPolicy content (delegate to cilium-network-policy-review) or perform live mutations (delegate to kubernetes-live-network-policy-guard / kubernetes-live-mesh-policy-guard).
+allowed-tools: Read Grep Glob WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-07"
+  category: networking
+---
+
+# Kubernetes Network Architecture Review
+
+## Purpose
+
+Review Kubernetes cluster networking *as a system* — the choices that shape every pod's reachability, latency, and blast radius before any policy is written. This skill is about **design correctness, sizing, and operational traps** in the dataplane, service routing, DNS, and multi-cluster surface. Policy correctness is delegated.
+
+## Scope boundary
+
+In scope:
+
+- CNI selection and dataplane mode (overlay vs native routing, eBPF vs iptables, kube-proxy replacement).
+- IPAM mode and Pod/Service CIDR sizing, including dual-stack and IPv6.
+- MTU and encapsulation overhead, jumbo frames, fragmentation traps.
+- Service surface: ClusterIP / NodePort / LoadBalancer / ExternalName / headless, EndpointSlices, `internalTrafficPolicy`, `externalTrafficPolicy`, topology-aware routing, `sessionAffinity`.
+- Ingress vs Gateway API: GatewayClass selection, role-oriented model (infrastructure / cluster operator / application), HTTPRoute / GRPCRoute / TLSRoute, ReferenceGrant, GAMMA mesh integration.
+- In-cluster DNS: CoreDNS Corefile, NodeLocal DNSCache architecture and risks, `ndots:5` tail-latency trap, ExternalDNS handoff.
+- Multi-cluster networking topology: Cilium ClusterMesh, Submariner, KEP-1645 MCS-API — pick on basis of identity, address-overlap, and policy semantics.
+- Connectivity observability: kube-proxy metrics, conntrack, Hubble flow shape, dropped packets, MTU mismatches.
+- Troubleshooting playbooks (read-only): pod-to-pod, pod-to-Service, pod-to-external, NodePort path, conntrack exhaustion.
+
+Out of scope — delegate:
+
+- NetworkPolicy / CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy content review → `cilium-network-policy-review`.
+- Istio mesh policy / ambient L7 → `istio-ambient-mesh-review`.
+- Live mutations on policy objects → `kubernetes-live-network-policy-guard`, `kubernetes-live-mesh-policy-guard`.
+- Pod `securityContext`, capabilities, host networking → `kubernetes-pod-spec-review`.
+
+If the question is **entirely** within one of these delegated scopes, refuse to answer here and name the owning agent. Do not partial-answer and append a handoff line.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get nodes,svc,endpointslices,gateway,gatewayclass,httproute,configmap -A`, `cilium status`, `cilium-dbg bpf`, `hubble observe`, `kube-proxy --metrics-port`, `conntrack -L`) when a Kubernetes MCP server, `kubectl`, and node-shell access are available; otherwise fall back to upstream documentation (kubernetes.io, gateway-api.sigs.k8s.io, docs.cilium.io, coredns.io) and sanitized YAML.
+- Separate confirmed facts from inference. If the CNI version, kube-proxy mode, IPAM mode, MTU, or DNS pod count was not queried, say so.
+- Treat **pod and service CIDR sizing** as architectural one-way doors — changing a Pod CIDR after the cluster is in use generally requires a cluster rebuild on most CNIs. Demand evidence of growth headroom.
+- Treat **kube-proxy mode swap** (iptables ↔ IPVS ↔ nftables, or to Cilium kube-proxy replacement) as a connectivity-affecting rollout — sessions on existing connections may break depending on mode and conntrack handling.
+- Treat **MTU mismatch between underlay and overlay** as a silent failure mode — TCP handshakes succeed, then large payloads stall. Always check whether encapsulation overhead (VXLAN 50B, Geneve 60B, WireGuard 60B with IPsec extra) was subtracted from node MTU.
+- Treat **`externalTrafficPolicy: Local`** as a correctness-sensitive choice — preserves source IP but breaks load balancing if the matching pod is not on the receiving node, and exposes pod placement to clients via uneven load.
+- Treat **`internalTrafficPolicy: Local`** the same way for in-cluster traffic — silent black-holing if no local endpoint exists.
+- Treat **`ndots:5` plus search-path expansion** as the default DNS tail-latency root cause. Five negative lookups before the absolute name on every external query, multiplied by every pod, is the dominant DNS load on most clusters.
+- Treat **NodeLocal DNSCache OOM** as a node-wide DNS outage — packet-filtering rules redirect to an unhealthy cache pod until restart. Memory limits and PDB are mandatory.
+- Treat **Ingress Controller annotations** as non-portable — migrating to Gateway API requires a route-by-route rewrite, not a global flip; plan the migration as a controller-by-controller cutover with overlap.
+- Treat **multi-cluster pod CIDR collisions** as the first failure for any cross-cluster scheme — reject any design that does not declare non-overlapping Pod CIDRs (or explicit NAT) before discussing identity or policy.
+- Treat **Cilium ClusterMesh kvstore replication lag** as a silent failure — remote ServiceImports serve stale endpoint maps with no error surfaced. Connections succeed but route to removed/replaced pods after a scale event. Compare endpoint revisions across peers (`cilium-dbg kvstore get`) when ClusterMesh is in scope.
+- Treat **conntrack table exhaustion** on busy nodes and **AWS NAT Gateway port exhaustion** (~55k connections per destination IP) as silent drops — packets disappear without errors at the application layer.
+- Treat **topology-aware routing skew** when zone labels are missing or unevenly populated as a silent traffic concentration — the Auto mode silently falls back to cluster-wide routing or drops endpoints.
+- Treat **any pod egress to `169.254.169.254` (AWS / Azure IMDS)** or **`metadata.google.internal` (GCP)** as a credential-theft vector. Recommend IRSA / Workload Identity / Pod Identity before discussing any egress allow rule. Surface unblocked metadata-service reachability as a HIGH severity finding rather than silently delegating to policy review.
+- **Do not invent CLI flags or commands.** Reference only `kubectl`, `cilium`, `cilium-dbg`, `hubble`, `calicoctl`, `subctl`, `ip`, `conntrack`, `iptables`, `ipvsadm`, `nft`, `coredns`. For anything outside this set, ask the user for the help text or a doc link rather than guess.
+- Refuse user-initiated mutation requests ("just apply this for me") and credential offers (kubeconfig, tokens, peer Secrets). Name the live-mutation delegate; do not proceed.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers, unknowns, and which delegate skill owns the next step.
+
+## References
+
+Load these only when needed:
+
+- [Dataplane and CNI choice](references/dataplane-and-cni.md) — use when reviewing CNI selection, kube-proxy mode, IPAM, MTU and encapsulation, dual-stack and IPv6.
+- [Service and Gateway API routing](references/service-gateway-routing.md) — use when reviewing Service types, EndpointSlices, `internalTrafficPolicy` / `externalTrafficPolicy`, topology-aware routing, Ingress vs Gateway API, GatewayClass selection.
+- [DNS and service discovery](references/dns-and-discovery.md) — use when reviewing CoreDNS Corefile, NodeLocal DNSCache, `ndots:5`, autopath, ExternalDNS.
+- [Multi-cluster and egress topology](references/multi-cluster-and-egress.md) — use when reviewing ClusterMesh, Submariner, MCS-API, egress-from-cluster topology, cross-cluster service discovery.
+- [Connectivity troubleshooting playbook](references/troubleshooting-playbook.md) — use when diagnosing pod-to-pod, pod-to-service, pod-to-external failures, intermittent latency, MTU stalls, conntrack exhaustion.
+- [Evidence path and tooling](references/mcp-and-evidence.md) — use when choosing live cluster evidence, identifying CNI/kube-proxy/IPAM/DNS state, or switching to documentation mode.
+- [Official sources](references/official-sources.md) — use when you need the authoritative Kubernetes / Gateway API / Cilium / CoreDNS reference list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the **scoped target** (CNI, Service, Gateway, DNS, multi-cluster topology, troubleshooting),
+- the **evidence level** — labeled **per finding**, not response-level only: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`. A response may legitimately mix levels; each finding must carry its own.
+- the **architectural posture findings** (with severity: high / medium / low),
+- the **safest next actions** — keep them reversible; for irreversible changes (CIDR resizing, kube-proxy swap), call out a tested cutover plan,
+- the **rollback or fallback path**,
+- the **delegate handoff** when the next step is policy content, mesh policy, live mutation, or pod-spec — name the skill or agent that owns it,
+- the **assumptions and blockers** that prevent stronger conclusions — if CNI version, kube-proxy mode, IPAM mode, node MTU, or DNS pod count were not confirmed by live evidence, each MUST appear here as an explicit open assumption. This field is not optional.

package/skills/kubernetes/kubernetes-network-architecture-review/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "kubernetes-network-architecture-review",
+  "name": "Kubernetes Network Architecture Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Kubernetes cluster network architecture: CNI and dataplane selection, kube-proxy mode and replacement, IPAM and CIDR sizing, MTU and encapsulation, dual-stack and IPv6, Service surface (EndpointSlices, internalTrafficPolicy, externalTrafficPolicy, topology-aware routing), Ingress to Gateway API migration, CoreDNS and NodeLocal DNSCache, multi-cluster topology, and connectivity observability and troubleshooting. Excludes NetworkPolicy content review and live mutations — those are delegated to cilium-network-policy-review and the live-guard agents.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kubernetes.io/docs/concepts/services-networking/",
+    "https://kubernetes.io/docs/reference/networking/virtual-ips/",
+    "https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/",
+    "https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/",
+    "https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/",
+    "https://kubernetes.io/docs/concepts/services-networking/dual-stack/",
+    "https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/",
+    "https://gateway-api.sigs.k8s.io/",
+    "https://docs.cilium.io/en/stable/network/concepts/",
+    "https://docs.cilium.io/en/stable/network/kube-proxy-replacement/",
+    "https://coredns.io/plugins/kubernetes/"
+  ],
+  "security_notes": "CNI and Pod CIDR are one-way architectural choices on most stacks — resizing requires cluster rebuild. kube-proxy mode swap can break in-flight connections. MTU mismatch between underlay and overlay is a silent payload-stall failure. externalTrafficPolicy: Local preserves source IP but black-holes traffic when no local endpoint exists. NodeLocal DNSCache OOM produces a node-wide DNS outage via stale packet-filter redirect. Multi-cluster pod CIDR collisions break any cross-cluster scheme regardless of policy correctness. ndots:5 plus search path is the dominant cluster DNS load on most installations.",
+  "last_verified": "2026-05-07",
+  "path": "skills/kubernetes/kubernetes-network-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubernetes-network-architecture-review/references/dataplane-and-cni.md

@@ -0,0 +1,89 @@
+# Dataplane and CNI
+
+## Step 1 — Identify the dataplane and CNI
+
+Capture, in order:
+
+1. **CNI plugin and version** — `kubectl -n kube-system get pods -l k8s-app=cilium -o name` (or `calico-node`, `flannel`, `aws-node`, `azure-cns`, `gke-cni`). Different CNIs have entirely different dataplanes (eBPF vs iptables vs vendor SDN), so every later question depends on this answer.
+2. **kube-proxy presence and mode** — `kubectl -n kube-system get ds kube-proxy` and the `--proxy-mode` flag in its ConfigMap (`kubectl -n kube-system get cm kube-proxy -o yaml`). On Cilium kube-proxy replacement, the DaemonSet does not exist or is disabled.
+3. **Routing mode** — encapsulation (VXLAN, Geneve, IPIP) vs native routing. Encapsulation works anywhere but adds 50–60 bytes of overhead and slightly higher CPU; native routing requires the underlay to route Pod CIDRs.
+4. **IPAM mode** — `cluster-pool` (CNI manages CIDR), `kubernetes` (uses `node.spec.podCIDR`), `aws-eni` / `azure` / `gke` (cloud IPAM, pods get VPC IPs).
+5. **Pod and Service CIDRs** — `kubectl cluster-info dump | grep -E '(cluster-cidr|service-cluster-ip-range)'` or check kube-controller-manager flags. Once set, these are very hard to change.
+6. **Node MTU and overlay MTU** — `ip link show | grep mtu`, then the CNI overlay interface (`cilium_vxlan`, `flannel.1`). The overlay MTU should be `node MTU − encapsulation overhead`.
+
+## Step 2 — Stress-test the CNI choice against actual requirements
+
+Common decision points and the trap each one hides:
+
+- **Cilium with kube-proxy replacement** — requires a kernel new enough for the eBPF features used (varies by version; verify with `cilium status` and the version's [system requirements page](https://docs.cilium.io/en/stable/operations/system-requirements/)). On older kernels, parts of KPR fall back to legacy paths and you lose the performance argument.
+- **Calico in BGP mode** — requires the underlay to accept BGP from every node, or a route reflector. In cloud, this often means a peering VM. In a managed cluster, this is usually impossible — the cluster ends up in IPIP encapsulation, defeating the BGP choice.
+- **AWS VPC CNI** — pods get VPC IPs, so subnet sizing and ENI limits per instance type bound pod density. An m5.large can hold ~30 pods because of ENI/IP limits, not memory. This is the dominant pod-density ceiling on EKS.
+- **Azure CNI (legacy)** — pre-allocates pod IPs from the subnet at node join, exhausting the subnet long before the pods exist.
+- **Azure CNI Overlay** — pods get a separate overlay CIDR; nodes still consume VNet IPs. Works at scale but add it as a deliberate IPAM choice, not the default.
+- **GKE alias IPs** — pod range is a secondary range on the VPC; sizing is fixed per cluster and resizing requires recreation.
+
+## Step 3 — Stress-test kube-proxy mode
+
+| Mode | Strengths | Real failures |
+|---|---|---|
+| `iptables` (default) | Simple, broadly tested | Rule count grows linearly with `Services × Endpoints`. On large clusters (10k+ Services) full rule resync becomes a multi-second event; new Service propagation latency rises. |
+| `ipvs` | Hash-based lookup, scales to many Services. Multiple LB algorithms. | Requires `ip_vs` kernel modules loaded on every node. Some session-affinity edge cases differ from iptables. Conntrack still drives source-IP preservation. |
+| `nftables` | Modern netfilter framework; better incremental update than iptables. | Newer; not all distros have stable nftables tooling. Still relatively young in production at scale. |
+| `kernelspace` (Windows) | Native Windows | Windows-only; behavior differs (no init container hostNetwork tricks, etc.). |
+| Cilium kube-proxy replacement | eBPF socket-LB; bypasses iptables entirely; preserves source IP for NodePort without `externalTrafficPolicy: Local` quirks. | Requires Cilium dataplane. Some hostPort and kernel-version edge cases. Verify `cilium status` reports KPR enabled in the expected mode (`Strict`, `Probe`, etc.). |
+
+Stress-tests the review must apply:
+
+- Migrating from `iptables` to `ipvs` or `nftables` on a running cluster — short connectivity blip during the rollout as kube-proxy rewrites rules. Schedule like a node-by-node rollout, not a config flag flip.
+- Migrating to Cilium KPR — uninstall kube-proxy *after* Cilium reports KPR healthy on every node. Removing kube-proxy first leaves Service VIPs unreachable.
+- Mixed mode during rollout — half nodes on iptables, half on Cilium KPR — Service traffic to a Pod on a KPR node from a kube-proxy node may follow different return paths and confuse conntrack. Plan a fast rollout window.
+
+## Step 4 — Stress-test IPAM and CIDR sizing
+
+A cluster sized 10× too small for its eventual workload count is the most common architectural debt — and it is hard to fix.
+
+Sizing stress-tests:
+
+- **Pod CIDR size** vs **max nodes × max pods/node** — a `/16` Pod CIDR with a `/24` per node gives 256 nodes max. A `/22` per node gives 64 nodes. Many CNIs allocate a fixed-size block per node, so the right number is `nodes × pods_per_node × headroom`.
+- **Service CIDR size** — Services tend to grow faster than people predict (every Helm chart adds a few). A `/16` is fine; a `/20` is risky in any cluster running a service mesh, since per-namespace mesh control planes add Services.
+- **CIDR collision with on-prem or peer VPC** — pods in `10.0.0.0/8` cannot route to an on-prem `10.x.x.x` system. RFC 1918 collision checks must precede every cluster build.
+- **`100.64.0.0/10` and `198.18.0.0/15`** — use carrier-grade NAT and benchmarking ranges if RFC 1918 is exhausted; cloud providers generally tolerate them.
+- **IPv6 / dual-stack** — single-stack v6 only is rarely supported by ecosystem tools (registries, observability). Dual-stack is the practical choice; ensure `--service-cluster-ip-range` and `--cluster-cidr` carry both families and that EndpointSlices report both.
+
+## Step 5 — Stress-test MTU and encapsulation
+
+MTU mismatch is a silent failure. The TCP three-way handshake passes (small packets), then the first large response stalls forever because Path MTU Discovery (PMTUD) ICMP is dropped by a firewall.
+
+The arithmetic the review must enforce:
+
+- VXLAN: 50 bytes (8 VXLAN + 8 UDP + 20 IPv4 + 14 Ethernet but 14 is shared) → overlay MTU = node MTU − 50.
+- Geneve: 60 bytes typical → overlay MTU = node MTU − 60.
+- IPIP: 20 bytes.
+- WireGuard (Cilium transparent encryption): ~60 bytes plus alignment.
+- IPsec: variable, ~73 bytes worst case.
+
+Stress-tests:
+
+- Cloud underlay at MTU 1500 → overlay should be 1450 (VXLAN). Some installers default to 1500 on the overlay too — silent corruption on first large packet.
+- Jumbo frames (MTU 9000) on AWS — works inside the same Availability Zone. Cross-AZ traffic is silently capped at 1500 by AWS, so jumbo overlay across AZs causes random stalls.
+- GKE / EKS / AKS managed nodes — verify the cloud-provider MTU before trusting the CNI's auto-detection. Some installers read `eth0` MTU at startup and miss later changes.
+
+Verification step: `kubectl run mtu-test --rm -it --image=alpine -- ping -M do -s <payload> <peer-pod-ip>`. The Don't-Fragment bit forces the kernel to fail rather than fragment, exposing the MTU ceiling.
+
+## Step 6 — Dual-stack and IPv6
+
+- The cluster API server, kube-controller-manager, kube-proxy, kubelet, and the CNI must all be configured for dual-stack. A partial enablement leads to confusing behavior where Services have only IPv4 addresses but Pods have both.
+- `Service.spec.ipFamilies` and `ipFamilyPolicy` (`SingleStack`, `PreferDualStack`, `RequireDualStack`) are the per-Service selectors. Default depends on the cluster's primary family.
+- EndpointSlices report addresses per family — verify both families are populated when `RequireDualStack` is in use.
+- IPv6-only clusters interact poorly with images pulled from IPv4-only registries; verify NAT64/DNS64 or registry mirroring is in place.
+
+## Output for this section
+
+- CNI and version,
+- kube-proxy mode (or KPR mode),
+- routing mode (encapsulation type or native),
+- IPAM mode and Pod / Service CIDR sizes,
+- node and overlay MTU,
+- dual-stack posture,
+- findings on sizing headroom, mode mismatch, MTU correctness, KPR readiness,
+- one-way-door warnings (CIDR resize, KPR migration) with cutover plan if a change is recommended.

package/skills/kubernetes/kubernetes-network-architecture-review/references/dns-and-discovery.md

@@ -0,0 +1,120 @@
+# DNS and Service Discovery
+
+## Step 1 — Identify the in-cluster DNS topology
+
+Capture:
+
+- CoreDNS deployment shape: `kubectl -n kube-system get deploy coredns -o wide`. Replica count, resources, anti-affinity.
+- CoreDNS Corefile: `kubectl -n kube-system get cm coredns -o yaml`. Plugins enabled, forward target, cache TTL, autopath, log/errors.
+- NodeLocal DNSCache presence: `kubectl -n kube-system get ds node-local-dns` (or `nodelocaldns`). Listening IP (typically a link-local address like `169.254.20.10`), upstream target, kube-proxy mode coupling.
+- kubelet `--cluster-dns` flag — does it point at the CoreDNS Service IP, or at the NodeLocal DNSCache link-local IP?
+- A pod's `/etc/resolv.conf`: `kubectl exec <pod> -- cat /etc/resolv.conf`. Note the `search`, `nameserver`, and `options ndots:` lines.
+
+## Step 2 — Stress-test the Corefile
+
+A canonical Corefile for a Kubernetes cluster typically uses these plugins in order:
+
+```
+.:53 {
+    errors
+    health { lameduck 5s }
+    ready
+    kubernetes cluster.local in-addr.arpa ip6.arpa {
+        pods insecure          # consider: pods verified
+        fallthrough in-addr.arpa ip6.arpa
+        ttl 30
+    }
+    prometheus :9153
+    forward . /etc/resolv.conf {
+        max_concurrent 1000
+    }
+    cache 30
+    loop
+    reload
+    loadbalance
+}
+```
+
+Stress-tests:
+
+- `pods insecure` returns A records for any pod IP without verifying a pod exists in that namespace. `pods verified` validates against pod existence in the same namespace; higher memory cost but a tighter security posture.
+- `forward . /etc/resolv.conf` follows the node's resolv.conf, which may point to the cloud DNS (169.254.169.254 on AWS, 168.63.129.16 on Azure). If pods talk to external services, every miss escapes the cluster — set `max_concurrent` deliberately to bound load on the upstream.
+- Missing `cache` plugin — every query hits upstream, including repeated queries for the same name within the TTL. The cache plugin is required for any cluster with non-trivial DNS load.
+- `cache` TTL larger than the upstream record's TTL — stale records persist past the authoritative source's update window. 30 seconds is a typical compromise.
+- `autopath` plugin — server-side search-path completion. Reduces the `ndots:5` round-trip cost (see Step 4) but requires `pods verified`, costs more memory, and complicates debugging because client-side lookups no longer match what reaches CoreDNS.
+- `loop` plugin — detects forwarding loops at startup. Without it, a forward to the cluster's own resolv.conf can loop until the deployment crashes. Always keep `loop` enabled.
+- `reload` plugin — picks up Corefile changes without a restart. Without it, a ConfigMap edit is not honored until the pod is recreated.
+
+## Step 3 — Stress-test CoreDNS scaling
+
+CoreDNS is the single most overlooked source of cluster-wide latency. Defaults from `kubeadm` and many installers are not production-sized.
+
+- Replica count — small clusters get 2 replicas by default. A cluster with 1000 pods doing 100 QPS per pod sees 100k QPS; two replicas with stock resources will become a queue.
+- Resource requests / limits — many installers default to a tight `100m CPU / 70Mi memory` request that is fine for 100 pods and a CPU throttle for 10000.
+- Pod anti-affinity — every CoreDNS replica must be on a different node. The default deployments usually have this; verify after migration to a new cluster.
+- PodDisruptionBudget — `minAvailable: 1` is the absolute floor; a stricter `maxUnavailable: 1` plus PDB on the DaemonSet's underlying nodes is safer during cluster autoscaler events.
+- `cluster-proportional-autoscaler` ([repository](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)) is the standard way to scale CoreDNS replicas with cluster size.
+
+## Step 4 — The `ndots:5` and search-path tail-latency trap
+
+The default `dnsPolicy: ClusterFirst` injects an `options ndots:5` line into every pod's `/etc/resolv.conf` along with a search list like:
+
+```
+search default.svc.cluster.local svc.cluster.local cluster.local
+options ndots:5
+```
+
+The `ndots:5` directive means: any name with fewer than 5 dots is treated as relative and tried against every search-list entry first.
+
+For a query like `api.example.com` (3 dots) the resolver issues:
+
+1. `api.example.com.default.svc.cluster.local.` — NXDOMAIN
+2. `api.example.com.svc.cluster.local.` — NXDOMAIN
+3. `api.example.com.cluster.local.` — NXDOMAIN
+4. `api.example.com.` — finally the real query
+
+For external services, that is **4× the DNS load** and 3× the chance of dropped UDP packets causing a 5-second timeout.
+
+Mitigations the review must consider:
+
+- Lower `options ndots:1` per-pod via `dnsConfig.options` for workloads that overwhelmingly resolve external hostnames. Cluster-internal Service names still resolve because they are absolute when written in the canonical `service.namespace.svc.cluster.local` form.
+- Use `ExternalName` Services so that `mysvc.namespace.svc.cluster.local` is the canonical reference, avoiding search-list expansion entirely.
+- Enable `autopath` in CoreDNS — completes the search path server-side, requires `pods verified` and more memory.
+- Always pair this fix with NodeLocal DNSCache so the search-list expansion cost stays on the node.
+
+## Step 5 — NodeLocal DNSCache deep-dive
+
+Per the [Kubernetes docs](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/), NodeLocal DNSCache runs as a DaemonSet listening on a link-local IP. It solves three production problems:
+
+1. **conntrack overhead** — every UDP DNS query allocates a conntrack entry that lives 30 seconds; high-DNS-QPS pods exhaust conntrack tables and trigger random drops elsewhere. NodeLocal DNSCache upgrades to TCP for upstream traffic, where entries are removed on connection close.
+2. **5-second timeout amplification** — a dropped UDP packet triggers the resolver's retry timer (3 × 10s on glibc, with extra hops). Local cache hits remove most of this.
+3. **DNAT bypass** — pods talking to the link-local IP skip the iptables/IPVS Service VIP rewrite entirely.
+
+Operational risks the review must call out:
+
+- **OOMKill is a node-wide DNS outage.** When the local cache pod is killed, the iptables rules that redirected DNS traffic to the cache stay in place pointing at an unhealthy pod until the new pod is ready. Set memory limits with headroom (default cache is 10k entries ≈ 30 MB; 100 MB request and 200 MB limit is a safer baseline) and monitor `coredns_dns_cache_size_entries`.
+- **PodDisruptionBudget** for the DaemonSet — node drains during cluster autoscaler events should not all evict the local cache simultaneously.
+- **kubelet `--cluster-dns` flag must be updated** if the kube-proxy mode is IPVS — see the linked docs for the exact rewrite. iptables mode tolerates either the cache IP or the kube-dns Service IP.
+- **IPv6** — the link-local address must be enclosed in brackets (`[fd00::1]:53`).
+- **Cilium kube-proxy replacement** — Cilium's `socketLB` honors the per-pod redirect to the link-local IP only with the right options; verify with Cilium's NodeLocal DNSCache integration page for the version in use.
+
+## Step 6 — ExternalDNS and the boundary
+
+`ExternalDNS` runs in the cluster but operates on cloud DNS (Route 53, Cloud DNS, Azure DNS, OCI DNS) — it is the bridge between Kubernetes Service / Ingress / Gateway and externally reachable hostnames.
+
+Architecture review checks:
+
+- The IAM/role binding ExternalDNS uses must be scoped to the specific hosted zone(s) and the record types it actually creates (typically A, AAAA, CNAME, TXT). A `*` permission is over-scoped.
+- Ownership records (TXT) prevent two clusters fighting over the same hostname. Without them, two ExternalDNS deployments will continually overwrite each other's records — silent ping-pong.
+- TTL: the default may be high (300s); for blue/green or canary cutovers, a low TTL on the routed records is required, set per-resource via the `external-dns.alpha.kubernetes.io/ttl` annotation.
+
+This boundary is also where this skill's scope ends — DNS *outside* the cluster is the AWS / Azure / OCI network architect's territory.
+
+## Output for this section
+
+- CoreDNS topology, Corefile critical-plugin checks (cache, loop, reload, kubernetes plugin mode),
+- replica count and autoscaler posture,
+- `ndots:5` exposure for the workloads in scope and the per-pod `dnsConfig.options` plan,
+- NodeLocal DNSCache presence, memory headroom, PDB, and OOM exposure,
+- ExternalDNS scope, ownership-TXT posture, TTL hygiene,
+- findings, severity, and the next-step delegate (cloud-network-architect agent for hosted-zone scoping).