Kubernetes Objects

Kubernetes Objects represent the desired state of the cluster and are created by configuration. These objects can be created, modified, or deleted via the Kubernetes API.

Kubernetes Objects describes the following:
       ●    what containerized applications are running and on which nodes.
       ●    resources available to these applications.
       ●    the policies on how these applications behave such as restart policies, upgrades, and
             fault-tolerance.

Objects can be selected using any of the following:
       ●    Label selectors
       ●    Namespaces
       ●    Field Selectors

Object Names and IDs

• Each object in the cluster has a unique Name for that resource.
• Each object has a UID that is unique across the whole cluster.

Names

• Names are client-provided string that refer to an object. It follows a resource URL format such as: /api/v1/pods/unnamed.
• For each kind of object, one name can be assigned to that object. If an object is deleted, the name can be assigned to the new object.
• Names must be unique across all API versions of the same resource.
• These are the commonly used name constraints:

1. DNS Subdomain Names
      ●    contains no more than 253 characters
      ●    contains only lower case alphanumeric characters, -, or .
      ●    starts and ends with an alphanumeric character

2. RFC 1123 Label Names
      ●    contains at most 63 characters
      ●    contain only lower case alphanumeric characters, or –
      ●    starts and ends with an alphanumeric character

3. RFC 1035 Label Names
      ●    contains at most 63 characters
      ●    contain only lower case alphanumeric characters, or –
      ●    starts with an alphabetic character
      ●    ends with an alphanumeric character

Path Segment Names

• Some resource types require their names to be encoded as a path segment. The name may not be “.” or “..” and the name may not contain “/” or “%”.

Kubernetes Object Management

There are three techniques in managing Kubernetes Objects:
       1.   Imperative commands
       2.   Imperative object configuration
       3.   Declarative object configuration

Imperative commands

• Imperative commands are used to operate directly on live objects in a cluster. Commands can be issued via kubectl or any equivalent Kubernetes client.
• Advantages

       ● Commands can be issued via one action word (for example: create, deploy).
       ● Cluster changes can be done in a single step.
       ● Simplest to use among the three

• Disadvantages
         ● does not easily integrate with a review process
         ● does not easily allow for an audit trail
         ● does not provide a record of the changes except for its effect
         ● does not allow for an organization to have a common template.
• Example of Imperative command:
                $ kubectl create deployment nginx –image nginx

Imperative object configuration

• Imperative object configuration uses a YAML or JSON file. The configurations are described in he file.
• Advantages

      ● Configuration can be stored in a source control system.
      ● Can be integrated with a review process.
      ● Allows for an audit trail.
      ● Allows for an organization to have a common template

• Disadvantages
         ● Requires basic understanding of the object schema.
         ● Requires writing of configuration file.
         ● Works best on files, not directories.
         ● Needs to be sync with any Imperative commands.
• Example of Imperative object configuration:

• The above .yaml file can saved into disk and applied with the following command: $ kubectl apply -f [yaml file]

Declarative object configuration

• Declarative object configuration refers to a collection of files that describes the object. The configuration files do not define the operations to be taken. Instead, the create, update, and delete operations are automatically detected per-object by kubectl.
• Advantages

       ●  Can be used with directories, where different operations might be needed for different
           objects.
       ● Changes made directly to live objects are retained. Optionally, these changes can be
           merged back into the file.

• Disadvantages
         ● The most complicated to use
         ● Harder to debug
         ● There is a potential for complicated merge and patch operations.
• Command to process declarative object configuration: $ kubectl apply -f configs/

Labels and Selectors

• Labels can be attached to objects. A single label is a key/value pair. Multiple labels can be defined per object. Each key in an object must be unique.
• Labels are used to identify attributes of objects that are meaningful and relevant to users. Unlike names and UIDs, labels are not unique. Labels can be added at creation time or during run time.
• Labels allow for efficient queries and watches. It also allow for the organization and selection of subsets of objects.
• The following are rules for the naming of label keys [3]:

      ● must be 63 characters or less (can be empty),
      ● unless empty, must begin and end with an alphanumeric character ([a-z0-9A-Z]),
      ● could contain dashes (-), underscores (_), dots (.), and alphanumerics between.
      ● “kubernetes.io/” and “k8s.io/” prefixes are reserved for Kubernetes core components.

Label selector

• Label selectors are used to identify a set of objects. There are two types of selectors:
         ● equality-based.
         ● set-based.
• Multiple label selectors can be used using the comma separator, which acts as a logical AND operator.
• Equality-base selector uses =, ==, and !=. Examples:
        ● environment = production
        ● tier != frontend
        ● environment=production,tier!=frontend
• Set-based selector uses in, notin, and exists. Examples:
        ● environment in (production, qa)
        ● tier notin (frontend, backend)
        ● partition
        ● !partition
        ● partition,environment notin (qa)
• Both types of selectors can be combined. For example:
        ● partition in (customerA, customerB),environment!=qa

Namespaces

• Namespaces are used to isolate groups of resources within a single cluster. Namespaces can also be used to divide cluster resources between multiple users (via a resource quota).
• A resource’s name can be unique inside a namespace, allowing for the same name to be used in other namespaces.
• Some cluster-wide objects are not applicable for namespacing (such as StorageClass, Nodes, PersistentVolumes, etc).

• Not all resources can be placed in a namespace. Examples of these are Nodes and persistentVolumes.
• Examples of objects that can be namespaced are Deployments and Services.
• A Kubernetes cluster will have four initial namespaces available:
         ●    default – Allows for the creation of a new cluster without first creating a namespace.
         ●    kube-node-lease – Used to hold Lease objects for each node. Node leases allows the
                kubelet component to send heartbeats to the control plane to detect node failures.
         ●    kube-public – Namespace that is readable by all clients, including unauthenticated
                guests.
         ●    kube-system – Created by the Kubernetes system for its objects
• Example of accessing an object with a namespace           
  • $ kubectl get namespace
  • $ kubectl get pods –namespace=[namespace]
  • $ kubectl config set-context –current –namespace=[namespace]
• Note that DNS entries for Service components uses the form “<service-name>.<namespace>.svc.cluster.local”. If a container only contains “<service-name>”, it will resolve to the local namespace.

Annotations

• Annotations are used to attach arbitrary custom metadata to objects. Like Labels, Annotations are key/value maps.
• Usually used by tools and libraries for their custom operations.
• Example:

Field Selectors

• Field Selectors are used to select Kubernetes objects based on the values of one or more resource fields.
• Example:

      ●     metadata.name=my-service
      ●     metadata.namespace!=default
      ●     status.phase=Pending

• Example of commands using field selectors:
                $ kubectl get pods –field-selector status.phase=Running
                $ kubectl get services –all-namespaces –field-selector metadata.namespace!=default
                $ kubectl get pods –field-selector=status.phase!=Running,spec.restartPolicy=Always
                $ kubectl get statefulsets,services –all-namespaces –field-selector metadata.namespace!=default

Owners and Dependents

• Objects can have an owner. These owner references describe the relationship between objects in Kubernetes. For example, a ReplicaSet is the owner of a set of Pods.
• Objects with an owner are dependent on the state of their Owner.
• Owner references allow Kubernetes components to avoid interfering with objects they don’t control.
• When a resource is deleted, the API server signals the managing controller to process any finalizer rules. This can prevent deletion of critical resources such as PersistentVolume still in use by a Pod.

Finalizers

• Finalizers are configurable rules that tells Kubernetes to wait until specific conditions are met before fully deleting resources that are marked for deletion.
• Finalizers can be used to control garbage collection
• When an object is deleted, it is not deleted immediately, but instead, is marked for deletion. This is to allow for Owners to decide on a deletion action before it is executed or canceled.