Senior Cloud-Native Architect

Aggregates: kubernetes-specialist, sre-specialist, gitops-specialist, service-mesh-specialist, cloud-architect

Cloud Provider Selection

| Provider | Strengths | Best For | Weaknesses | |----------|-----------|----------|------------| | AWS | Breadth of services, mature ecosystem, global reach | Enterprises, hybrid cloud, legacy migration | Complexity, cost management, lock-in risk | | GCP | Kubernetes-native (GKE), data/AI, networking | Cloud-native orgs, data pipelines, ML workloads | Smaller service catalog, fewer regions | | Azure | Microsoft stack integration, hybrid (Arc), AAD | Enterprise Microsoft shops, .NET workloads | K8s less mature, service inconsistency |

Kubernetes Architecture

Control Plane Components

• kube-apiserver: Entry point, validates/configures API objects, etcd-backed
• etcd: Distributed key-value store, single source of truth (3-5 nodes for HA)
• kube-scheduler: Assigns pods to nodes based on resource requests, affinity, taints
• kube-controller-manager: Runs controller loops (Deployment, StatefulSet, Node, etc.)
• cloud-controller-manager: Cloud provider integration (LB, nodes, routes)

Workload Types

| Type | State | Scaling | Use Case | |------|-------|---------|----------| | Deployment | Stateless | Replicas + HPA | Web apps, APIs | | StatefulSet | Stateful | Ordinal + PVC | Databases, message queues | | DaemonSet | Per-node | Node-driven | Logging agents, node monitors | | Job/CronJob | Ephemeral | Parallelism | Batch processing, backups |

Networking

• CNI plugins: Calico (network policy), Cilium (eBPF, service mesh), Flannel (simple overlay)
• Service types: ClusterIP, NodePort, LoadBalancer, ExternalName
• Ingress controllers: nginx-ingress, contour (Envoy), haproxy, AWS/GCP L7 LB
• Gateway API: Replaces Ingress, role-oriented (provider-independent)

Storage Classes and CSI

• CSI drivers: EBS, EFS, GCE PD, Azure Disk/File, Ceph RBD, NFS
• Volume modes: Filesystem (ReadWriteOnce/ReadWriteMany), Block
• Ephemeral vs persistent: EmptyDir, hostPath (avoid), PVC, ephemeral inline

Security

• RBAC: Role/ClusterRole, RoleBinding/ClusterRoleBinding, least privilege
• Pod Security Standards: Privileged, Baseline, Restricted (PodSecurityAdmission)
• Network policies: Default deny, ingress/egress rules, pod selector
• Secrets: etcd encryption at rest, external secrets (AWS Secrets Manager, Vault)
• Service accounts: TokenRequest API, projected volumes, OIDC federation
• OPA/Gatekeeper: Admission webhooks, policy enforcement
• Kyverno: Kubernetes-native policy engine (mutate, validate, generate)

GitOps

ArgoCD vs Flux

| Feature | ArgoCD | Flux | |---------|--------|------| | Architecture | Pull-based, CRD-driven | Pull-based, controller-driven | | UI | Rich web UI + CLI | CLI + dashboard (weave-gitops) | | Sync strategies | Manual, automated, self-heal | Automated, reconciliation loop | | Multi-cluster | Hub-spawn (ArgoCD clusters) | Kustomize overlays + clusters | | Secret management | SOPS, sealed-secrets, Vault | SOPS, Mozilla sops, sealed-secrets | | Image updates | ArgoCD Image Updater | Flux Image Automation | | Git providers | GitHub, GitLab, Bitbucket | Same + Azure DevOps | | Rollback | Automatic rollback on failure | Manual revert in Git |

Best Practices

1. One repo per cluster or mono-repo with Kustomize overlays
2. Use Kustomize or Helm for environment differentiation
3. Enable automated sync with self-heal for non-production
4. Use PR-driven sync for production (manual sync approval)
5. Implement cluster-scoped vs namespace-scoped apps

Service Mesh

When to Use Each

| Mesh | Strengths | Best For | Trade-offs | |------|-----------|----------|------------| | Istio | Feature-rich, mTLS, traffic management, observability | Enterprises, multi-cluster, compliance | Complexity, resource overhead, learning curve | | Linkerd | Lightweight, simple, Rust data plane | Teams wanting simple zero-trust | Less feature-rich, no eBPF | | Cilium | eBPF-based, high performance, network policy | Performance-sensitive, Kubernetes-native | Newer ecosystem, less mesh maturity |

Istio Architecture

• Data plane: Envoy sidecars (per-pod or per-node)
• Control plane: istiod (Pilot, Citadel, Galley consolidated)
• Traffic management: VirtualService, DestinationRule, Gateway, ServiceEntry
• Security: PeerAuthentication (mTLS), RequestAuthentication (JWT), AuthorizationPolicy
• Observability: Telemetry (metrics, access logs), Kiali dashboard, distributed tracing

mTLS Migration Strategy

1. PERMISSIVE mode (allows plaintext + mTLS)
2. STRICT mode for sensitive namespaces
3. Full roll-out with monitoring (no breakage)

Linkerd Architecture

• Data plane: Linkerd2-proxy micro-proxy (Rust)
• Control plane: Destination, Identity, Proxy injector
• Features: mTLS by default, HTTP/2, gRPC, load balancing, retries, timeouts
• Observability: tap, top, metrics (Prometheus), dashboard

SRE

SLO / SLI / Error Budget

service: user-api
slis:
  latency_p99:
    measurement: "prometheus.http_request_duration_seconds"
    filter: "status=~'2..|3..'"
    threshold: 500ms
    window: 30d
  availability:
    measurement: "prometheus.http_requests_total"
    filter: "status=~'5..'"
    threshold: 99.9%
    window: 30d
error_budget:
  monthly_limit: 100 - slo_percentage
  current_burn_rate: error_budget_consumed / window_days

Dashboard Types

• Service dashboard: Latency, traffic, errors, saturation (USE method)
• Dependency dashboard: Upstream/downstream health, DB connections, queue depth
• Alert dashboard: Firing alerts, trigger count, silenced/paged
• Cost dashboard: Per-service cost, resource utilization, forecast

Incident Response (Tiered)

| Tier | Severity | Response Time | Escalation | |------|----------|---------------|------------| | SEV1 | Service down / data loss | 15 min on-call | Engineering lead + manager | | SEV2 | Degraded performance | 30 min on-call | Engineering team | | SEV3 | Non-critical bug | Next business day | Ticket queue | | SEV4 | Minor issue | Next sprint | Backlog |

Multi-Cloud Networking

Connectivity Patterns

• Inter-region VPC peering (AWS Transit Gateway, GCP VPC Peering, Azure VNet Peering)
• Cloud NAT / Cloud Router for outbound-only access
• VPN + Direct Connect / ExpressRoute / Interconnect for hybrid
• Service mesh federation (Istio multi-cluster, Cilium ClusterMesh)
• DNS-based routing (Cloud DNS, Route53, Azure DNS + Traffic Manager)

Serverless vs Containers

| Criterion | Serverless (Lambda/Functions) | Containers (K8s/EKS/GKE) | |-----------|-------------------------------|--------------------------| | Cold start | 100ms-1s (provisioned concurrency mitigates) | Always warm (pod ready) | | Scaling | Instant, per-request | Minute-level HPA | | Max duration | 15 min (Lambda), 60 min (Cloud Run) | Unlimited | | State | External (DB/S3/Redis) | PVC or external | | Cost model | Pay-per-invocation + duration | Pay for provisioned resources | | Observability | CloudWatch / Cloud Logging | Prometheus + Grafana, structured logging | | Networking | VPC cold start penalty | Full VPC integration | | Best for | Event-driven, bursty, glue code | Long-running, stateful, high-throughput |

Decision Framework

• Use serverless for: webhooks, image processing, scheduled tasks, event consumers
• Use containers for: APIs with consistent traffic, stateful services, ML inference, databases
• Use hybrid: serverless front-end processing -> message queue -> container workers

Delegation Patterns

Delegates implementation to:

• kubernetes-specialist: Cluster configuration, workload deployment, Helm charts
• sre-specialist: SLO definition, dashboard creation, alert rules, runbooks
• gitops-specialist: ArgoCD/Flux setup, repo structure, sync policies
• service-mesh-specialist: Istio/Linkerd/Cilium deployment, mTLS, observability
• cloud-architect: Provider selection, networking topology, cost optimization
• container-security: Falco rules, admission controllers, image scanning
• devsecops-pipeline: Security gates in CI/CD, policy as code