If downtime is not an option for you and your application needs to be extremely low-latency; what cocktail of open source projects can facilitate this best? Both Kubernetes and Apache Ignite are Open Source Frameworks that work exceedingly well together to achieve said goals. By working with containerization Kubernetes helps enable developers to work seamlessly with new versions of their applications, running them where they want with a flexibly scalable experience. Apache Ignite is the perfect complement to this. As a memory-centric platform Ignite allows you to access distributed data sets processing them using SQL and key-value operations, execute computations and much more. For the purposes of this webinar we will walk through the basics of a Kubernetes and Ignite deployment and how to set up a Apache Ignite cluster addressing the Kubernetes IP Finder, the Kubernetes Ignite Lookup Service, Sharing the Ignite Cluster Configuration, how to Deploy your Ignite Pods and Adjusting the Ignite Cluster Size when you need to scale. All in all, this should be an informative session which should enable you to work with both technologies for a better operational experience with your cluster.
Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood
Deploy like a Boss: Using Kubernetes and Apache Ignite!
1. DEPLOY LIKE A BOSS: USING
APACHE® IGNITETM AND
KUBERNETES®
DANI TRAPHAGEN
SOLUTION ARCHITECT
GRIDGAIN SYSTEMS
@DTRAPEZOID
2. AGENDA
• Setting up a Apache Ignite cluster
• Using the Kubernetes IP Finder and the Kubernetes Ignite
Lookup Service
• Sharing the Ignite Cluster Configuration
• Deploying your Ignite Pods
• Adjusting the Ignite Cluster Size when you need to Scale
• How to try it out with Azure!
5. APACHE IGNITE PLATFORM (VERSION 2.1+ DEPICTED)
KUBERNETES WORKS WITH VERSIONS 1.9 AND ABOVE
Apache Ignite
Cluster
APIs to interact
with your data
Deployment
options
What it is:
6. APACHE IGNITE FEATURES
Ignite Persistence
ACID Compliance
Complete SQL Support
Key-Value Store/APIs
Collocated Processing
Scalability and Durability
8. KUBERNETES IN A SIMPLE DEFINITION
“Kubernetes intends to
radically simplify the task of
building, deploying and
maintaining distributed
systems.”
Kubernetes: Up and Running:
Dive into the Future of
Infrastructure
By: Kelsey Hightower
What it is:
9. K8 FEATURES
Automatic Binpacking
Horizontal Scaling
Automated Rollouts and Rollbacks
Storage Orchestration
Self-Healing
Service Discovery and Load Balancing
Secret and Configuration Management
Batch Execution
11. BENEFITS OF K8 (VERSION 1.7)
Cost Efficiency
Use of containers by multiple developers ensures shared
resourcing rather than redundancy
High Availability and Performance
Self-healing: Deploying with K8 and setting rules for a
set number of nodes, will ensure your cluster can always
handle the transactions hitting it
No more pager duty
Get home to your pet chinchilla sooner
12. SETTING UP AN APACHE IGNITE CLUSTER
Step 1:
What is your use case?
Seriously, what is your use
case?
I’m not kidding. Use case, then
set up…
Cart before horse please.
13. SETTING UP AN APACHE IGNITE CLUSTER
1. Download Apache Ignite
2. Make sure to add the ignite-
kubernetes Maven Dependency to
your pom.xml
3. Try using examples from our
docs.
14. SETTING UP K8 ON A LOCAL MACHINE
Install K8 where you intend
AWS
Google Cloud
Dev Machine
Set your $PATH w/K8
Install Kubectl
Follow K8 Docs
15. KUBERNETES DISCOVERY
Multicast = ☹
Use Static IP Finder & list Ignite IPs, K8
will dynamically assign them
You can use other cloud Ignite IP
finders but you need K8 to running
in the cloud env.
What’s the point of the
TcpDiscoveryKubernetesIpFinder?
16. USING THE KUBERNETES IP FINDER AND THE KUBERNETES IGNITE
LOOKUP SERVICE
Apps & nodes running outside of K8 & Ignite will not be able to reach the
cluster
K8 service should be deployed before Ignite cluster boot
The Ignite Pods internal IPs will be maintained by the K8 service.
Service name must be equal to setServiceName(String)
This will be `ignite` as a default
https://ignite.apache.org/releases/latest/javado
c/org/apache/ignite/spi/discovery/tcp/ipfinder/
kubernetes/TcpDiscoveryKubernetesIpFinder.ht
ml
21. CONFIGURING YOUR IGNITE PODS
2 Things Needed!
1. Apache Ignite Configuration File with the
Kubernetes IP Finder
2. YAML Configurations for the Apache Ignite
pods/nodes
Steps:
Create your ignite-service.yaml
kubectl create -f ignite-service.yaml
kubectl get svc ignite
22. SHARING IGNITE CLUSTER CONFIGS
Confirm the ignite
service was created
Make a path to the
persistence volume
docker will use to pass
the kubernetes config
‘example-kube.xml’
24. PERSISTENT VOLUME BOUND?
Make sure your
persistent volume is
bound to the claim
kubectl get pvc
ignite-volume-claim
kubectl get pv ignite
volume
use xhyve driver so you can access persistent volumes
minikube start --vm-driver=xhyve
& modify the directory path "/data/ignite" that is used in
the examples to "/Users/<username>/data/ignite"
25. DEPLOYING YOUR IGNITE PODS
Now it’s time to launch
kubectl create -f ignite-
deployment.yaml
kubectl get pods
Get the logs and examine for each
cluster…ex)
kubectl logs ignite-cluster-3454482164-
d4m6g
Scale out:
kubectl scale --replicas=5 -f ignite-
deployment.yaml
27. USING MINIKUBE FOR LOCAL DEV
A good place to start for exploration
When you want to get in the cloud - pick your
poison
Post on setup w/Azure by Ignite PMC Denis
Magda:
https://dzone.com/articles/deploying-apache-ignite-
in-kubernetes-on-microsoft
https://kubernetes.io/docs/setup/pick-right-
solution/#turnkey-cloud-solutions
30. 2. CONNECT TO YOUR CLOUD ENVIRONMENT FROM YOUR
LOCAL MACHINE, EX) AZURE
#connect to cluster, make sure your sshkeys are setup
az acs kubernetes get-credentials --resource-
group=myResourceGroup --name=myK8sCluster
#make sure you see the k8s-agents & master
kubectl get nodes
32. 4. CREATE THE K8 LOOKUP SERVICE
#using above link, next to the number 4, create the file then initiate the service
kubectl create -f ignite-service.yaml
#you will see that the ignite service is under the services tab
33. 5. DEPLOY YOUR APACHE IGNITE CLUSTER
#create the ignite-deployment.yaml file following instructions here
kubectl create -f ignite-deployment.yaml
#you will see that the ignite cluster is running in kubernetes
34. ADJUSTING THE IGNITE CLUSTER SIZE WHEN YOU NEED TO SCALE
•When you want to elasticly scale out your cluster with K8:
• kubectl scale –replicas=<n> -f ignite-
deployment.yaml
• Run:
• kubectl get pods
•Let’s say you want 5 nodes?
• kubectl scale --replicas=5 -f
~/kubernetes_dev/azure/ignite-deployment.yaml
•You will see your cluster scale out – in this case from 2 to
5 nodes!
36. RESOURCES
Denis Magda’s & Akmal Chaudhri’s blog’s on
deploying Ignite w/K8 and Azure or AWS:
https://dzone.com/articles/deploying-apache-ignite-in-
kubernetes-on-microsoft
https://www.gridgain.com/resources/blog/kubernetes-and-
apacher-ignitetm-deployment-aws
Tutorials
https://kubernetes.io/docs/tutorials/
K8 Book by Kelsey Hightower:
http://shop.oreilly.com/product/0636920043874.do
Ignite Book by Shahim & others:
https://leanpub.com/ignite
37. ANY QUESTIONS?
Reach me on Twitter
@dtrapezoid
Use #apacheignite
Checkout
http://ignite.apache.org
Notes de l'éditeur
Durable Memory
Ignite's durable memory component treats RAM not just as a caching layer but as a complete fully functional storage layer. This means that users can turn the persistence on and off as needed. If the persistence is off, then Ignite can act as a distributed in-memory database or in-memory data grid, depending on whether you prefer to use SQL or key-value APIs. If the persistence is turned on, then Ignite becomes a distributed, horizontally scalable database that guarantees full data consistency and is resilient to full cluster failures.
Ignite Persistence
Ignite native persistence is a distributed, strongly consistent disk store that transparently integrates with Ignite's durable memory.
ACID Compliance
Data stored in Ignite is ACID-compliant both in memory and on disk, making Ignite a strongly consistent system. Ignite transactions work across the network and can span multiple servers.
Complete SQL Support
Ignite provides full support for SQL, DDL and DML, allowing users to interact with Ignite using pure SQL without writing any code. This means that users can create tables and indexes as well as insert, update, and query data using only SQL. Having such complete SQL support makes Ignite a one-of-a-kind distributed SQL database.
Key-Value
The in-memory data grid component in Ignite is a fully transactional distributed key-value store that can scale horizontally across 100s of servers in the cluster. When persistence is enabled, Ignite can also store more data than fits in memory and survive full cluster restarts.
Collocated Processing
Most traditional databases work in a client-server fashion, meaning that data must be brought to the client side for processing. This approach requires lots of data movement from servers to clients and generally does not scale. Ignite, on the other hand, allows for sending light-weight computations to the data, i.e. collocating computations with data. As a result, Ignite scales better and minimizes data movement.
Scalability and Durability
Ignite is an elastic, horizontally scalable distributed system that supports adding and removing cluster nodes on demand. Ignite also allows for storing multiple copies of the data, making it resilient to partial cluster failures. If the persistence is enabled, then data stored in Ignite will also survive full cluster failures. Cluster restarts in Ignite can be very fast, as the data becomes operational instantaneously directly from disk. As a result, the data does not need to be preloaded in-memory to begin processing, and Ignite caches will lazily warm up resuming the in memory performance.
Ignite Persistence
Ignite native persistence is a distributed, strongly consistent disk store that transparently integrates with Ignite's durable memory.
ACID Compliance
Data stored in Ignite is ACID-compliant both in memory and on disk, making Ignite a strongly consistent system. Ignite transactions work across the network and can span multiple servers.
Complete SQL Support
Ignite provides full support for SQL, DDL and DML, allowing users to interact with Ignite using pure SQL without writing any code. This means that users can create tables and indexes as well as insert, update, and query data using only SQL. Having such complete SQL support makes Ignite a one-of-a-kind distributed SQL database.
Key-Value
The in-memory data grid component in Ignite is a fully transactional distributed key-value store that can scale horizontally across 100s of servers in the cluster. When persistence is enabled, Ignite can also store more data than fits in memory and survive full cluster restarts.
Collocated Processing
Most traditional databases work in a client-server fashion, meaning that data must be brought to the client side for processing. This approach requires lots of data movement from servers to clients and generally does not scale. Ignite, on the other hand, allows for sending light-weight computations to the data, i.e. collocating computations with data. As a result, Ignite scales better and minimizes data movement.
Scalability and Durability
Ignite is an elastic, horizontally scalable distributed system that supports adding and removing cluster nodes on demand. Ignite also allows for storing multiple copies of the data, making it resilient to partial cluster failures. If the persistence is enabled, then data stored in Ignite will also survive full cluster failures. Cluster restarts in Ignite can be very fast, as the data becomes operational instantaneously directly from disk. As a result, the data does not need to be preloaded in-memory to begin processing, and Ignite caches will lazily warm up resuming the in memory performance.
The name Kubernetes originates from Greek, meaning helmsman or pilot, and is the root of governor and cybernetic. K8s is an abbreviation derived by replacing the 8 letters “ubernete” with “8”.
Startes w/Need for Containerization, VMs are clunky, not very portable and require the OS package manager – Containers are small, fast, portable and use OS-level virtualization. Through Docker they have become popular since 2013, linux containers have been used as a packaging mechanism for distributed applications in a microservices style architecture and run CI/CD. Docker is dev centric, allowing for shared images including your code, binaries, configs…etc. Developers and operators generally love containers.
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery.
Automatic binpacking
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
Horizontal scaling
Scale your application up and down with a simple command, with a UI, or automatically based on CPU usage. – Horizontal Pod Autoscaler – sets the number of pods in a replication controller, deployment or replica set based on observed CPU utilization (or with custom metrics if desired)
Automated rollouts and rollbacks
Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
Storage orchestration
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as GCP or AWS, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
Self-healing
Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
Service discovery and load balancing
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives containers their own IP addresses and a single DNS name for a set of containers, and can load-balance across them.
Secret and configurationmanagement
Deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration.
Batch execution
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
Automatic binpacking
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
Horizontal scaling
Scale your application up and down with a simple command, with a UI, or automatically based on CPU usage. – Horizontal Pod Autoscaler – sets the number of pods in a replication controller, deployment or replica set based on observed CPU utilization (or with custom metrics if desired)
Automated rollouts and rollbacks
Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
Storage orchestration
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as GCP or AWS, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
Self-healing
Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
Service discovery and load balancing
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives containers their own IP addresses and a single DNS name for a set of containers, and can load-balance across them.
Secret and configurationmanagement
Deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration.
Batch execution
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
The Kubernetes Master is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: kube-apiserver, kube-controller-manager and kube-scheduler.
Each individual non-master node in your cluster runs two processes:
kubelet, which communicates with the Kubernetes Master.
kube-proxy, a network proxy which reflects Kubernetes networking services on each node.
The IP finder automatically lookups IP addresses of all the alive Ignite pods by talking to a distinct Kubernetes service that keeps all the endpoints up to date.
Discovery SPI implementation that uses TCP/IP for node discovery. Nodes are organized in ring. So almost all network exchange (except few cases) is done across it.
service will maintain a list of all endpoints (internal IP addresses) of all containerized Ignite pods running so far. The name of the service must be equal to setServiceName(String) which is `ignite` by default.
public class TcpDiscoveryKubernetesIpFinder extends TcpDiscoveryIpFinderAdapterIP finder for automatic lookup of Ignite nodes running in Kubernetes environment. All Ignite nodes have to deployed as Kubernetes pods in order to be discovered. An application that uses Ignite client nodes as a gateway to the cluster is required to be containerized as well. Applications and Ignite nodes running outside of Kubernetes will not be able to reach the containerized counterparts.The implementation is based on a distinct Kubernetes service that has to be created and should be deployed prior Ignite nodes startup. The service will maintain a list of all endpoints (internal IP addresses) of all containerized Ignite pods running so far. The name of the service must be equal to setServiceName(String) which is `ignite` by default.
As for Ignite pods, it's recommended to label them in such a way that the service will use the label in its selector configuration excluding endpoints of irrelevant Kubernetes pods running in parallel.
The IP finder, in its turn, will call this service to retrieve Ignite pods IP addresses. The port will be either the one that is set with TcpDiscoverySpi.setLocalPort(int) or TcpDiscoverySpi.DFLT_PORT. Make sure that all Ignite pods occupy a similar discovery port, otherwise they will not be able to discover each other using this IP finder.
Optional configuration
The Kubernetes service name for IP addresses lookup (see setServiceName(String))
The Kubernetes service namespace for IP addresses lookup (see setNamespace(String)
The host name of the Kubernetes API server (see setMasterUrl(String))
Path to the service token (see setAccountToken(String)
Both registerAddresses(Collection) and unregisterAddresses(Collection) have no effect.
Note, this IP finder is only workable when it used in Kubernetes environment. Choose another implementation of TcpDiscoveryIpFinder for local or home network tests.