liveBook · Manning

Kubernetes resource

As explained in Machine Learning Platform Engineering

A Kubernetes object is a declarative resource record that describes the desired or observed state of an application or infrastructure component.

A Kubernetes resource is a named object used to deploy or manage something in a cluster. For a containerized API, a Pod holds the application container; a ReplicaSet maintains a specified number of Pods; and a Deployment manages the ReplicaSet and application updates. Defining these objects in YAML makes the deployment repeatable. section 3.3.3

Read a workload manifest from its top-level fields:

  • apiVersion identifies the resource API; kind selects the object type, such as Pod or Deployment. section 3.3.3
  • metadata names the object and can hold labels. Labels let other resources select the intended Pods. section 3.3.3
  • spec describes the workload: a Pod specifies containers and images; a ReplicaSet or Deployment also specifies a Pod template, replica count, and label selector. section 3.3.3
Listing 3.6 deployment.yaml: creating a deployment 
apiVersion: apps/v1    #1
kind: Deployment    #2
metadata:
  name: joker-deployment    #3
  labels:
      app: fast-api
spec:
  template:    #4
    metadata:
      name: joker
      labels:
          app: fast-api
    spec:
      containers:
      - name: hello-joker
        image: varunmallya/hello-joker:v1
        ports:
        - containerPort: 8083
  replicas: 3
  selector:
    matchLabels:
      app: fast-api

This Deployment manifest ties three replicas to a Pod template through matching labels. Its container image can be changed and the manifest applied again to initiate an update. section 3.3.3

Apply, inspect, and recover

Create a resource with `kubectl create -f deployment.yaml`; use `kubectl get deployments` to check availability. After changing the image, run `kubectl apply -f deployment.yaml` and inspect rollout events with `kubectl describe deployment joker-deployment`. If the update fails, `kubectl rollout undo deployment/joker-deployment` reverts it. For a Pod reporting `ErrImagePull`, inspect it with `kubectl describe pod joker`; use `kubectl logs joker` to check application output. section 3.3.3

Resources also organize and configure the application. A Namespace scopes resource names; resources without an explicit namespace go into `default`. Set `metadata.namespace` to place a Deployment or Service elsewhere, and use `kubectl get pod -n funny` to inspect that namespace. ConfigMaps hold configuration data, while Secret manifests hold base64-encoded data that can be retrieved and decoded. These are additional resource kinds, not fields of the Deployment. section 3.3.5

How Machine Learning Platform Engineering covers it

How deep it goes
Works through YAML fields and kubectl operations for several resource kinds, while leaving the complete object catalog out of scope.
Examples
Shows a FastAPI Pod, three-replica Deployment, namespace-scoped resources, a ConfigMap, and a Secret through YAML and kubectl output.
What it assumes
Starts from an existing Docker image of a FastAPI application and introduces Pod definitions before larger workload resources.
What you can do after
Operate/configure it with YAML and kubectl to create, inspect, update, troubleshoot, and roll back application resources.
How it connects
Connects Pods, ReplicaSets, Deployments, Services, Namespaces, ConfigMaps, Secrets, labels, and container images.
Cover of Machine Learning Platform Engineering
liveBookmanning.com
Read Machine Learning Platform Engineering on liveBook Get the book at manning.com

Also explained in

Compare how 5 books explain Kubernetes resource →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Machine Learning Platform Engineering. The section links point to the parts of the book it draws on.