Cloud Native DevOps with Kubernetes, read against EKS
Cloud Native DevOps with Kubernetes, read against EKS
Chapter 11, Security and Backups
| book says | page | correct, and on EKS |
|---|---|---|
| check whether RBAC is enabled; GKE users get a token from gcloud | 227–228 | RBAC is always on. People authenticate with IAM, mapped by access entries (CreateAccessEntry, AssociateAccessPolicy, authentication mode API, all in the API model); the cheat sheet has the commands |
| "Apps … don't need any RBAC permissions … the default service account … has no roles" | 230 | still true for RBAC. For AWS permissions, give each ServiceAccount its own role through Pod Identity; never the node role |
| Clair, Aqua MicroScanner, kube-hunter, Anchore Engine | 231–232 | Clair continues (v4); MicroScanner was replaced by Trivy; Anchore Engine was retired in favour of Syft and Grype; check kube-hunter's status. On AWS, ECR enhanced scanning (scan type ENHANCED, API model) runs Amazon Inspector on push and continuously |
| back up etcd, or use a provider that does | 233–234 | EKS runs etcd; you cannot and need not snapshot it |
| Velero with BackupStorageLocation and VolumeSnapshotLocation; "each Velero backup is complete … not incremental" | 235–236 | Velero is current; the AWS plugin is required, and credentials should come from Pod Identity. EBS snapshots and Velero's Kopia file-system backups are incremental underneath. The AWS Backup API model now lists EKS as a resource type, with object-level backup and restore failure codes; check what it captures in your region. See Backing up Kubernetes onto AWS |
| restoring skips resources that already exist | 236–237 | the default; velero restore create --existing-resource-policy=update overwrites (check against your Velero version) |
| kubectl get componentstatuses | 238 | deprecated since 1.19 (the API's own description says so); use kubectl get --raw='/readyz?verbose' and EKS cluster insights (ListInsights) |
| Kubernetes Dashboard, Weave Scope, kube-ops-view | 241–244 | the Dashboard was archived in January 2026, and Weaveworks closed in 2024. Use the EKS console's resources view, Headlamp, or k9s |
| node-problem-detector: "Kubernetes currently does not take any action" | 243 | on EKS, the node monitoring agent plus node auto repair replaces unhealthy managed nodes (nodeRepairConfig in the API model) |
Chapter 12, Deploying Kubernetes Applications
| book says | page | correct, and on EKS |
|---|---|---|
| Chart.yaml with only name, sources and version | 247 | Helm 4.3 still installs it, but helm lint fails: "apiVersion is required." Use apiVersion: v2 |
| dependencies in requirements.yaml, without a repository | 250 | apiVersion: v2 charts declare dependencies in Chart.yaml, each with a repository; Helm 4.3 lists the book's as missing |
| --set "isn't in the spirit of infrastructure as code"; use values files | 251–252 | still right, and it is how Argo CD applications should carry values |
| helm-monitor for metric-driven rollback | 253 | check; Argo Rollouts analysis runs (or Flagger) against AMP do this |
| Sops-decrypt into a temp file, then helm upgrade | 254–255 | works; the helm-secrets plugin or Argo CD with a Sops plugin avoid the plaintext file |
| Helmfile, Landscaper, Helmsman | 255–258 | Helmfile is maintained under helmfile/helmfile; for a whole cluster's applications on EKS, the Argo CD capability with ApplicationSets (Argo CD on AWS) |
| ksonnet | 258–259 | discontinued in 2019. Jsonnet lives on (Tanka), and Kapitan is maintained |
| kustomize as a separate binary | 260 | built into kubectl as kubectl apply -k since 1.14 |
| kubeval in the pipeline | 261–262, 281 | kubeval is unmaintained; kubeconform is the replacement. Server-side kubectl apply --dry-run=server against a real cluster is stricter still |
| Ansible's k8s module | 261 | kubernetes.core.k8s |
Chapter 13, Development Workflow
The chapter's rollout-strategy section is correct and still the clearest short explanation of
maxSurge and maxUnavailable (pp. 267–268). On AWS:| book says | page | correct, and on EKS |
|---|---|---|
| Draft from Microsoft | 265 | the original Draft was archived; Skaffold and Telepresence remain, with Telepresence now a CNCF project |
| Knative "integrates with … Istio" | 265 | Knative no longer needs Istio (Kourier and others serve it), and its build component became Tekton |
| maxSurge/maxUnavailable default "25%, or 1, depending on your Kubernetes version" | 268 | 25% in apps/v1 |
| blue/green by switching a Service selector; Service on port 8080 | 268–269 | still works; note the demo listens on 8888, not 8080. On EKS, Argo Rollouts drives blue/green and canary through ALB weighted target groups |
| canary with Istio for weighted routing | 269 | ALB weights through Argo Rollouts, or Gateway API HTTPRoute weights; no mesh needed for north–south |
| "helm.sh/hook-weight": "0 | 272 | missing closing quote; "0" |
Chapter 14, Continuous Deployment
The principle (p. 275): the artifact you test and promote "is not the source code, but the container", tagged with its Git SHA (p. 281). This is the book's dev/prod-parity rule, and it carries over directly. The example does not: Cloud Build,
gcr.io and a GKE Developer IAM role.| book's pipeline step | page | on AWS |
|---|---|---|
| Cloud Build trigger on push | 282 | CodePipeline V2 with a CodeConnections source (CodeCommit is closed to new customers) |
| build the test stage, run go test, build the app image | 279–280 | CodeBuild, with native ARM compute if you ship Graviton images |
| push to gcr.io/$PROJECT_ID/demo:$COMMIT_SHA | 281 | ECR with immutable tags and enhanced scanning as the gate |
| helm template | kubeval | 281 | helm template | kubeconform |
| Cloud Build runs helm upgrade --install with cluster credentials | 285 | prefer pull: CI updates the image tag in git and the Argo CD capability syncs; if you must push, give CodeBuild an access entry scoped to the namespace |
| Flux "watching … a container registry"; Keel; Gitkube; Docker Hub automated builds | 277–278 | Flux v1 is archived and Flux v2 (CNCF graduated) is Git-driven, with optional image automation; Docker Hub autobuilds are a paid feature; check Keel and Gitkube |
| official mozilla/sops image "about 800 MiB" | 287 | the lesson (small build images) stands; the image has moved with the project |
Chapter 15, Observability and Monitoring
The chapter's argument is that "Cloud native applications are never up" (p. 293), that nines don't matter if users aren't happy, and that external checks come first. All of it holds. On AWS:
| book says | page | correct, and on AWS |
|---|---|---|
| ELK, Splunk, Loggly for logs | 293–294 | Fluent Bit (part of the CloudWatch observability add-on) to CloudWatch Logs, or to OpenSearch |
| Zipkin, Jaeger, LightStep; "the OpenTracing framework … aims to provide a standard" | 297 | OpenTracing was archived and merged into OpenTelemetry; on EKS, the ADOT add-on, with X-Ray or any OTLP backend |
| use Uptime Robot or Pingdom; "don't build your own" | 300–301 | still right; the AWS-managed versions are CloudWatch Synthetics canaries and Route 53 health checks (both in the API models) |
| readiness probes that check dependencies, so a failure cascades up a chain of services as a "circuit breaker" | 301–302 | be careful. If every replica fails readiness on a shared dependency at once, the Service has no endpoints and the ALB has no healthy targets, so a blip becomes an outage of that tier. Keep liveness free of dependencies, check only what this Pod alone can fix in readiness, and put the breaker and fallback in the application; Microservices resilience on AWS |
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article