# Mastering Cloud Infrastructure: A Practical Guide to Kubernetes, AWS, and Linux

> Explore this comprehensive DevOps fundamentals guide covering Kubernetes scheduling, AWS EC2 and VPC provisioning, and essential Linux commands.

- Canonical URL: https://coreiten.com/en/article/mastering-cloud-infrastructure-a-practical-guide-to-kubernetes-aws-and-linux
- Language: en
- Section: Projects
- Author: Sami
- Published: 2026-07-25T10:02:46+03:00
- Modified: 2026-07-25T10:02:46+03:00
- Publisher: CoreITen (https://coreiten.com)
- Keywords: DevOps fundamentals guide, Kubernetes scheduling, AWS EC2, AWS VPC, Linux commands, Kubernetes Services, OOMKilled

---

Mastering the foundational pillars of cloud engineering can feel overwhelming, but breaking down complex systems into actionable steps accelerates the learning curve. This DevOps fundamentals guide demystifies essential cluster management, operating system configurations, and cloud provisioning to help you build resilient infrastructure. Whether you are configuring virtual networks or troubleshooting pod evictions, understanding the core mechanics of Kubernetes, AWS, and Linux is critical for any modern deployment.

### Kubernetes Services and Traffic Routing

In a Kubernetes environment, exposing applications reliably requires a solid understanding of Services. The default Service type is **ClusterIP**, which provides a stable virtual IP and load balances traffic exclusively across matching Pods inside the cluster using labels. For external access, a **NodePort** exposes the application on a specific port across every Kubernetes node, utilizing a port range of 30000 - 32767.

When configuring a NodePort, traffic flows through a specific pipeline. It requires defining the **containerPort** (where the app listens), the **targetPort** (where the Service forwards traffic), the internal **port**, and the external **nodePort**. In cloud environments like AWS, Azure, and GCP, engineers typically use a **LoadBalancer** Service, which automatically provisions a cloud load balancer to route internet traffic directly to the Service and down to the Pods.

```plaintext
Client   ↓
NodeIP:NodePort   ↓
Service Port   ↓
TargetPort   ↓
ContainerPort
```

### Mastering Kubernetes Scheduling and Resource Limits

Controlling where Pods run is a fundamental aspect of cluster stability. Administrators use Taints to keep Pods away from specific nodes, while Tolerations allow specific Pods to ignore those taints. The effects vary: **NoSchedule** prevents new Pods from being placed, **PreferNoSchedule** acts as a soft restriction, and **NoExecute** actively evicts existing Pods that lack the proper toleration.

```bash
kubectl taint nodes <node-name> key=value:NoSchedule
```

Conversely, Node Affinity dictates where a Pod *should* run. By labeling a node (e.g., `disktype=ssd`), you can enforce placement using **requiredDuringSchedulingIgnoredDuringExecution** (a strict requirement) or **preferredDuringSchedulingIgnoredDuringExecution** (a soft preference). Additionally, every Pod must define resource requests and limits to maintain cluster health.

```yaml
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"
```

Requests guarantee minimum resources for scheduling, while limits cap maximum consumption. If a CPU limit is exceeded, the process is throttled. However, if a memory limit is exceeded, the container is abruptly terminated with an **OOMKilled** error.

### How to Solve a Kubernetes Scheduling Conflict

Understanding these concepts is best demonstrated through real-world troubleshooting. Consider a scenario where a Pod fails to schedule because the control-plane node has a taint, and the only available worker node lacks sufficient memory for the Pod's requested resources. Furthermore, the Pod explicitly requires an SSD via a `nodeSelector`.

- **Step 1:** Label the target worker node to satisfy the selector requirement using the command: `kubectl label node worker1 disk=ssd`.
- **Step 2:** Analyze the resource constraints and identify that the Pod is requesting more memory than the worker node can physically provide.
- **Step 3:** Reduce the Pod's memory request in the manifest file. Once adjusted, the scheduler will find the node suitable and successfully deploy the Pod.

### Essential Linux Commands and Environment Variables

Effective DevOps relies heavily on Linux proficiency. Navigating the file system requires commands like `mkdir <folder_name>` to create directories, `cd` to navigate, `pwd` to print the working directory, and `ls` to list contents. For deletion, `rm -rf <folder_name>` recursively and forcefully removes directories, though it must be used with extreme caution.

Managing environment variables is equally critical. You can display all variables using `env`, check a specific one with `echo $VARIABLE_NAME`, or set a temporary one using `export VARIABLE_NAME=value`. To make variables persistent, the export command must be added to shell configuration files like `~/.profile`, `~/.bashrc`, or `~/.zshrc`.

```bash
export PS1="\u@\h:\w\$ "
```

You can also customize your terminal prompt by modifying the `PS1` variable. In the example above, `\u` represents the username, `\h` is the hostname, `\w` is the current working directory, and `\$` displays a standard prompt symbol.

### Provisioning AWS EC2, VPC, and S3 Resources

Moving to the cloud layer, AWS provides the foundational infrastructure for these clusters. Launching an Elastic Compute Cloud (EC2) instance involves selecting an Amazon Machine Image (AMI), such as the Ubuntu Quick Start or Windows Server. For small workloads and Free Tier testing, the **t3.micro** instance type is highly suitable. The launch configuration also requires setting up a key pair, networking, storage, and a security group.

These instances operate within a Virtual Private Cloud (VPC), which acts as an isolated virtual network. Every VPC is defined by a CIDR block (for example, `10.0.0.0/16`) that dictates its IP address range. It is important to note that VPCs are regional resources, meaning they exist entirely within a single AWS Region. Alongside compute and networking, services like Amazon S3 provide the necessary object storage to complete the foundational cloud architecture.

### Why Abstraction Demands Deeper OS Knowledge

The intersection of Kubernetes scheduling, Linux environments, and AWS provisioning highlights a critical reality in modern DevOps: abstraction does not eliminate the need for foundational knowledge. When a Pod crashes with an OOMKilled error, simply restarting it via a Kubernetes dashboard is insufficient. The engineer must understand how the Linux kernel manages memory limits and how the underlying AWS EC2 instance is provisioned to permanently resolve the bottleneck.

Furthermore, the reliance on cloud-native load balancers and automated scaling can create a false sense of security. As demonstrated by the scheduling conflict scenario, a single misconfigured taint or an overly ambitious memory request can halt deployments entirely. Mastering the command line and understanding the exact traffic flow from a VPC CIDR block down to a container port remains the ultimate safety net for infrastructure reliability.

## Sources

- [medium.com](https://shreyajung.medium.com/day-1-of-devops-85ed250588e7)