Personal cheat on Kubernetes (K8)

Where Docker stores definitions of isolated operating systems They are a recipe for what an operating system needs to run, and contains things like

• install ubuntu
• install apache

They are instances of images. So, an image is like a class, and a container is like a particular instance of this class. These objects are you will be most dealing with. Can also think of docker images as golden images that are then used to create docker containers.

They communicate with each other as if they were real servers on a network, so via TCP/IP or UDP typically.

Why containers, or container apps, or containerized applications? It is a packaging mechanism for code that contains the application code itself along with all the dependancies (down to the version) of that application. Therefore they can run on any platform as all the reqeuirements are included/packaged together. So they are easier to deploy, they are easy to migrate from one platfrom to another.

Large monolithic applications are no longer being developed. Instead people write micro-services that interact over the network.

This also allows one to stay current by upgrading individual microservices easily and independent of one another. The changes to the system are small, but many. Kind of achieves continual improvement…

But, it creates a lot of fragmentation / container sprawl. The mgt of this sprawl needs to be addresssed with some container orchestration.

• Islands of compute
• Provides automated scheduling, ensuring that components are running,

automatic restarting, or expanding containers, automated roll-out of new app versions, as well as roll-back these upgrades.

• Bin-packing (packing more nodes on a single host to get better utilization

of compute resources)

Initially was a tool for stateless workload, stateless containers, that did not need protection.

Now however many containers have persistent volumes and state is maintained on those. Kubernetes needs to keep track of what volumes store persistent data, and Kubernetes then needs to ensure that these volumes are protected and secured.

More workloads moving into production means compliance to security regulations and need mgt of type of security needed for these different workloads on containers.

Applications developers like to move quickly into production, however operations security managers need to see that the new versions are secure.

As more need for data protection arises, you need more security on the containers.

Kubernetes itself needs protection. For instance SCD is kubernetes' own database keeps info on the application state of the containers. These need protection.

Although stateless workloads on a container can be very simply killed and redeployed, this is only a subset of applications/workloads.

Configuration data needs protection.

Persistent Volumes. Kubernetes has done a good job at abstracting storage that is cloud agnostic. You may change the storage class for an application but the way you do backups and protection would be identical whether you are using Google Cloud, Azure, AWS or other cloud providers, or private on prem clouds.

Good job on security policies, network policies that can be driven through infrastructure as code in a very declarative approach.

End user view really looks to proctect:

1. Persistent data
2. Configurations
3. Operator customized resources (are part of the application state, stored in SCD)

Speed of deployment of new features hourly while maintaining reliablity with no downtime

Once a container is created, you cannot change it. So, kill it and replace it with a newer version.

Containers and Kubernetes encourage developers to build distributed systems that create an immutable infrastructure. Once an "artifact" is created, users cannot change it. This contrasts with traditional infrastructures where changes are applied to an existing system as "incremental updates".

With Kubernets, rather than making an incremental update to a service, an entirely NEW, complete image is built, where the update becomes a simple replacement of the intire image with the new image, in a single operation.

Contrast that to a system that has an accumulation of upgrades and changes. The current state of the infrastructure is no longer a single artifact but the whole string of sequential upgrades including operator changes.

The are the crux of everything you can build with Kubernetes. No changes! Just new images.

Everything in Kubernetes is a declarative configuration configuration object. These represent the desired state of the system. It is up to Kubernetes to ensure that the desired state is implemented and that the running state matches the desired state. Kubernetes calls this "Desired State Management".

This is very different from an imperative configuration, where the configs are a bunch of instructions/cookbooks on what actions needs to be done. I always have liked the air traffic controller, who simply declares "flight AC545 come to a heading 270 and altitude 8000 ft, speed 280 knots". That is much different than "flight AC 545, reduce throttle by 30%, right flaps 20%, bank right…"

Because the state of the system is defined in these declarative configs, it is easy to put them into a version control system, and very easy to back-out of changes and go back to a previous state, or two or three back.

Kuberetes is an online self-healing system. On a regular basis Kubernetes compares its current state to the declared desired state. Any mis-match is noted, and acted upon. Because the Kubernetes is in control of making the detailed changes to match a desired state from the beginning, it has all the native capabilities to make the changes to move the system back to a desired state.

Contrast that to the traditional cook-book list of steps given one condition and a different series of steps given another condition, let alone knowing if after the steps have been executed is the desired state actually attainged or not. -yikes!!

Plus, the old system relies on operators to make run the cook-book steps according to the planned and documented multitude of recovey procedures.

Load balaners make it possible to isolate the implementers from the users. That makes it easy to scale the system, because adding processes from one area does not affect other areas. Adusting and/or reconfiguring of other components is NOT needed, when you increase the scale.

Decoupling servers via APIs not only makes it easy to scale, it also allows each team to focus on a small microservice, and make that efficient, error free, and stable, including implementing the changes needed.

You can even let Kubernetes autoscale for you as the load demands. Kubernetes simply takes the immutable containers and increases their count with the tied-in load balancers.

The manual chore becauase simply monitoring resources and scaling up the cluster itslef with more resources as needed. Because even the machines in the cluster are identical, Kubernetes helps you with this task too. You can simply image a new machine, and join it to the cluster.

a.k.a Capacity Planning is also more accurate using Kubernetes for these reasons:

1. Decoupling the teams from the specific machines they are using allows the aggregate services to be shared among all the available machines.
2. Each service does not need to be dedicated a resource that has reserve capacity for planned expansion that may or may not be needed.
3. Statistically averaged load across many services is achieved and the aggregate utilization of existing machines can be much higher.

On big enough teams, with enough resources, the decoupling of the apps from the kubernetes services can warrant a dedicated team managing the h/w and kubernetes services for a whole bunch of different app developer teams.

Smaller companies though may want to deligate the h/w and kuberentes services management to the cloud so they can focus on just the app development. This is called KaaS, or Kubernetes as a Service.

KAAS can run on:

1. Microsoft Azure using Azure Container (Kubernetes?) Service, (AKS)
2. Google Cloud Platform via the Google Kubernetes Engineer (GCP GKE).
3. Amazon's AWS EKS, Elastic Kubernetes Service, (AWS EKS).

Left off on chapter 1, and "Abstracting your Infrastructure"

Applications usually have a language runtime, libraries, and your source code. Often applications utilize external libraries such as libc and libssl. These external libraries are generally shipped as shared components in the OS that you have installed on a particular machine.

Problems can occur when an application developed on a progrrammers's laptop has a dependency on a shared library that isn't available when the program is rolled out to the production OS running on a Linux, or other, server.

So there are complex installation scripts that try to check all variations and options so that dependencies are all met. Add to that the fact that running multiple traditional apps on a single machine means these apps have to agree on a set of libraries, because they are shared libraries used by all of them.

Docker has a registry makes it easy to package an application along with all of the library dependencies and push that image to a the remote registry where it can be later pulled by others. There is are many linux container image on docker hub that have been downloaded over 10 million times.

Running docker you will get kubernetes too. To control kubernetes from the command line, use the kubectl commands.

Some examples: kubectl get all –all-namespaces -o wide

helm is the package manager for kubernetes, similar to apt-get, yum, dnf, brew, pip, etc. tiller is the component installed on the kubernetes cluster that will accept commands from your helm client and enforce the resulting configurations on the kubernetes cluster

helm –help

helm init –help

helm repo list helm repo update helm upgrade chart-name help rollback helm search wordpress helm install stable/wordpress

k get po –all-namespaces (aliased to kubectl? check youtube knova

> could not find tiller

So lets tell helm where its tiller is. So run helm init (helm init –help)

Where you can define all your cluster values. These values are then pulled into the deployment.YAML and service.YAML files rather than have these files define individual values. Examples could be: deployment: image:node/mondodb replicas:2 service: type:NodePort port:8080

Then your deployment.YAML file would not define image: node/mongo but would use image:{{values.deployment.image}} and replicas: 2 would rather be replicas:{{values.deployment.replicas}}

Also your service.YAML file would have entries like: type:{{valuse.service.type}} port:{{values.service.port}}

It is the root

best charts are in CenterForOpenScience/helm-charts repo These are like dependencies lists for each app, that includes all the configuration settings for the apps you are deploying on a k8 cluster

You can push a chart to a repo, so that others can benefit from the configurations that you have created. This is with help package, then helm repo to push the package up to the repo.

GKE and AKS provide cluster management for free: Master node management and machines running it are not billed. You pay only for what you run, like virtual machines, bandwidth, storage, and services.

Amazon EKS, on the other hand, costs $0.20 per hour for each deployed cluster, in addition to all the other services you will need. In a 30-day month, that comes out to a $144 extra. Keep in mind that AWS bills even for testing and staging cluster environments.

From this blog on Kubernetes Cost Guide: AWS vs GCP vs Azure vs Digital Ocean "AWS, GCP, Microsoft Azure and Digital Ocean are in the top 6 environments, enterprises deploy Kubernetes workloads on. OpenStack and on-premise are the other two. AWS, GCP and Azure also have managed Kubernetes offerings, while Digital Ocean's is on the way. This coupled with the cloud first trend makes it safe to assume that most enterprise Kubernetes workloads are en-route to the cloud."

“The above table shows you yearly cloud provider costs for a 100 core, 400 GB Kubernetes cluster. Even though Digital Ocean doesn’t provide either a managed Kubernetes offering or discounts for reserved instances, it still has the lowest cost for running our cluster. GCP is a close second. When our cluster exclusively leverages on-demand instances, GCP’s cost is 37% lower than AWS and 27% lower than Azure. GKE cost, when deployed on on-demand instances is also 38% and 27% lower as compared to EKS and AKS, respectively.”

The "direct deployment" above refers to workloads deployed directly onto virtual machine instances. The "managed Kubernetes" above refers to ones leveraging managed Kubernetes services like AWS EKS, GCP GKE or Azure AKS.

A kubernetes node is a backend for kubernetes that provides two things.

1. networking
2. container runtime this starts and stops your pods and your containers, and manages the life cycle

A node is basically a virtual machine. It runs the kublet, maybe docker or containerd as the container runtime, (something to start and stop the containers), and runs kubeproxy to run the networking.

Docker Application is a new packaging option

Modern apps are distributed, in containers, in hybrid-clouds, that contain microservices.

Container Orchestration:

1. deploying
2. Sche4duling
3. Scaling
4. UPdating
5. ? missed this.

Kubernetes is hard. experts are rare. 96% of organization can't manage kubernetes on their own.

DKS has a GUI called "Docker Enterprise Universal Control Plane

Islands of compute

Provides automated scheduling, ensuring that components are running, automatic restarting, or expanding containers, automated roll-out of new app versions, as well as roll-back these upgrades.

Bin-packing (packing more nodes on a single host to get better utilization of compute resources)

Initially was a tool for stateless workload, stateless containers, that did not need protection.

Now however mmany containers have persistent volumes and state is maintained on those. Kubernetes needs to keep track of what volumes store persistent data, and Kubernetes then needs to ensure that these volumes are protected and secured.

More workloads moving into production means compliance to security regulations and need mgt of type of security needed for these different workloads on containers.

Applications developers like to move quickly ionto prodeuction, however operations security managers need to see that the new versions are secure.

As more need for data protection arises, you need more security on the containers. You

Kubernetes itself needs protection. For instance SCD is ubernetes own database keeps info on the application state of the containers. These need protection.

Although stateless workloads on a container can be very simply killed and redeployed, but this is only a subset of applications/workloads.

Configuration data needs protection.

Persistent Volumes. Kubernetes has done a good job at abstracting storage that is cloud agnostic. You may change the storage class for an application but the way you do backups and protection would be identical whether you are using Google Cloud, Azure, AWS or other cloud providers, or private on prem clouds.

good job on security policies, net work policies that can be driven through infrastructure as code in a very declarative approach.

End user view really looks to proctect:

1. Persistent data
2. Configuration
3. Operator customized resources (are part of the application state, stored in SCD