Kubernetes - Overview
    Kubernetes - Objects
    Kubernetes - API Extensions
    Kubernetes - apimachinery
    Kubernetes - Container Runtimes (CRI)
    Kubernetes - Storage (CSI)
    Kubernetes - Networking (CNI)
    Kubernetes - Ecosystem
    Kubernetes - Tools
    Kubernetes - kubectl
    Kubernetes - client-go
    Kubernetes - Source Code
    Kubernetes - Kind
    Kubernetes - kubeconfig
    Kubernetes - Versus

Kubernetes - Objects

Updated: 2022-09-10
  • When you create a Service, it creates a corresponding DNS entry.

  • CustomResourceDefinition (CRD): to extend the Kubernetes API.

Object vs kind vs resources

  • A Kubernetes object is a persistent entities in the Kubernetes system.
  • A Kubernetes resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, the built-in pods resource contains a collection of Pod objects.

The most important objects


Use controllers to manage pods, do not manage pods directly

Deployment Controller -> ReplicaSet -> Pods

In the simplest cases, each pod just have 1 container, but with sidecar, each pod has 2 containers.


A service provides an unchanging IP, used between frontend deployment and backend deployment.

A service is responsible for enabling network access to a set of pods.

Each service gets a ClusterIP allocated, one ip to get traffic to all the endpoints.

service type:

  • ClusterIP: cluster scoped IP, used internally, the service is not exposed to resources outside the cluster.
  • NodePort: maps a node port to a service; can be accessed from outside the cluster by requesting <NodeIP>:<NodePort>
  • LoadBalancer: Exposes the Service externally using a cloud provider's load balancer.

Services will create Endpoints, one for each healthy pod. (I.e. each Endpoint is a ip:port pointing to the Pod that is part of this Service.)


A deployment is responsible for keeping a set of pods running.


cronjob controller will create jobs


Deployment vs Service

  • A deployment without a service: the deployment could be scaled up and down and pods could be replicated. Each pod could be accessed individually via direct network requests, rather than abstracting them behind a service.
  • A service without a deployment: create each pod individually then the service routes network requests to the pods.

Deployment vs StatefulSet vs DaemonSet

  • Deployment for stateless services, e.g. web servers.

    • Pod replicas in deployments share the same persistent volume.
  • StatefulSet is for stateful services, e.g. db.

    • Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

    • If a volume is configured, each pod will be provision its own persistent volume

    • Better use headless services (service without an IP address), clients can connect directly to what lies behind it. Headless services has clusterIP: None.

      kind: Service
        clusterIP: None
  • DaemonSet: one copy per worker node.

Service vs Pod

  • Service has a stable IP address that lasts for the life of the service; each pod has its own address but pods may come and go and their IP addresses change.
  • Service provides load balancing across pods.


applications, app.k8s.io/v1beta1, https://github.com/kubernetes-sigs/application


crd, apiextensions.k8s.io/v1



  • create a KIND cluster
  • use the KIND cluster to bootstrap an admin cluster
  • admin cluster manages the control planes for tenant admin cluster
  • tenant cluster further manages tenant user clusters