Kubernetes has emerged as a de-facto standard for platform-as-a-service (PaaS) for Microservices, Cloud Native, and emerging architecture patterns. As a software architect, it is essential to not only understand the basics of Kubernetes but also become a practitioner of it. This article showcases 5 awesome views of Kubernetes architecture to help you grasp the key concepts.
Kubernetes High-level Architecture View
- Controller Manager – manages control processes such as node controller, job controller, etc.
- Scheduler – allocates the resource requirements such as allocation of node for PODs
- Cluster DNS – manages DNS records for Kubernetes services
- Cloud Controller Manager – embeds Cloud-provider (e.g. AWS, GCP, Azure) specific control logic
- API Server – main interface for control plan as API server
- ETCD – Key-value based datastore for storing cluster data
Kubernetes Workload Architecture View
Kubernetes workload components represent an application running in the Kubernetes cluster. As your application can have multiple components, a workload can be executed in a single Pod or set of Pods as per the configuration.
- Pods – smallest component to run one or more containers with shared storage and network
- Deployment – provides instructions to Deployment manager in terms of desired state of the Pods & Replicasets. Deployment configures the ReplicaSet.
- ReplicaSet – ensures that specified number of Pods are running in a given time (for Stateless applications)
- StatefulSet – ensures that specified number of Pods are running in a given time (for Stateful applications)
- ReplicationController – obsolete and recommended to use Deployment using Replicaset
- Job – to run a single or multiple tasks by creating required number of Pods
- CronJob – creates the Jobs on the repeated schedule
Kubernetes Network Architecture View
- Ingress – to expose services running in the cluster (HTTP/HTTPS) to the outside world
- Ingress Controller – fulfills the responsibilites of Ingress. There are many options to choose from – AWS, AKS, GKE, GCE, NGINX, Ambassador, HAProxy, Kong, Traefik and many more.
- Service – to expose an application (running on set of Pods) as a load-balanced component
- Load Balancer – exposes the Service externally using a cloud provider’s load balancer
- Endpoint Slices – to track network endpoints within a Kubernetes cluster
- Network Policy – to control traffic at IP address or Port level
Kubernetes Storage Architecture View
- Volume – provides persistent storage to containers running in a Pod
- Persistence Volume – provides long-term storage and exists beyond containers, pods, and nodes.
- ConfigMap – stores config values (non-confidential data) as key-value store and provides them to Pods as environment variables, command-line arguments, or as configuration files in a volume
- Secret – stores sensitive data such as a password, a token, or a key.
Kubernetes RBAC Architecture View
Kubernetes uses standard Role-based Access Control (RBAC) method to manage permissions on resources in context with users and their associated groups and roles:
- Kubernetes also supports Attribute-based Access Control (ABAC) where access rights are granted to users through the use of policies which combine attributes together.
- Role represents set of permissions – there are no “deny” rules. Role binding grants the permissions to the users or group of users.
- Verbs are the actions such as “get, update, list, watch, create, delete, patch”.
- Service accounts are for processes (not humans) running in Pods. Typically, user accounts get fetched from the existing identity store (such as Microsoft Active Directory) but Service Accounts are maintanied locally by Kubernetes. It allows cluster users to create service accounts for specific tasks by following the principle of least privilege.
References