Skip to content

DevOps: Next Steps

This module started from a single question — "what is a container, really?" — and worked outward: the kernel mechanics in Namespaces and cgroups, the everyday tooling in Docker and Podman in Practice, automated builds in Linux in CI/CD, self-configuring instances in Linux in the Cloud, fleet-wide provisioning in Infrastructure as Code Foundations, and fleet-wide observability in Monitoring, Logging, and Automation. Every one of those topics was, underneath its own tooling, the same Linux fundamentals covered from module 1 onward — processes, namespaces, permissions, systemd, SSH, logs — applied at scale and increasingly without a human typing each command by hand. This closing article names what comes next once that foundation is solid, and how the pieces already covered connect to it.

What You Will Learn

By the end of this article you will be able to:

  • explain what an orchestrator like Kubernetes actually adds on top of the container fundamentals already covered;
  • describe GitOps as a specific, disciplined application of the IaC and CI/CD concepts from earlier in this module;
  • name the industry certifications that validate the skills this course builds toward, and what each one actually tests;
  • assess your own readiness for the LFCS-style labs that follow this module, and where to focus review first.

From "A Container" to "An Orchestrated Fleet of Containers"

Everything in Docker and Podman in Practice operates on one host at a time: docker run starts a container on the machine you typed the command on. Running dozens or hundreds of containers, across many hosts, with automatic restart on failure, automatic scaling under load, and automatic rescheduling when a host dies, is the problem container orchestrators — Kubernetes being the dominant one — solve.

Docker/Podman:  you decide which host, you run the container, you notice if it dies
Kubernetes:     you declare "I want 3 replicas of this container, healthy, always"
                the scheduler decides which hosts, restarts failures, reschedules on host loss

Crucially, Kubernetes does not replace the container fundamentals from Linux Containers and Namespaces and cgroups — it builds directly on top of them. A Kubernetes Pod is, at the kernel level, one or more containers sharing a network namespace, created by containerd or CRI-O calling runc, exactly as described in Linux Containers. A kubectl describe pod failure that says a container is stuck in CrashLoopBackOff is debugged the same way any container failure is debugged — kubectl logs, then, if that is insufficient, nsenter into the underlying container's namespaces on the actual node, using the exact technique from Namespaces and cgroups. A Kubernetes resource limit and request for CPU and memory are, underneath the YAML, cgroup cpu.max and memory.max values set on the pod's cgroup, precisely as demonstrated by hand in that same article. Nothing about orchestration is a different technology stack — it is automation layered on the same primitives, which is exactly why this module built the primitives first.

GitOps: IaC and CI/CD Combined Into One Discipline

Infrastructure as Code Foundations covered declaring infrastructure in version-controlled files; Linux in CI/CD covered pipelines that build and test automatically on every commit. GitOps is the practice of combining both into a single loop: a Git repository is the single source of truth for a system's desired state, and an automated process continuously reconciles the running system to match whatever is currently committed — with no manual terraform apply or kubectl apply run by a person at all.

Developer merges a change to the Git repo
   │
   ▼
GitOps controller (e.g., Argo CD, Flux) detects the diff
   │
   ▼
Controller reconciles the live cluster to match the repo
   │
   ▼
Drift from the repo is automatically corrected, continuously

This directly closes the drift problem raised in Infrastructure as Code Foundations: rather than drift being detected only the next time someone happens to run terraform plan, a GitOps controller checks continuously and reconciles automatically. The trade-off is the same one raised there — an emergency manual fix applied directly to the running system, with no corresponding commit, gets silently reverted by the very automation meant to keep things consistent, which is why GitOps teams treat "commit the fix to Git" as part of the incident response itself, not an optional follow-up.

Where the Certifications Fit

Three certifications map closely to the skills this course, and this module in particular, builds toward — worth knowing what each one actually validates, since they test different things:

  • LFCS (Linux Foundation Certified System Administrator) validates exactly the single-host administration skills covered from this course's start through module 14: users, permissions, storage, networking, systemd, troubleshooting. The LFCS labs module immediately following this one is built specifically as hands-on practice for this exam's style of task-based, live-system questions.
  • LFCE (Linux Foundation Certified Engineer) builds on LFCS with a heavier emphasis on networking services, security, and the kind of automation covered starting from Cron and Automation through this module.
  • CKA (Certified Kubernetes Administrator) assumes the container fundamentals from this module as a prerequisite and tests Kubernetes cluster administration specifically — the natural next certification once orchestration, not just containers, becomes the daily work.

None of these substitute for the others' scope: a CKA holder without solid Linux fundamentals will struggle the moment a cluster problem turns out to be a node-level kernel, cgroup, or networking issue rather than a Kubernetes-level one — which is a common, real failure mode, and precisely the gap this course is structured to prevent by building the Linux foundation first.

Interview angle: "you know Kubernetes — do you actually know Linux?"

This question, in some form, comes up often for candidates whose experience is entirely container-and-orchestrator-shaped with no lower-level troubleshooting behind it. A strong answer demonstrates exactly the connection this article just drew: that a Kubernetes networking problem is frequently a veth/network-namespace problem underneath, that a pod being OOM-killed is a cgroup memory.max event checkable with the same dmesg and cgroup-file inspection covered in Namespaces and cgroups, and that "restart the pod and hope" is not a diagnosis. Interviewers ask this specifically to filter for candidates who can debug below the orchestrator's abstraction layer when the abstraction itself is the thing failing.

Assessing Your Own Readiness

Before moving into the LFCS labs that follow this module, a fair self-check is whether you can do the following without looking anything up:

  • explain the difference between a namespace and a cgroup, and demonstrate both with unshare and a manual cgroup limit;
  • build a Dockerfile, run the resulting image, and persist its data with a volume;
  • write an idempotent Ansible task and explain why a changed result on a second run indicates a problem;
  • read journalctl -p err output and connect it to a specific failing systemd unit;
  • explain, out loud, why a firewall rule needs the SSH allow rule confirmed before ufw enable, from Server Hardening.

If any of these feel shaky, the corresponding article — most are linked directly above — is worth a second pass before the labs module, which assumes this module's material as a working foundation rather than re-teaching it.

Common Mistakes

  • Learning Kubernetes YAML syntax without first understanding what a container actually is. As shown above, most real Kubernetes troubleshooting eventually lands back on the container and kernel fundamentals from earlier in this module — skipping them creates a ceiling on how deep any orchestrator-level debugging can go.
  • Adopting GitOps tooling without first having reliable, idempotent IaC underneath it. GitOps automates applying the desired state continuously; it does not fix an unreliable or non-idempotent configuration — it just applies that unreliable configuration more often and with less human review.
  • Chasing certifications in the wrong order. Attempting CKA without solid LFCS-level fundamentals tends to produce exactly the "knows the orchestrator, not the OS" gap the interview angle above describes.
  • Treating this module as the finish line rather than a foundation. Container orchestration, service mesh, and GitOps are each large enough to be their own multi-month learning tracks — this module's job was making sure the Linux ground underneath all of them is solid, not covering them exhaustively.

Exercises

  1. Without referring back to the article, explain in your own words the difference between what a namespace restricts and what a cgroup restricts, then verify your answer against Namespaces and cgroups.
  2. Pick one of the three certifications discussed above that matches your current goals, and list the three topics from this entire course you feel least confident about relative to that certification's published exam objectives.
  3. Describe, in a short paragraph, what would need to be true about your IaC (from Infrastructure as Code Foundations) before adopting a GitOps workflow would be a safe next step rather than a premature one.
  4. Proceed to the LFCS labs module and attempt the first troubleshooting scenario without hints; note which specific earlier article you needed to revisit, if any.

Summary

Container orchestration, GitOps, and the certification paths built around them are not a separate subject from what this course has covered — they are automation and scale layered directly on top of the namespaces, cgroups, containers, IaC, and CI/CD fundamentals this module worked through in order, and debugging any of them eventually requires being able to drop back down to that same foundation. The LFCS labs that follow are where that foundation gets tested directly, under the same kind of live-system, task-based conditions the LFCS exam itself uses.

References