Concepts

Core Concepts

Overview

Kuberinfo

Kube-master

  • kube-apiserver: The Kubernetes API server validates and configures data for the api objects which include pods, services, replicationcontrollers, and others. The API Server services REST operations and provides the frontend to the cluster’s shared state through which all other components interact.,

  • kube-controller-manager: In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.

  • kube-scheduler:The Kubernetes scheduler is a policy-rich, topology-aware, workload-specific function that significantly impacts availability, performance, and capacity.

kube-slave

  • Kubelet: communicates with the Kubernetes Master.
  • kubeproxy: a network proxy which reflects Kubernetes networking services on each node.

Readmore

  • kube-apiserver
  • etcd
  • kube-scheduler
  • kube-controller-manager
  • cloud-controller-manager
  • kubelet
  • kube-proxy
  • CRI
  • DNS
  • Container resource monitoring
  • Cluster-level Logging

Objects

Namespaces

NOTE: owever namespace resources are not themselves in a namespace. And low-level resources, such as nodes and persistentVolumes, are not in any namespace.

  • default The default namespace for objects with no other namespace
  • kube-system The namespace for objects created by the Kubernetes system
  • kube-public This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.

kubectl create ns NAME

Labels and Selectors

Labels are key/value pairs that are attached to objects. Used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs.

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Also

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

Unlike names and UIDs, labels do not provide uniqueness. In general, we expect many objects to carry the same label(s).Via a label selector, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.

API currently supports two types of selectors: equality-based and set-based. A label selector can be made of multiple requirements which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as a logical AND (&&) operator.

inequality-based

Equality- or inequality-based requirements allow filtering by label keys and values. =,==,!=. The first two represent equality (and are simply synonyms), while the latter represents e.g: the sample Pod below selects nodes with the label “accelerator=nvidia-tesla-p100”.

inequalityapiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100
Set-based

Set-based label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: in,notin and exists (only the key identifier). For example:

  • environment in (production, qa): The first example selects all resources with key equal to environment and value equal to production or qa
  • tier notin (frontend, backend): tier notin (frontend, backend):
  • partition: he third example selects all resources including a label with key partition; no values are checked.
  • !partition: The fourth example selects all resources without a label with key partition; no values are checked
  • partition,environment notin (qa): filtering resources with a partition key (no matter the value) and with environment different than qa can be achieved.

NOTE:

  • selector is a general form of equality since environment=production is equivalent to environment in (production); similarly for != and notin -Set-based requirements can be mixed with equality-based requirements. For example: partition in (customerA, customerB),environment!=qa.
In API
  • equality-based requirements: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
  • set-based requirements: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29
In kubectl

kubectl get pods -l environment=production,tier=frontend

kubectl get pods -l 'environment in (production),tier in (frontend)

kubectl get pods -l 'environment in (production, qa)

kubectl get pods -l 'environment,environment notin (frontend)'

Annotations

You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata.

Field Selectors

Field selectors let you select Kubernetes resources based on the value of one or more resource fields. Here are some example field selector queries:

kubectl get pods --field-selector status.phase=Running

Supported field selectors vary by Kubernetes resource type. All resource types support the metadata.name and metadata.namespace fields.

can use the =, ==, and != operators with field selectors

kubectl get services --all-namespaces --field-selector metadata.namespace!=default

As with label and other selectors, field selectors can be chained together as a comma-separated list dd kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

Key Description Example Type
app.kubernetes.io/name The name of the application mysql string
app.kubernetes.io/instance A unique name identifying the instance of an application wordpress-abcxzy string
app.kubernetes.io/version The current version of the application (e.g., a semantic version, revision hash, etc.) 5.7.21 string
app.kubernetes.io/component The component within the architecture database string
app.kubernetes.io/part-of The name of a higher level application this one is part of wordpress string
app.kubernetes.io/managed-by The tool being used to manage the operation of an application helm string

e.g:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm