Deploy like a Boss: Using Kubernetes and Apache Ignite!
•Descargar como PPTX, PDF•
4 recomendaciones•2,579 vistas
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.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Deploy like a Boss: Using Kubernetes and Apache Ignite!
Similar a Deploy like a Boss: Using Kubernetes and Apache Ignite! (20)
Más de Dani Traphagen
Más de Dani Traphagen (7)
Último
Último (20)
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!
- 3. BY THE END – THIS WILL BE YOU WILL BECOME THE…
- 4. FIRST - APACHE IGNITE’S PLATFORM What it isn’t:
- 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
- 7. SECOND – DEPLOYMENT WITH KUBERNETES (K8) What it isn’t:
- 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
- 10. APACHE IGNITE + K8 CLUSTER ARCHITECTURE https://kubernetes.io/docs/admin/high-availability/
- 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
- 17. USING DOCKER ON LOCAL MACHINE WITH MINIKUBE
- 18. SHARING THE IGNITE CLUSTER CONFIGURATION
- 19. SERVICE STARTUP & SHARING CONFIGS Minikube - Two basic commands minikube start minikube dashboard Kubectl kubectl create -f ~/<path-to-project>/<project- name>/config/ignite-service.yaml
- 20. NOW KUBERNETES IS RUNNING!
- 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’
- 23. SUCCESS Now, do this for the ignite-volume- claim.yaml
- 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
- 26. MANY DEPLOYMENT OPTIONS On Premise Cloud Azure EC2 Google Cloud
- 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
- 28. DARE TO TRY?
- 29. 1. DEPLOY CLOUD ENVIRONMENT
- 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
- 31. USING THE DASHBOARD 1.kubectl proxy 2.http://localhost:8001/ui
- 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!
- 35. OVERALL STEPS Ignite Download: https://ignite.apache.org/download.cgi Run Kubernetes Locally: https://kubernetes.io/docs/getting-started-guides/minikube/ Deploy Kubernetes & Ignite https://apacheignite.readme.io/docs/kubernetes-deployment
- 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
Notas del editor
- 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.
- Kube-cuddle