Credits to Udemy course.Github sources here.Cheat sheet by Kubernetes official.
Let’s give a very quick overview of main kubernetes concepts with some useful commands that really helped me a lot.
Pods
Kubernetes works on Pods basis. A pod is a set of co-related containers. The most common scenario is running a single container per Pod. We can label pods or add pods in namespaces to better organise them in logical units.
This quick-reference and print-friendly cheat sheet provides a list of handy kubectl commands, segmented out into common Kubernetes objects (the ones that you're likely to interact with the most often): Pods, Services, Deployments, Secrets and Nodes. Github: K8s in 30 mins 🌟 This is not a comprehensive guide to learn Kubernetes from scratch, rather this is just a small guide/cheat sheet to quickly setup and run applications with Kubernetes and deploy a very simple application on single workload VM. This repo can be served as quick learning manual to understand Kubernetes.
Deployments
The pods are un-managed resources which means that if a pod is dead, Kubernete will do nothing to recover it back. In order to manage pods, we need to use ReplicationControllers or ReplicaSets.
$ git clone project url Downloads a project with the entire history from the remote repository. 01 02 Git Cheat Sheet Day-To-Day Work $ git status Displays the status of your working directory. Options include new, staged, and modified files. It will retrieve branch name, current commit identifier, and changes pending commit. $ git add file. Helm is called the package manager for Kubernetes. It makes it easier to package and deploy software on a Kubernetes cluster using app definitions called charts. A chart is a package that can be shared and reused, which contains an application’s Kubernetes resource definitions (YAML files) and some templating logic. At Intellipaat, we support our learners with a handy reference, that’s the reason we have created this cheat sheet. It is designed for those who have already started learning Docker but needs a handy reference to recall the concepts that they have learned.
Don’t want to add more details about these two resource types since we’ll be using Deployment resources for managing pods and more things.
When we apply this deployment, Kubernetes will create one or more ReplicaSets resources to manage the pods by us. We can manage the number of pods we want to create using the replicas field. Easy peasy!
Moreover, the Deployment resource can offer much more! It works like if we tag our branch in git, but with a whole infrastructure. We can tag the state of a whole infrastructure and rollback whenever we want.
And eventually, we’ll want to upgrade our applications. This resource manages the upgrade of existing containers using two strategies:
- StrategyType: RollingUpdate. This is the default strategy. We’ll update all the pods gradually. To be used if our stack supports multiple different versions running at the same time.
- StrategyType: Recreate. It will delete all the existing pods and recreate them with the new version.
This is done transparently by Kubernetes when we update a Deployment template.
Using Private Docker Repository
This only works for docker images that are hosted in dockerhub. Most of the cases, we want to use a private docker repository. Let’s see how to configure this. We need a Secret resource (we’ll see more about this resource later in this tutorial) to provide the docker credentials:
And use it in your deployment template like:
Resources
Another important topic when deploying our apps is the server resources we’re using or we’ll need:
The resources.requests field works like a minimum resources the application needs to work well. The resources.limits is the maximum resources that the application should consume.
Pods Ordering
Sometimes, our apps need some services to start working, how can we deal with pods startup orderning? Let’s introduce the init containers:
Services
Github Kubernetes The Hard Way
How do we expose our endpoints? We need to use another resource called Services:
- The default service type is “ClusterIP” which will expose the pods only within current node.
- The service type “NodePort” will expose the pods within the same cluster.
- Setting the service type to “LoadBalancer” will expose the pods outside too via public ip.
This is an example of how to create a service in Kubernetes. In Minikube, we can test this service by doing:
Some useful commands about services:
All the resources we have introduced so far: ReplicationControllers, ReplicaSets and Services, select the pods via label selection. This is if our pod is labelled with “app=myApp”, we can configure our Service to scope the pods with label “app=myApp” only.
Volumes
Usually, our applications need paths to work. Either a folder where to put the logging files that eventually will be read by a third system like logstash or splunk. Or a folder where to locate temporal files we need to watch or import on demand. Or a folder where to read the configuration files from.
Kubernetes provides the Volume resources for this purpose. And there are MANY type of volumens you can mount. We can find the complete list of volume types here.
Let’s give a very easy example:
The volume type emptyDir will create an empty folder. Then we’ll mount this empty folder in our containers. We could map the same volume to different containers and these containers could send files each folder through this volume.
Bear in mind, our pods should be node agnostic, so we should *NEVER mount local folders in. This is a very bad practice. This is because the pod could work differently if it’s deployed in a node where the data in its local folder is different from another node.
Configuration
What about the configuration files? Do we need to upload these files into a volume in the cloud like S3 always for kubernetes? NO. Kubernetes provides a couple of special volumes for you.
ConfigMap
Kubernetes Cheat Sheet Github Free
Let’s see how looks like:
We added a ConfigMap resource with a couple of files. Let’s use it:
Create A Config Map from a file
In order to see the output in yaml:
Secrets
For the secrets, it’s almost the same as in ConfigMaps but it works differently internally. We edit the template using Base64 and this configuration is not stored in each node, but it keeps in memory. More about this in here.
Dashboard Web UI
Or:
Appedix: More Commands
Scaling
Upgrading
Secrets Commands
Usage & Resource Monitoring
Namespaces & Resource Quotas
Auto-Scaling
Comments are closed.