Design Cloud-Native Secure Environment to Host Your Enterprise Application
This article would help to draft an infrastructure layout with Network, IP, VM design for your HA application to be hosted in HA Kubernetes cluster.
Let’s assume your organization is planning to develop an enterprise solution (name it opendrapp) using microservice architecture having below components and host them in a private cloud.
- OpenDrApp-UI: Reactjs based app.
- OpenDrApp-ACL: OpenID based user access control.
- OpenDrApp-CRM.
- OpenDrApp –PC &OrderCare with PMS, PIS, CAM, BM, WM, NIM etc
- OpenDrApp-Charging.
- OpenDr — Billing.
Database: Cloud-native database hosted on Kubernetes in HA &FT config.
Cache/key store: cloud-native hosted in Kubernetes in HA config.
Message broker: cloud-native hosted on Kubernetes in HA config.
Let’s say architecture building blocks of the OpenDrApp would be something like below. Please note that each block may contain multiple individually deployable components. Only UI will be exposed outside.
Let’s try to design the environment to support the above application. We will try to design as vendor independent as possible them would discuss vendor specific alternative approach. We will be requiring below infrastructure to support the application.
- Highly-available Kubernetes cluster to host application, database, message broker and key store solution.
- Highly-available object storage. Which would be coupled with Kubernetes cluster to store persistence data of database, broker, key store and application logs etc.
- A HA load balancer to route the external traffic to Kubernetes workers.
Let’s discuss the above design in details.
Network Design
- Private subnet for OpenDrApp VM communication: It’s a 10.0.1.0/24 subnet with gateway 10.0.1.0. Router will have external link to organization’s internal satellite server to receive OS patches. All the VM will primarily be connected to this subnet. Kubernetes, Storage VMs will interact using this network. Will recommend multiple similar private subnet in case of network redundancy requirement.
- One provider network towards organization internal management network.
- One Provider network towards traffic network which to be exposed externally and internally.
VM and IP Design
JumpBox: This would be the infrastructure control node of the cluster. Lets say ansible orchestration node. Only this node will have management IP attached and this will connect to other nodes of the cluster with internal subnet IP.
LBs: Will host software load balancer top of VIP. Will have traffic interface to accept http load from outside and forward to Kubernetes workers over internal subnet.
Please follow the link to my blog to configure HA LB.
K8s Master/Worker: Kubernetes master/worker will have internal interface only. Master Worker communication will happen over internal subnet only. Also workers will access to object storage using internal subnet. Please adjust the number of worker nodes based on your need.
Please visit https://kubernetes.io/ or follow the link to my blog to setup HA K8s cluster.
If you wish to setup a secure private docker registry please follow the link to my blog.
Ceph MN/OSD: Ceph MN/OSD will also have internal interface only. K8s workers will interact over internal subnet. Please adjust the additional volume and number of OSD nodes based on your application’s replication, retention and data volume need.
Please follow the link to setup a HA ceph cluster.
Openstack related alternatives: LB nodes could be replaced by openstack load balancer. Please make sure to have proper network redundancy.
Google Cloud/AWS/ Azure alternatives: LB nodes to be replaced by load balancer service. Also proper network redundancy to be planed. Appropriate Kubernetes engine(managed k8s cluster) could also be considered. Ceph to be replaced by cloud storage.
Please do let me know in the comments section if you need any further information, clarification or help to setup HA DB, Key Store or broker setup.
Originally published at https://dzone.com.
