| Approach |
Type of Data |
How it's mounted |
Example |
| Using a manifest's container definition |
Non-confidential |
Environment variable |
Command-line flag |
| Using {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} |
Non-confidential |
Environment variable OR local file |
nginx configuration |
| Using {{< glossary_tooltip text="Secrets" term_id="secret" >}} |
Confidential |
Environment variable OR local file |
Database credentials |
{{< note >}}
If you have any data that you want to keep private, you should be using a Secret. Otherwise there is nothing stopping that data from being exposed to malicious users.
{{< /note >}}
## Understand basic Kubernetes architecture
As an app developer, you don't need to know everything about the inner workings of Kubernetes, but you may find it helpful to understand it at a high level.
#### What Kubernetes offers
Say that your team is deploying an ordinary Rails application. You've run some calculations and determined that you need five instances of your app running at any given time, in order to handle external traffic.
If you're not running Kubernetes or a similar automated system, you might find the following scenario familiar:
{{< note >}}
1. One instance of your app (a complete machine instance or just a container) goes down.
1. Because your team has monitoring set up, this pages the person on call.
1. The on-call person has to go in, investigate, and manually spin up a new instance.
1. Depending how your team handles DNS/networking, the on-call person may also need to also update the service discovery mechanism to point at the IP of the new Rails instance rather than the old.
{{< /note >}}
This process can be tedious and also inconvenient, especially if (2) happens in the early hours of the morning!
**If you have Kubernetes set up, however, manual intervention is not as necessary.** The Kubernetes {{< link text="control plane" url="/docs/concepts/overview/components/#master-components" >}}, which runs on your cluster's master node, gracefully handles (3) and (4) on your behalf. As a result, Kubernetes is often referred to as a *self-healing* system.
There are two key parts of the control plane that facilitate this behavior: the *Kubernetes API server* and the *Controllers*.
#### Kubernetes API server
For Kubernetes to be useful, it needs to know *what* sort of cluster state you want it to maintain. Your YAML or JSON *configuration files* declare this desired state in terms of one or more API objects, such as {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. To make updates to your cluster's state, you submit these files to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server (`kube-apiserver`).
Examples of state include but are not limited to the following:
* The applications or other workloads to run
* The container images for your applications and workloads
* Allocation of network and disk resources
Note that the API server is just the gateway, and that object data is actually stored in a highly available datastore called {{< link text="*etcd*" url="https://github.com/coreos/etcd" >}}. For most intents and purposes, though, you can focus on the API server. Most reads and writes to cluster state take place as API requests.
For more information, see {{< link text="Understanding Kubernetes Objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}.
#### Controllers
Once you’ve declared your desired state through the Kubernetes API, the *controllers* work to make the cluster’s current state match this desired state.
The standard controller processes are {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}} and {{< link text="`cloud-controller-manager`" url="/docs/concepts/overview/components/#cloud-controller-manager" >}}, but you can also write your own controllers as well.
All of these controllers implement a *control loop*. For simplicity, you can think of this as the following:
{{< note >}}
1. What is the current state of the cluster (X)?
1. What is the desired state of the cluster (Y)?
1. X == Y ?
* `true` - Do nothing.
* `false` - Perform tasks to get to Y, such as starting or restarting containers,
or scaling the number of replicas of a given application. Return to 1.
{{< /note >}}
By continuously looping, these controllers ensure the cluster can pick up new updates and avoid drifting from the desired state. These ideas are covered in more detail {{< link text="here" url="/docs/concepts/" >}}.
## Additional resources
The Kubernetes documentation is rich in detail. Here's a curated list of resources to help you start digging deeper.
### Basic concepts
* {{< link text="More about the components that run Kubernetes" url="/docs/concepts/overview/components/" >}}
* {{< link text="Understanding Kubernetes objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}
* {{< link text="More about Node objects" url="/docs/concepts/architecture/nodes/" >}}
* {{< link text="More about Pod objects" url="/docs/concepts/workloads/pods/pod-overview/" >}}
### Tutorials
* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/" >}}
* {{< link text="Hello Minikube" url="/docs/tutorials/stateless-application/hello-minikube/" >}} *(Runs on Mac only)*
* {{< link text="Kubernetes object management" url="/docs/tutorials/object-management-kubectl/object-management/" >}}
### What's next
If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys:
* {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} - Dive deeper, with the next level of this journey.
* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys.
{{% /capture %}}