5 Awesome Views of Kubernetes Architecture

Post Views: 3,623

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

Max Brenner