Kubernetes
    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 - Versus

Updated: 2022-09-10

Spec vs Status

  • Spec: desired state
  • Status: actual state
    • contains any information we want users or other controllers to be able to easily obtain.
    • we never read our own status

Controllers vs Webhook

  • Controller: a client of Kubernetes.
  • Webhook: Kubernetes is the client and calls out to a remote service. The remote service is called a Webhook Backend.

Kind vs Resources vs Object

  • Kind = the name of an Object Schema: every object returned or accepted by the API must conform to an object schema
  • Resources = resource types + resource instances
    • Resource types are organized into API groups, and API groups are versioned. (API Groups e.g. apps/v1)
    • Every resource representation follows a certain schema defined by its kind.
  • an Object is a resource instance; the reverse is not true: not every resource represents a Kubernetes Object; Kubernetes Objects are stored in etcd.
  • Resources are named in all lower case, plural form, e.g. persistentvolumes; Kinds are named in CamelCase, singular form, e.g. PersistentVolume.
  • every API endpoint deals with objects of a certain resource type.

Often, there’s a one-to-one mapping between Kinds and resources. For instance, the pods resource corresponds to the Pod Kind. However, sometimes, the same Kind may be returned by multiple resources. For instance, the Scale Kind is returned by all scale subresources, like deployments/scale or replicasets/scale. With CRDs, however, each Kind will correspond to a single resource. resources are always lowercase, and by convention are the lowercase form of the Kind.

When we refer to a kind in a particular group-version, we’ll call it a GroupVersionKind, or GVK for short. each GVK corresponds to a given root Go type in a package.

Resources > Objects

Most of the Kubernetes API resources represent Objects.

  • Some of the resources only mandate the kind field.
  • Objects require kind, apiVersion, metadata (namespace, name, uid).

Kubernetes Objects are persistent entities, which represent the intent (desired state, spec) and the status (actual state, status)

Service Accounts vs User Accounts

Service accounts are managed within k8s (ServiceAccount resource), user accounts are managed outside of k8s.

Level triggered vs edge triggered.

Kubernetes is Level triggered instead of edge triggered. "Edge" means it monitors a change of voltage level, while "Level" means it monitors a consistent voltage level.

Edge triggered: e.g. when the hardware needed attention, it would signal the CPU "interrupt"; interrupts used to be a literal wire from the device to the CPU, the device can change the voltage on the wire, the CPU can detect changes in voltage. Problem: if the CPU doesn't detect the pulse, the interrupt doesn't get serviced.

Level triggered: the device change the voltage and keep it there until the interrupt is serviced. The CPU can't miss edges.

For kubernetes: State is more useful than events; clients can check and re-check state at any time. k8s's controller model

Reconciliation is level-based, meaning action isn't driven off changes in individual Events, but instead is driven by actual cluster state read from the apiserver or a local cache.

All nodes watch the kubernetes API and figure out what they need to do, instead of master sending out instructions

Benefits

  • no single point of failure
  • simple master components

PV vs PVC

  • PersistentVolume (PV): the actual storage.
  • PersistentVolumeClaim (PVC): a declaration of need for storage by the user.

Users use PVC to say "I need XXX TB storage" but do not care how that requirement is fulfilled (e.g. which file system or which cloud provider), so the implementation details are abstracted away.

Annotation vs Label

Both are ways to attach metadata to objects in Kubernetes.

  • Labels are for Kubernetes, annotations are for humans.
  • Labels are used in conjunction with selectors, to group a set of related resources.
  • Labels are constrained by RFC 1123 (e.g. a maximum 63 character length).
  • Annotations are used for "non-identifying information" i.e., metadata that Kubernetes does not care about. Clients such as tools and libraries can retrieve this metadata.