I have been learning Kubernetes intermittently for over a year now.
The hardest part for me is the YAML configurations. Usually, a configuration file contains an apiVersion, kind, metadata, and spec. And then spec contains template, which contains spec again. And this is not always the same. Formats differ for each different kind. I have to memorize a lot of things, and I have to check every time against a reference.
What is the best way to learn Kubernetes configurations? Do we have to grab configuration files and apply them every time instead of writing them? Is this the recommended way?
This question is part of the 100K Member Contest - don't forget to kudo the original contest post to be entered.
You don't need to remember resources yaml syntax , we are not robots.
This is not the goal of the exams.
You should have the knowledge of what you need to solve the problem/task , and deep debugging skills.
Yaml examples are provided on the docs , and on the openshift/kubernetes platform, for example you can get the yaml output of some running component like monitoring, and look for the yaml structure of the deployment / pv and so on.
@MehdiHaghgoo if you haven't already, check out this guided exercise on KBE that generates a basic YAML file you can run: https://kubebyexample.com/en/learning-paths/application-development-kubernetes/lesson-1-running-cont...
also, check out KubeLinter --- it analyzes your YAML files (and Helm charts) against best practices to run in prod w/security considerations: https://github.com/stackrox/kube-linter
The advantage of configuration files is that you can check the files into your version control (probably git). This means that your whole system configuration is stored and deployable to multiple clusters -- qa, integration, prod1, prod2 (multi-region). This helps protect your clusters against disasters or makes your business portable to different clouds.
Another advantage is that you can practice gitOps by creating a git workflow where changes to production are peer reviewed, version controlled, auditable, and reproducible.
Learning the yaml manifests takes time, but in practice most people will refer to other working applications and build off of that. Just make sure that you read through and understand the manifests.
The best way to see Kubernetes/OpenShift's yaml file is break down it into sections and understand what each section can suppose to do. For e.g.
Syntax for pod.yaml
api: <contains api version>
kind: <represent what kind of resource it is pod, pv,pvc etc.>
metadata:<it contains name and namespace and labels other information too>
spec: <it contains specifications of the resource. For e.g. Pod, which image it is using and on what port it will listen the request, what is the mount etc. >
If you breakdown yaml with above key components then you will not find any difficulty in future.
Also, it will help you to debug the issues with ease.
I hope this will help you to understand yaml and it is not difficult to read/write just syntax nothing else
In addition to Satyajit's advice, I use yamallint.com a great tool to check and correct your syntax. At least works for me.
Break down config files and read carefully, you can check a config syntax online in case of human error
There are several tools that can help you create or edit K8s yaml files. Make sure first you understand the resources available (use "oc api-resources" or "kubectl api-resources" to check them).
To create a basic resource yaml file, you can use the dry-run option of the kubectl create cli, example:
oc create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2 --dry-run=client -o yaml
provides the basic skeleton of the resource yaml file.
If it is to be edited and customized, you can use oc explain <resource_name> to get more details about the resource options available. Example: oc explain Deployment | more
Hope this helps as a start!
Get a good editor, that handles the yaml syntax for you. I personally use PyCharm and Microsoft VS Code.
A collaborative learning environment, enabling open source skill development.