Kubernetes: Objects
Understanding Kubernetes objects
Source: Kubernetes Documentation: Understanding Kubernetes Objects
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
- What containerized applications are running (and on which nodes)
- The resources available to those applications
- The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
A Kubernetes object is a “record of intent”–once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.
Required fields for Kubernetes YAML files
Kubernetes Documentation: Required Fields
-
apiVersion: self-explanatory. Not the same as the software version. -
kind: the kind of object to create. e.g. pod, deployment, job, DaemonSet, ReplicaSet, ReplicationController, etc. metadata: a key for nesting sub key/value pairs.name: has to be unique for each object. 253 chars max. Lower-case chars, en dashes, or periods.uid: generated by Kubernetes automatically. Unique for the lifetime of a cluster.
-
spec: description of the desired state of an object. Fields vary per object type. status: describes the actual state of the object at the current time.
Types of Kubernetes objects
- Nodes: physical or virtual machines.
- Service accounts.
- Resources quotas (per namespace).
- Endpoint.
- Deployment: a controller that manages the state of ReplicaSets.
- Pod.
ReplicaSet
Orchestrates individual pod lifecycle and updates. These are newer versions of Replication Controllers, which differ only in selector support.
DaemonSet
Ensures a single pod, of the same type, runs on every node in a cluster. This includes nodes created after a DaemonSet. Useful for applications like logging.
StatefulSets
An object used to manage stateful applications. Pods use the same PodSpec,
however, each Pod is considered unique. A StatefulSets also order pods. By
default, Pods have an -# suffix. Another Pod will not launch until the first
reaches a running and ready state.
Horizontal Pod Autoscales (HPA)
Scale Replication Controllers, ReplicaSets, or Deployments based on a metric. The default metric a target of 50% CPU usage.
The usage is checked by the kubelet every 30 seconds, and retrieved by the Metrics Server API call every minute. HPA checks with the Metrics Server every 30 seconds. Should a Pod be added or removed, HPA waits 180 seconds before further action.
Cluster Autoscaler (CA)
Adds or removes nodes automatically from the cluster, based on low utilization or an inability to deploy pods.
Data is collected every 10 seconds and decisions are made every 10 minutes.
Jobs
Run a set number of Pods to completion. If a pod fails, it will be restarted until the number of completion is reached.
Jobs are useful for either running one-off Pods or running batch jobs.
A Job specification will have a parallelism and a completion key, which can be omitted.
ClusterRole, Role, ClusterRoleBinding, and RoleBinding
API group:
rbac.authorization.k8s.io
- These resources allow us to define Roles within a cluster and associate users to these Roles.