commands

# watch mode
kubectl get pods -w

# more info
kubectl get pods -o wide

Workshop ACC ICT

Containers are not virtualisation, but isolation.

Kettle vs pet

All the containers are similar

Container rules

What k8s does not do

Business case

Network tools

Namespaces

Services

Ingress

Controllers

Todo Research

DAPR

Dapr, which stands for Distributed Application Runtime, is an open-source project by Microsoft aimed at making it easier to build microservice applications.

Dapr provides a set of building blocks that simplify how you build and run distributed applications. These building blocks provide capabilities such as state management, service-to-service invocation, publish and subscribe messaging, and distributed tracing, among others.

The goal of Dapr is to provide a platform-agnostic, language-agnostic framework that developers can use to build high-performance, scalable systems without having to worry about the underlying infrastructure. It provides a consistent approach to building and managing microservices across different environments (e.g., on-premises, in the cloud, and on the edge).

Dapr can be used with various programming languages and frameworks, and it can run either in self-hosted mode or on Kubernetes.

KEDA

KEDA, or Kubernetes Event-Driven Autoscaling, is a Kubernetes-based solution for auto-scaling containerized applications in response to events from sources like message queues, databases, or serverless functions. It allows developers to dynamically scale their applications running on Kubernetes in response to events from external sources without having to change their application code.

Kubernetes federation

Managing and coordinating multiple Kubernetes clusters as a single unified entity.

  1. Kubernetes Federation Control Plane: The control plane is responsible for managing and coordinating the federated setup. It typically includes components like the Federation API Server and the Federated Controller Manager. The Federation API Server exposes the federated API, which allows users to interact with the federated control plane.
  2. Federated Resources: In a federated Kubernetes setup, resources such as Deployments, Services, ConfigMaps, and other Kubernetes objects can be defined at the federated level. These resources are then propagated to the individual clusters in the federation. For example, you might define a federated Deployment, and replicas of that Deployment would be created in each cluster.
  3. Federated Configurations: Federated configurations allow you to specify how resources should be replicated and managed across clusters. This includes defining placement policies, which determine where resources should be deployed based on criteria like cluster labels or geographic location.
  4. Federation API: The Federation API extends the standard Kubernetes API to support federated resources and configurations. It allows users to interact with the federated control plane and manage resources at the federated level.
  5. Cluster Topology: Federated Kubernetes supports various topologies, such as a single control plane managing multiple clusters or a multi-control plane setup where each cluster has its own control plane. The choice of topology depends on factors like geographical distribution, network latency, and desired fault tolerance.
  6. Global DNS: In a federated setup, global DNS may be used to route traffic to the appropriate cluster based on the location of the user or other criteria. This ensures that users are directed to the closest or most suitable cluster for their requests.
  7. Cross-Cluster Communication: Federated Kubernetes provides mechanisms for cross-cluster communication, allowing pods in one cluster to communicate with pods in other clusters. This is essential for building distributed and scalable applications.

Containers

are an application-centric method to deliver high-performing, scalable applications on any infrastructure of your choice

Containers encapsulate microservices and their dependencies but do not run them directly. Containers run container images.

A container image bundles the application along with its runtime, libraries, and dependencies, and it represents the source of a container deployed to offer an isolated executable environment for the application.

Container orchestrators

are tools which group systems together to form clusters where containers’ deployment and management is automated at scale while meeting the requirements mentioned above.

Orchestrators

Most container orchestrators can:

Kubernetes features

Kubernetes architecture

Kubernetes installation types

Kubernetes object model — nodes

Kubernetes object model — namespaces

Kubernetes object model — pods

LIVENESS

READINESS

Kubernetes object model — controllers

Examles

Kubernetes object model — labels

Kubernetes object model — services

SERVICE DISCOVERY

Environment VariablesAs soon as the Pod starts on any worker node, the kubelet daemon running on that node adds a set of environment variables in the Pod for all active Services.

DNSKubernetes has an add-on for DNS, which creates a DNS record for each Service and its format is my-svc.my-namespace.svc.cluster.local. 

SERVICE TYPE

Authentication

Authorizes the API requests submitted by the authenticated user.

 authentication modules:

Authorization

Authenticate a user based on credentials provided as part of API requests.

NodeNode authorization is a special-purpose authorization mode which specifically authorizes API requests made by kubelets. It authorizes the kubelet’s read operations for services, endpoints, or nodes, and writes operations for nodes, pods, and events. For more details, please review the Node authorization documentation.

Attribute-Based Access Control (ABAC)With the ABAC authorizer, Kubernetes grants access to API requests, which combine policies with attributes.

WebhookIn Webhook mode, Kubernetes can request authorization decisions to be made by third-party services, which would return true for successful authorization,

Role-Based Access Control (RBAC)In general, with RBAC we regulate the access to resources based on the Roles of individual users. In Kubernetes, multiple Roles can be attached to subjects like users, service accounts, etc. While creating the Roles, we restrict resource access by specific operations, such as create, get, update, patch, etc. These operations are referred to as verbs. In RBAC, we can create two kinds of Roles:

The manifest defines a pod-reader role, which has access only to read the Pods of lfs158 Namespace. Once the role is created, we can bind it to users with a RoleBinding object.

There are two kinds of RoleBindings:

Admission control

Software modules that validate and/or modify user requests

Admission controllers are used to specify granular access control policies, which include allowing privileged containers, checking on resource quota, etc. We force these policies using different admission controllers, like ResourceQuota, DefaultStorageClass, AlwaysPullImages, etc. They come into effect only after API requests are authenticated and authorized.

Volumes

A PersistentVolumeClaim (PVC) is a request for storage by a user. Users request for PersistentVolume resources based on storage class, access mode, size, and optionally volume mode

Container storage interface — CSI

designed to work on different container orchestrators with a variety of storage providers.

Config maps

ConfigMaps allow us to decouple the configuration details from the container image. Using ConfigMaps, we pass configuration data as key-value pairs, which are consumed by Pods or any other system components and controllers, in the form of environment variables, sets of commands and arguments, or volumes. We can create ConfigMaps from

See convig values as env variables inside of the containers

Can also be mounted as a Volume inside a Pod

kubectl create configmap my-config
–from-literal=key1=value1
–from-literal=key2=value2

Secret

Secret data is stored as plain text inside etcd, therefore

kubectl create secret generic my-password \  –from-literal=password=mysqlpassword

make sure you do not commit a Secret’s definition file in the source code. With stringData maps, there is no need to encode the value of each sensitive information field. The value of the sensitive field will be encoded when the my-password Secret is created

Secrets are consumed by Containers in Pods as mounted data volumes, or as environment variables, and are referenced in their entirety or specific key-values.

We can also mount a Secret as a Volume inside a Pod.

Ingress

Ways to espose the app:

Properties

Helps with

Annotations

With Annotations, we can attach arbitrary non-identifying metadata to any objects, in a key-value format:

"annotations": {  
    "description": "Deployment based PoC dates 2nd Mar2022",
    "key2" : "value2"
}

Unlike Labels, annotations are not used to identify and select objects. Annotations can be used to:

Annotations are displayed while describing an object

Quota and Limits Management

per Namespace:

LimitRange, used in conjunction with the ResourceQuota API resource. A LimitRange can:

Autoscaling a.k.a. Elasticity

Jobs and Cronjobs

A Job creates one or more Pods to perform a given task. The Job object takes the responsibility of Pod failures. It makes sure that the given task is completed successfully. Once the task is complete, all the Pods have terminated automatically. Job configuration options include:

we can also perform Jobs at scheduled times/dates with CronJobs, where a new Job object is created about once per each execution cycle. The CronJob configuration options include:

Stateful sets

The StatefulSet controller is used for stateful applications which require a unique identity, such as name, network identifications, or strict ordering. For example, MySQL cluster, etcd cluster. The StatefulSet controller provides identity and guaranteed ordering of deployment and scaling to Pods. However, the StatefulSet controller has very strict Service and Storage Volume dependencies that make it challenging to configure and deploy. It also supports scaling, rolling updates, and rollbacks.

Custom resources

a resource is an API endpoint which stores a collection of API objects. For example, a Pod resource contains all the Pod objects.

Custom resources are dynamic in nature, and they can appear and disappear in an already running cluster at any time.

There are two ways to add custom resources:

Network policies

Network Policies are sets of rules which define how Pods are allowed to talk to other Pods and resources inside and outside the cluster. Pods not covered by any Network Policy will continue to receive unrestricted traffic from any endpoint. 

Network Policies are very similar to typical Firewalls. They are designed to protect mostly assets located inside the Firewall but can restrict outgoing traffic as well based on sets of rules and policies. 

The Network Policy API resource specifies podSelectors, Ingress and/or Egress policyTypes, and rules based on source and destination ipBlocks and ports. Very simplistic default allow or default deny policies can be defined as well.

Monitoring

Logging

Kubernetes does not provide cluster-wide logging by default Fluentd

Although we can extract container logs from the cluster, we are limited only to logs of currently running containers

# get the logs of last failed container, if it is continuously restarting
kubectl logs pod-name -c container-name —previous

Debug

kubectl exec pod-name -c container-name -it -- /bin/sh
kubectl get events
kubectl describe pod pod-name

Deployment strategies