Kubernetes Objects

intro

• Pods, or groups of containers, can group together container images developed by different teams into a single deployable unit.

• Kubernetes services provide load balancing, naming, and discovery to isolate one microservice from another.

• Namespaces provide isolation and access control, so that each microservice can control the degree to which other services interact with it.

• `Ingress objects provide an easy-to-use frontend that can combine multiple microservices into a single externalized API surface area.

Cluster

Cluster: A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node. A cluster also has a control plane that runs services that manage the cluster.

Node

Node: Kubernetes runs your workload by grouping containers into pods and assigning those pods to run on nodes. A node can be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run pods.

Pod

Pod: A group of one or more containers. Pods are defined by a PodSpec file, a specification for how to run the containers. Pods are the basic building block within Kubernetes for deployment, scaling, and replication.

kubectl get pods -o wide

Volume

Ephemeral volume: Applications in a pod have access to shared volumes to facilitate data sharing in the pod and persistence of data across container restarts. When a pod ceases to exist, Kubernetes destroys ephemeral volumes.

Persistent volume: A persistent volume functions similarly to an ephemeral volume but has a lifecycle independent of any individual pod that uses them. Persistent volumes are backed by storage subsystems independent of cluster nodes.

Service

Service: In Kubernetes, a service is a logical collection of pods and a means to access them. The service is continually updated with the set of pods available, eliminating the need for pods to track other pods.

Namespace

Namespace: A virtual cluster that is backed by the same physical cluster. Physical clusters can have resources with the same name as long as they are in different namespaces. Namespaces are especially useful when you have multiple teams or projects using the same cluster.

kubectl get namespaces -o wide

Replicaset

ReplicaSet: Ensures that a specific number of pod replicas are running at any given time.

Deployment

Deployment: Owns and manages ReplicaSets or individual pods. You describe a desired state in the deployment. The deployment then changes the actual state of the cluster to the desired state at a controlled rate.

kubectl apply -f nginx-deploy.yaml

Secrets and configmap

ConfigMap: A ConfigMap is an API object that stores nonconfidential data as key-value pairs used by other Kubernetes objects, such as pods. Use ConfigMaps to follow the best practice of portability by separating your configuration data from your application code.

Secrets: All confidential data, such as AWS credentials, should be stored as Kubernetes secrets. Secrets restrict access to sensitive information. Optionally, encryption can be turned on to improve security.

Pod scheduling

Pod scheduling

You can schedule pods with the Kubernetes scheduler. The scheduler checks the resources required by your pods and uses that information to influence the scheduling decision. The scheduler runs a series of filters to exclude ineligible nodes for pod placement

Control plane and data plane

Control plane: Control plane nodes manage the worker nodes and the pods in the cluster.

Data plane: Worker nodes host the pods that are the components of the application workload.

Control/data plane communication: Communication between the control plane and worker nodes is done through the API server to kubelet.

Control plane

The control plane determines when tasks are scheduled and where they are routed to.

• The control plane includes:
• Control plane nodes
• Controller manager
• Cloud controller o Scheduler
• API server
• etcd

The controller manager runs background threads called controllers that detect and respond to cluster events.

The cloud controller is a specific controller that interacts with the underlying cloud provider.

The scheduler selects nodes for newly created containers to run on.

The Kubernetes API server exposes the Kubernetes API and is the frontend for the Kubernetes control plane.  It handles all communication from the cluster to the control plane; none of the other control plane components are designed to expose remote services. The Kubernetes API server is designed to scale horizontally, deploying more instances as necessary

Etcd is the core persistence layer for Kubernetes. It is a highly available distributed key value store. This is where the critical cluster data and state are stored.

Data plane

In Kubernetes, the data plane is where the tasks are run. This is all done on your worker nodes.

The data plane includes

• worker nodes:
• kube-proxy
• container runtime
• kubelet
• pods

kube-proxy helps with networking. It maintains network rules on the host and performs any connection forwarding that may be necessary.

container runtime Kubernetes supports several runtimes, with Docker being the most common.

kubelet is the primary agent that runs on the worker nodes. Kubelet makes sure that the right containers are running in a pod and that they are healthy.

A Pod is a group of one or more containers. The containers in a pod are always colocated, scheduled together, and managed together; you cannot split containers in a pod across nodes. Applications in a pod can easily communicate with each other. Like individual application containers, pods are considered to be relatively ephemeral (rather than durable) entities. This means that pods can disappear if they become unhealthy, and new ones can take their place.

kubectl

You can communicate with your control plane nodes using kubectl. kubectl is a command line interface (CLI) for communicating with the Kubernetes API server. It provides commands to create resources, view detailed information about the cluster and resources, and access troubleshooting tools. kubectl commands are used to roll out, scale, and automatically scale resources.

Syntax:

kubectl [command] [TYPE] [NAME] [flags]

• Command: Specifies the operation you are performing.
• Type: Specifies the resource type.
• Name: Specifies the name of the resource.
• Flag: Specifies optional flags.

EKS API

The Amazon EKS control plane consists of at least two API server nodes and three etcd nodes across three Availability Zones. Amazon EKS automatically detects and replaces unhealthy control plane nodes, which removes a significant operational burden for running Kubernetes. With this capability, you can focus on building your applications instead of managing AWS infrastructure.

To get started with Amazon EKS, you provision your cluster of worker nodes. Amazon EKS handles the provisioning, scaling, and management of the Kubernetes control plane in a highly available and secure configuration. You then connect to the Amazon EKS cluster using the graphical or command line interface. After you’ve connected to the Amazon EKS cluster, you’re ready to deploy your Kubernetes applications to your Amazon EKS cluster. You can do this the same way that you would with any other Kubernetes environment.

You use the Amazon EKS API for anything that Amazon EKS manages. As you have learned, this includes the entire control plane (creating and managing the cluster). In later modules, you learn how Amazon EKS can also manage parts of the data plane using features such as managed node groups and AWS Fargate.