Kubernetes as Orchestrator for A10 Lightning Controller
Download as PPTX, PDF0 likes1,451 views
The document discusses using Kubernetes as an orchestrator for A10 Lightning Controller. Some key points: 1) Kubernetes allows for automatic recovery of pods on failure, easy rolling upgrades of code, and automated scaling of microservices. 2) Using Kubernetes allows the controller to be deployed on-premise and scaled across multiple VMs, with automated launching and scaling. Installation is also now independent of the underlying infrastructure. 3) The journey involved moving from a manual deployment to a Kubernetes deployment, which simplified overlay networking, environment variable passing, and simplified adding/replacing nodes.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Kubernetes as Orchestrator for A10 Lightning Controller (20)
Ad
More from Akshay Mathur (20)
Recently uploaded (20)
Kubernetes as Orchestrator for A10 Lightning Controller
- 1. Confidential | ยฉA10 Networks, Inc. Using Kubernetes as Orchestrator for A10 Lightning Controller Akshay Mathur Manu Dilip Shah
- 2. A10 Lightning Application Delivery Service DATA CONTROL Analytics Admin Portal API Client A10 Lightning Controller REST API LADC Cluster Application ServicesClients Lightning Controller โข A micro services based application โข Configuration, Visibility, Analytics โข Multi-tenant portal โข Programmability with REST APIs Lightning ADC โข Scale-out โข Traffic Management โข App Security
- 4. Why we thought of Kubernetes โข On failure, K8s brings up the pod automatically โข Rolling upgrade of code can be done easily โข Scaling policy can be setup to scale each micro service as needed โข Pod health can be monitored easily and acted upon
- 5. What we achieved at high level โข Controller was only available as SaaS โข Launch and Scaling was manual โข Installation was dependent on underlying infrastructure platform โข Controller is available for on-premise โข It can be scaled from One VM to Multiple depending on use case โข Launch and Scaling is automated โข Installation is independent of underlying infrastructure platform From AWS VMs to K8s Containers in Multiple Environments
- 6. Current Environment for Controller โข Kubernetes core components โข Kube-dns โ Internal DNS service โข Flannel โ Overlay networking โข Heapster โ Monitoring of pods โข Kubernetes Dashboard - Helps monitoring the pods โข jq โ Programmatically Editing JSONs for K8s objects
- 7. The Journey: From ๏ to ๏ โข Everything was manual to start with โข Selecting Master and Minion โข Mapping node port to container port โข Cross node communication Configuration โข Limitations Realized โข Cant run same type of pod on one node โข Packaging and distribution issues e.g. build process automation โข Data loss when node stops
- 8. The Journey: From ๏ to ๏ โข Second Level Issues โ After some level of simplifications โข Cumbersome overlay network configuration โข Passing env info to pod โ Startup script env variables are not scalable โข Installation was still too many steps โข Thought for Future โ Solved now โข Adding node to the K8s cluster when more capacity is needed โข Migrating static IP of the node to other node when node is replaced โข Adding component in future with minimal change in existing components
- 9. Design Choices โข Keep all micro-services as is โข One K8s service per micro-service โข One pod per k8s deployment โข Multiple services exposed externally โข Continue to use third-party registry service โข Kubernetes Registry Service can be used instead of third-party
- 10. Accessing Micro Services โข Multiple micro services of Controller are required to be accessed from outside โข Micro services accessing each other also canโt depend on IP address โข Kubernetes Services and kube-dns allow fixing name as well as a fixed IP address for each service โข All internal access (between components) is using service name โข Service IP is mapped to Node IP for all external access โข Public static IP is assigned to the node for external access
- 11. Simplifying Networking โข Each pod gets the IP address that is internal to the node โข Overlay networking facilitates communication between pods across nodes โข Flannel creates an overlay network that spans across nodes โข Each pod gets IP address from same subnet โข This subnet is internal to the K8s cluster โข This provides seamless communication between pods across nodes โข Private Subnet for Service IPs is configured in K8s configuration
- 12. Overlay Network
- 13. Persisting Data โข Pods may come and go or can spawn across nodes โข Persistence is required for maintaining the state across reboots or across clusters โข NFS, AWS EBS, GCE Persistent Disk or Azure Disk can be used as K8s Persistent Volume (PV) โข In K8s Deployment object, โPV Claimsโ can be done by each Pod, as needed โข K8s provides PV matching the Claim to the Pod โข This mounts the PV file system into containerโs file system
- 14. Storage Objects in Kubernetes
- 15. Deploying Clustered Applications โข Cluster application (e.g. datastores) each pod need to know about other pod running same application โข Such applications needs to be deployed using K8s Stateful Set โข K8s Stateful Set provide fixed names for each instance/pod โข PV Claims in each instance of Stateful Set also have fixed names โข Having fix names help a lot in the configuration and functioning of clustered applications โข When the application requires more capacity, it is easy to add
- 16. We do many exciting things You can join the team [email protected] [email protected] ๏ Thanks ๏