Because of its abstractions, Kubernetes introduces some concepts that need introduction. This is not an in depth description of all components. Consider this a quick overview of some essential components.
For in depth information, take a look at the Kubernetes docs.
kubectl is the command line tool that is used to manage Kubernetes clusters.
A manifest is a YAML file that is a description of a desired state of specific Kubernetes resources. Every Kubernetes resource (e.g. a Pod, Deployment, Service, etc.) can be described in such a manifest. If a manifest is applied, Kubernetes automatically adjusts the state of the current cluster to match the described state. A sample manifest and how to use it can be found here.
Pods are the smallest unit in Kubernetes. It is an abstraction over one or more containers that are tightly coupled.
A deployment describes a desired state for a set of pods to be in. Deployments can be dynamically updated with no application downtime. It also is responsible for scaling the amount of pods for a particular application.
A service makes deployments internally available. If you want interaction between two deployments, you need to create a service for each of them and then connect them to the respective service.
Kubernetes implements an in-cluster network for inter-resource communication. To serve external requests, Kubernetes employs ingress resources as an entry point to the cluster. Ingress resources forward requests to the right services, dependent on subdomain- or URL-matching. They also can handle the SSL encryption and termination. Ingress resources are managed by a ingress controller, that need to be deployed separately.
Containers have no persistency. If you kill a container, all non-persistent data is gone. A volume allows mounting storage into a service. This storage can be either local or remote (e.g. AWS S3 storage). To be accessible to a resource the volume must be claimed first. This is called a persistent volume claim.
A node is a compute-instance that is part of a Kubernetes cluster. Load is distributed between nodes.
A StatefulSet, as the name suggests, manages stateful pods (applications). These can be databases or other apps that store data. This is necessary because if multiple instances of an application were all allowed to change data, there obviously would be data inconsistency. StatefulSets circumvent this by using a master-slave relationship between all instances of a stateful set. Only the master can make actual changes to the data. Slaves can still query data or ask the master to change data.
Designed & Developed by Jasper Anders