Interacting with Kubernetes:

Method 1:

• It is possible but not common to work directly with the API server
• You might need to if there is no Kubernetes client library for your programming language.

Method 2: Client libraries

• Handles authenticating and managing individual REST API requests and responses.
• Maintains official client libraries

Method 3: kubectl

• Issue high-level commands that are translated into REST API calls.
• Wors with local and remote clusters
• Manages all different type of Kubernetes resources, and provides debugging and introspection features.

Method 4: Web Dashboard

Pods

What are Pods?

• Basic building block in Kubernetes
• One or more containers in a Pod
• Pod containers all share a container network
• One IP address per Pod

Because Pods include containers, the declaration of a Pod includes all the properties that you would expect for example with Docker run.

Manifest Files

• Declare desired properties.
• Manifests can describe all kinds of resource
• The spec contains resource-specific properties.

Probes:

• Used to check when a pod is ready to serve traffic/handle requests
• Userful after startup to check external dependencies.
• Readiness Probes set the Pods's ready condition. Services only send traffic to ready Pods.
• Can be declared in a Pod's containers
• All cotainer probes must pass for the Pod to pass
• Probe actions can be a comand that runs in the container, an HTTP GET request, or opening a TCP socket.

Liveness Probes:

• Detect when a Pod enters a broken state.
• Kubernetes will restart the pod for you.

Init Containers:
Motivation for Init Contianers:

• Sometimes you need to wait for a service, downaloads , dynamic or decisions before starting a Pods's containers.
• Prefer to separate initialization logic from the container image.
• Initialization is tightly coupled to the main application (belongs in the Pod)
• Kubernetes provides us with Init Containers that allow you to run initialization tasks before starting the main container(s)

Init Containers:

• Pods can declare any number of init containers
• Init Containers run in order and to completion

*

• User their own images
• Easy way to blcok or delay startring an application.
• Run every time a Pod is created
• They have the same fields as regular containers, except for readinessProbe.

In short, Init Contianers allow you to perform tasks before main application containers have an opportunity to st art.
They are useful for checking preconditions and preparing dependencies.

Volumes:

• Volumenes are tied to a pod and their lifecycle.
• Share data between containers and tolerate container restarts
• Use for non-durable storage that is deleted with the Pod.
• Default Volumen type is emptyDir
• Data is lost if Pod is rescheduled on a different node.

ConfigMaps and Secrets:
ConfigMaps and secrets separte configuration data from pod specs or what would otherwise be stored in container images.

• Both store data as key-value pairs.
• Secrets are for sensitive data.