In Apache Cassandra Lunch #41: Apache Cassandra Lunch #41: Cassandra on Kubernetes – Docker/Kubernetes/Helm Part 1, we discuss Cassandra on Kubernetes and give an introduction to Docker, Kubernetes, and Helm. The live recording of Cassandra Lunch, which includes a more in-depth discussion and a demo, is embedded below in case you were not able to attend live. If you would like to attend Apache Cassandra Lunch live, it is hosted every Wednesday at 12 PM EST. Register here now!
In Apache Cassandra Lunch #41: Apache Cassandra Lunch #41: Cassandra on Kubernetes – Docker/Kubernetes/Helm Part 1, we discuss Cassandra on Kubernetes and introduce containerization technologies and how they work.
Containers : “Get with the program”
Docker – One “Dockerfile” becomes an Image which runs as one container on a node / host.
Docker-Compose – Can run multiple containers on a node / host in as a composition. (Kompose)
Docker Swarm – Can run docker-compose at scale on many node / hosts.
Mesosphere/DCOS – Mesos, grand daddy of containerization adopted Docker, and Kubernetes
Kubernetes – Basically everyone who does anything uses Kubernetes to deploy big applications.
Kubernetes General Architecture
Nodes (minimum of 3 physical nodes)
Master Nodes / Control Plane (at least 1)
A master node is a node which controls and manages a set of worker nodes (workloads runtime) and resembles a cluster in Kubernetes. … All external communication to the cluster is via the API-Server. Kube-Controller-Manager, which runs a set of controllers for the running cluster.
Whenever master node under kubernetes fails, the cluster still remains in an operational mode. It doesn’t affect pod creation or service member changes. If worker node fails, master stops receiving updates from worker node
High availability / multi-master nodes use a load balancer to manage the API server which serves both the clients and the worker nodes
Worker Nodes (at least 2)
The worker nodes run the workloads. The worker node contains kubelet and kube-proxy that both connects to the pods within the docker. … A kubelet takes information from the master node and ensures that any pods assigned to it are running and configured in the desired state. All Kubernetes nodes must have a kubelet.
By themselves, don’t do much in Kubernetes.
Need to make it part of a Pod.
Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in your cluster. Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources.
Deployments / ReplicaSet (Stateless)
Leverages “PersistentVolume” that is managed as a resource.
“Sidecar” local to that node
Monitoring / Management
Job / CronJob
Tasks that run and stop.
Job – one-off tasks
CronJob – recurring tasks
The client (CLI), which lives on your local workstation.
The server (Tiller), which lives on the Kubernetes cluster to execute what’s needed.
Chart: A package of pre-configured Kubernetes resources.
Release: A specific instance of a chart which has been deployed to the cluster using Helm.
Repository: A group of published charts which can be made available to others.
Reduces duplication & complexity
Smoothens the learning curve
The Operator pattern aims to capture the key aim of a human operator who is managing a service or set of services. Human operators who look after specific applications and services have deep knowledge of how the system ought to behave, how to deploy it, and how to react if there are problems.
deploying an application on demand
taking and restoring backups of that application’s state
handling upgrades of the application code alongside related changes such as database schemas or extra configuration settings
publishing a Service to applications that don’t support Kubernetes APIs to discover them
simulating failure in all or part of your cluster to test its resilience
choosing a leader for a distributed application without an internal member election process
Robots are better at doing repetitive tasks
Simplifies the overall complexity of an operation into a few configurable components
Cassandra.Link is a knowledge base that we created for all things Apache Cassandra. Our goal with Cassandra.Link was to not only fill the gap of Planet Cassandra, but to bring the Cassandra community together. Feel free to reach out if you wish to collaborate with us on this project in any capacity.
We are a technology company that specializes in building business platforms. If you have any questions about the tools discussed in this post or about any of our services, feel free to send us an email!
Posted in Modern Business|Comments Off on Apache Cassandra Lunch #41: Cassandra on Kubernetes – Docker/Kubernetes/Helm Part 1