Download as PDF, PPTX
![GKE: Create k8s Cluster gcloud container clusters get-credentials NAME [--internal-ip] [--region=REGION | --zone=ZONE, -z ZONE] [GCLOUD_WIDE_FLAG …]](https://image.slidesharecdn.com/devops-microserviceandkubernetes-190715123631/75/Devops-Microservice-and-Kubernetes-32-2048.jpg)
Uploaded byNodeXperts
Devops - Microservice and Kubernetes
This document provides an overview of microservices and various methodologies for deploying microservices. It begins with an introduction comparing monolithic and microservice architectures. Next, it discusses considerations for microservice design like scalability and complexity. It then covers challenges of deploying microservices like monitoring and scaling. The document proceeds to introduce Kubernetes as a container orchestration tool for deploying microservices. It includes descriptions of various Kubernetes components like pods, deployments, services, and ingress. Finally, it demonstrates deploying microservices locally using Minikube to simulate a Kubernetes cluster on a single node.
Devops - Microservice and Kubernetes
- 1.
- 2. Microservices over Monolithic Kubernetesfor Deployment Deploying of Microservices in local Environment Deploying of Microservices over GCP Overview of Kubernetes (Anil Chauhan) (Anil Chauhan) (Rahul Abrol) (Sapna Upreti) (Sapna Upreti)
- 3. Anil Kumar Chauhan,Head of Engineering - Successive Technologies About Me anil.chauhan@successive.tech facebook.com/anil.livelife www.linkedin.com/in/anilkchauhan/ ❖ 10+ Years of IT Experience ❖ Technical Architect and Trainer ❖ Worked as full stack developer on numerous web technologies ❖ Proficient on Cloud Agnostic Platform twitter.com/anillivelife
- 4. Enterprise Application -Checklist Use of emerging technologiesTeam must own the code Easy to understand and enhance Productive new members Scalability and availability Support to continuous deployment
- 5. Main Components: Monolithic Applications Traditionalway to build enterprise app, and deployed and scaled as a single package ● Client-side user interface ● Server-side application ○ Design Pattern(Services & Repositories) ● A database server
- 6. Monolithic Application Services Repositories Scaling anddeployed as a single package Business Layer Data Store User Interface
- 7. Monolithic Application: Example Products -product_id - product_name - product_price - market_id Users - user_id - user_name - market_id Markets - market_id - market_name A query to get the list of products and market name of the logged in user say with id=40 under price 300? SELECT product_name, market_name FROM products INNER JOIN markets on products.maket_id = markets.id INNER JOIN users on users.market_id = markets.id WHERE users.user_id = 40 AND products.product_price < 300
- 8. Monolithic Application -MVP version Dev Team 1 What if a big hit?
- 9. Monolithic Application -After few releases Dev Team 1 Dev Team 2 Dev Team 3 Dev Team 4 Areas where multiple teams working on same part
- 10. Monolithic - Pros/ Cons Not ideal for growing codebase. Barrier to adopting new technologies Steep learning curve Simple to develop, for small codebases Simple to Test Simple to deploy and scale Pros & Cons Slower release for large code base IDE-friendly
- 11. Checklist - Revisit Useof emerging technologies Team must own the code Easy to understand and enhance Productive new members Scalability and availability Support to continuous deployment
- 12. Design Considerations Micro Services Suitesof independently deployable services ● Organized around business capability ● Decentralized Database ● Loosely Coupled and Highly Cohesive ● Independently deployed
- 13. Microservice Application Users Service MarketService Products Service API Gateway Events 2 Replica 1 Replica
- 14. Microservice Application: Example products { id:1, name: ‘AWS’ price: 300, market: { id: 1, name: US } } Users { id: 1, name: ‘John Smith’ market: { id: 1, name: US } } markets { id: 1, name: US, currency: ‘$’, created_at: ‘123’, updated_at: ‘abc’ } ● Separate database per service as per business domain ● Maintain Duplicacy of data with single source of truth ● Eventual Consistency among services
- 15. Microservice - Pros/ Cons More moving parts Documentation overhead Complex infrastructure Better for complex application High scalability Ease of deployment Pros & Cons Harder to Debugging Easy to understand
- 16. Checklist - Revisit Useof emerging technologies Team must own the code Easy to understand and enhance Productive new members Scalability and availability Support to continuous deployment
- 17. Comparison (Productivity vsComplexity) Productivity Complexity For less complex app managing microservices will leads to extra efforts. Decoupling nature of microservices really pay off. Microservice Monolithic
- 18. Deployment Challenges withMicroservices Deployment and configuration of high number of services Monitoring of services for node failures Scaling of particular services and distribution of traffic Service Logs and Debugging Update strategy with zero downtime Rollback in case of any trouble
- 19. ● Invented byGoogle ● Managed by open source community ● Adopted by Microsoft and Amazon ● Run Anywhere Why to Choose? Kubernetes (K8s) An open-source system for automating deployment, scaling, and management of containerized apps
- 20.
- 21. Rahul Abrol, DevOpsEngineer - Successive Technologies About Me rahul.abrol@successive.tech facebook.com/rahul.abrol.96 www.linkedin.com/in/rahul-abrol-002042ab ❖ 3+ Years of IT Experience ❖ Site Reliability Engineer and Automation Expert ❖ Delivered Solutions for various Projects twitter.com/RahulAb75631000
- 22. Basic components ofKubernetes (Cloud) Cluster CLI Kubectl Master Node API Server Scheduler Controller Manager etcd Worker Node 1 kubelet kube-proxy docker Pod 1 Pod 2 Pod N Worker Node N kubelet kube-proxy docker Pod 1 Pod 2 Pod N UI Dashboard
- 23. Basic components ofKubernetes (local) CLI Kubectl Minikube Master Node Single Worker Node kubelet kube-proxy docker Pod 1 Pod 2 Pod N Local Cluster UI Dashboard
- 24. Basic components: Pods WorkerNode kubelet kube-proxy docker Pod 1 Pod 2 Pod N Containers ● Basic and smallest building block. ● All the connected containers deployed to a single pod ● Containers inside pod will live and die together ● All containers have common IP, and resources. ● Each POD has unique IP. User Log Product Report Log
- 25. Basic components: Deployments ●Scaling up and down of the pods. ● Manages releases and rollback ● Self Healing of system ● Assign a unique label to every set of pods, and used by services for discovery. Deployment Replica Set Replica: 2 Pod Pod User User Log Log label=user-service label=user-service
- 26. Basic components: Service ●Stable endpoint that load balances traffic among pods with similar label ● Discover the respective pods by the selectors ● With Service you don’t have to remember how many pods are running or where Deployment Replica Set Replica: 2 Pod Pod label=user-service label=user-service Service selector: user-service
- 27. Basic components: Ingress Service:user-service Type: NodePort Service: market-service Type: NodePort Service: product-service Type: NodePort Pod A label: user-service Pod B label: user-service Pod C label: market-service Pod D label: product-service Pod E label: product-service Pod Ingress Controller Service: ingress Type: LoadBalancer Public IP -Path: /users Service: user-service -Path: /markets Service: market-service -Path: /products Service: product-service
- 28. Deployment on GCP 28 (SapnaUpreti)
- 29. Sapna Upreti, Sr.Software Engineer - Successive Technologies About Me sapna.upreti@successive.tech facebook.com/sapna0214 www.linkedin.com/in/sapna-upreti-a093525b/ ❖ 4+ Years of IT Experience ❖ Technology Specialist ❖ Blogger ❖ Tech Speaker https://twitter.com/sapna0214
- 30. GKE: Prerequisites ● gcloudCLI ● Enabled the Google Kubernetes Engine API ● gloud init
- 31.
- 32. GKE: Create k8sCluster gcloud container clusters get-credentials NAME [--internal-ip] [--region=REGION | --zone=ZONE, -z ZONE] [GCLOUD_WIDE_FLAG …]
- 33.
- 35. K8s: Rollbacks ● Rollingout your application to previous version ● Set the revision that you want ● Kubernetes will scale up the corresponding ReplicaSet, and scaled down the current one Handy Commands: ● kubectl rollout history deployments products ● kubectl rollout status deployments products ● kubectl rollout undo deployments products
- 36. K8s: Rollbacks inaction 36
- 38. Deployment Strategies: RollingUpdates ● Replace each pod in the deployment with a new one ● Backwards compatibility ● New ReplicaSet created and old ones gets decreased V1 V1 V1 V1 V1 V1 V2 V1 V1 V1 V1 V2 V2 V2 V2 V2 V2 V2` ` ` `
- 39. Deployment Strategies: RollingUpdates (example)
- 40. Deployment Strategies: RecreateStrategy Terminate the old version and release the new one V1 V1 V1 V1 V1 V1 V1 V1 V2 V2 V2 V2` ` `
- 41. Deployment Strategies: Blue/Green ●Run two complete deployments of your application ● “green” version of the application is deployed alongside the “blue” version V1 V1 V1 V1 V2 V2 V1 V1 V2 V2 V2 V2
- 42. Deployment Strategies: Blue/Green(example)
- 43.
- 45.
- 46. Minikube: K8s clusteron Local UI CLI Kubectl Minikube Master Node API Server Scheduler Controller Manager etcd Single Node kubelet kube-proxy docker Pod 1 Pod 2 Pod N Local Cluster Dashboard
- 47. Minikube: Prerequisites Few handycommands: ● minikube start (pass VM option), default is VirtualBox ● minikube addons enable ingress ● VM Driver ○ macOS: VirtualBox, VMware Fusion, HyperKit ○ Linux: VirtualBox, KVM ○ Windows: VirtualBox, Hyper-V ● Install Minikube ○ brew cask install minikube (macOS) ● Install kubectl ● VT-x/AMD-v virtualization must be enabled in BIOS ● Internet connection on first run
- 48. Minikube: K8s Cluster Hurrah!Now we have K8s cluster running named as minikube ● kubectl config get-contexts
- 49. Minikube: K8s Cluster Changecontext to minikube ● kubectl config use-context minikube ● kubectl config get-contexts
- 50. Minikube: Deployment Deployments arerequirements you give to Kubernetes regarding your applications (your Pods) “Hey Kube, always keep 5 instances (or replicas) of these Pods running — always”
- 51. Minikube: Deployment (MarketsService) Container Port is the port that the application is running on. Readiness probes: when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready
- 52. Minikube: Deployment (ProductsService) ● A Deployment named demo-product is created ● four replicated Pods ● Pods are labeled as demo-products ● Image from docker ● Environment variables
- 53. Minikube: Deployment (UsersService) ● A Deployment named demo-users is created ● Two replicated Pods ● Pods are labeled as demo-users ● Image from docker ● Environment variables
- 54. Minikube: Service Expose ourpods using Services. “Not healthy? Killed. Not in the right place? Cloned, and killed.”
- 55. Minikube: Service (MarketsService) Each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service demo-markets service Selects demo-markets Pods
- 56. Minikube: Service (ProductsService) Each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service demo-products service Selects demo-products Pods
- 57. Minikube: Service (UsersService) Each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service demo-users service Selects demo-users Pod
- 58. Minikube: Ingress Ingress objectsare the rules that define the routes that should exist. Annotations to configure some options depending on the Ingress controller Target URI where the traffic must be redirected
- 59.
- 61. Minikube: UI Deploymentand Service
- 62. Minikube: Dashboard (minikubedashboard)
- 63. Minikube- in action(UI) 63
- 65.
- 66. Clouds and Tools Weat Successive Technologies use following tools for building Cloud Agnostic Platform.
- 67.
- 68.