Master Kubernetes Basics: From Pods to Deployments and kubectl

Preface

The author switched from front‑end development to back‑end development in September and was immediately required to understand Kubernetes (K8s) for a project with tight deadlines. Existing "K8s beginner" articles were confusing, so this series aims to help newcomers grasp K8s concepts and foster discussion.

Article organization:

What K8s is, its purpose, architecture, and key components such as API Server, Scheduler, Controller Manager, and etcd.

Important K8s concepts: API objects like Pod, Deployment, Service, etc.

How to configure kubectl.

How to use kubectl to deploy services.

I. K8s Overview

1.1 What is K8s?

Kubernetes is an open‑source system for managing containerized applications across multiple hosts, providing mechanisms for deployment, maintenance, and scaling.

In plain language, K8s automates the operation and management of a cluster of Docker containers.

1.2 Why K8s?

Traditional deployment places binaries on a server and runs a script to start them, with a watchdog to restart if needed. When traffic spikes, you manually add servers and load balancers. K8s solves the problem by automating deployment, updates, scaling, and removal of services.

1.3 How does K8s work?

K8s follows a master‑worker (master‑node / worker‑node) model. The master node runs core components (API Server, Scheduler, Controller Manager, etcd) that schedule and manage workloads. Worker nodes run the actual containers via components such as Kubelet, Kube‑Proxy, container runtime, logging layer, and add‑ons.

Key master components:

API Server : entry point for all requests.

Scheduler : selects suitable worker nodes for new pods.

Controller Manager : monitors and adjusts pod state, e.g., ensuring the desired number of replicas.

etcd : stores cluster configuration and state.

Key worker components:

Kubelet : reports node status and executes commands from the master.

Kube‑Proxy : handles network traffic and load balancing.

Container Runtime : provides the Docker (or other) environment.

Logging Layer : collects resource usage metrics.

Add‑Ons : optional plugins that extend functionality.

II. Important K8s Concepts

2.1 Pod

A Pod is the smallest deployable unit in Kubernetes. It groups one or more containers that share network, storage, and execution context. Containers in the same Pod can communicate via localhost and share volumes, while containers in different Pods cannot.

Example Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm","1","--vm-bytes","150M","--vm-hang","1"]
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}

Key fields: apiVersion: API version (usually v1). kind: object type, here Pod. metadata: name and namespace. spec: container list, resources, command, args, volume mounts, and volumes.

2.2 Volume

Volumes provide persistent storage for Pods. A volume object defines the storage, while volumeMounts specify where a container mounts it. A volume must be defined before it can be mounted.

2.3 Container

Containers are the actual runnable units inside a Pod. Types include standard application containers, init containers, sidecar containers, and ephemeral containers. Most deployments use standard application containers.

2.4 Deployment and ReplicaSet

A Deployment manages Pods and ReplicaSets, ensuring the desired number of replicas are running. It acts like a foreman, creating and updating ReplicaSets as needed. A ReplicaSet maintains a stable set of replica Pods; it is controlled by a Deployment.

2.5 Service and Ingress

Service abstracts a set of Pods and provides a stable network endpoint with load balancing and DNS. Ingress manages external HTTP(S) access to Services, offering load balancing, SSL termination, and name‑based virtual hosting.

2.6 Namespace

Namespaces partition a single physical cluster into multiple virtual clusters, isolating resources. Objects like Pods, Deployments, and Services exist within a namespace, allowing the same name to be reused in different namespaces.

III. Configuring kubectl

3.1 What is kubectl?

kubectl

is the command‑line tool for interacting with a Kubernetes cluster. It reads configuration from $HOME/.kube/config or a file specified via --kubeconfig or the KUBECONFIG environment variable.

3.2 How to configure kubectl?

Step 1: Obtain a kubeconfig file (example shown in the article). The file contains clusters, users, contexts, and the current context.

Step 2: Make the configuration available to kubectl using one of three methods:

Pass --kubeconfig=${CONFIG_PATH} on every command (or create an alias).

Set the KUBECONFIG environment variable to include the file.

Copy or merge the file into $HOME/.kube/config (using kubectl config view --flatten for merging).

Step 3: Choose the correct context with kubectl config use-context ${CONTEXT_NAME} or edit a context with kubectl config set-context. The context determines the cluster, user, and namespace used by default.

IV. Deploying Services with kubectl

4.1 Deploy a Pod

Prepare a Pod YAML (as shown above) and run: kubectl create -f ${POD_YAML} If the YAML is invalid, kubectl reports the offending line. After fixing errors, re‑run the command.

4.2 Deploy a Deployment

Example Deployment YAML:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: rss-site
  namespace: mem-example
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: memory-demo-ctr
        image: polinux/stress
        resources:
          limits:
            memory: "200Mi"
          requests:
            memory: "100Mi"
        command: ["stress"]
        args: ["--vm","1","--vm-bytes","150M","--vm-hang","1"]
        volumeMounts:
        - name: redis-storage
          mountPath: /data/redis
      volumes:
      - name: redis-storage
        emptyDir: {}

Deploy with: kubectl create -f ${DEPLOYMENT_YAML} K8s automatically creates the associated ReplicaSet and Pods.

V. Viewing, Updating, and Deleting Services

5.1 Viewing

Use kubectl get or kubectl describe with the appropriate resource type and namespace, e.g.:

kubectl get pod -n=oona-test
kubectl get deployment -n=oona-test
kubectl get pod --all-namespaces

Add -o wide for more details.

5.2 Updating / Editing

Two methods:

Modify the YAML and apply: kubectl apply -f ${YAML}.

Edit live resources: kubectl edit ${RESOURCE} ${NAME}. Only a limited set of fields (e.g., container image) can be changed; other changes require recreation.

5.3 Deleting

Delete a Pod: kubectl delete pod memory-demo Delete a Deployment (which also removes its Pods): kubectl delete deployment ${DEPLOYMENT_NAME} If a Pod refuses to terminate, force delete with --force --grace-period=0.

VI. Troubleshooting with kubectl

6.1 Deployment failures

Inspect events with: kubectl describe pod ${POD_NAME} The Events section shows why a pod failed (e.g., image pull errors).

6.2 Runtime issues

View container logs: kubectl logs ${POD_NAME} -c ${CONTAINER_NAME} Enter a container for interactive debugging:

kubectl exec -it ${POD_NAME} -c ${CONTAINER_NAME} -- /bin/sh

Further diagnostics may require additional tools.

Conclusion

The article aims to give Kubernetes newcomers a quick, practical understanding of core concepts, deployment workflows, and troubleshooting techniques, encouraging deeper exploration of K8s’s sophisticated architecture.

本文转载自：「腾讯技术工程」，原文：https://tinyurl.com/ya3ennxf，版权归原作者所有。