Continuing from blog post Part 1, the objective is to go through some essentials for planning out a simple Azure Kubernentes Cluster to host your containerized or microservices application in a development/test or proof of concept (POC) environment. Also, to lay out the foundation to build upon towards a production grade environment.
Identity Access Security
Kubernetes Service accounts or Azure AD Integration RBAC
The default and basic approach are with Kubernetes Service accounts. This is simply a service account where its credentials are stored in the Kubernetes cluster and managed via the Kubernetes API. This is not in any means an identity management solution.
The other option is to integrate AKS with Azure AD to leverage its identity management capabilities and role-based access controls (RBAC). This allows for more control and manageability. One key practical use case is where application developers and system administrators can have role-based access using their existing Azure AD identities and can be centrally managed in via Azure AD Groups and assigned permissions. Other advance controls is applying Azure AD conditional access for MFA for highly privileged access.
For further details:
- Access and identity options for Azure Kubernetes Service (AKS)
- Best practices for authentication and authorization in Azure Kubernetes Service (AKS)
Persistent Database Storage
As all applications require some persistent storage such as a database or files, you need to consider persistent storage options as pods in your application are created and killed. Pods are known to be ephemeral and typically stateless by default. Note that storing data in a pod is lost when the pod is killed in situations such as restarting and scaling operations. As there are many options, but two option that come to mind are as follows:
Database in a pod. This is where you have SQL server, mysql or postgres running in a pod and setup persistent storage through a persistent volume outside of the pod yet in the node.
Database outside of the AKS cluster in Azure. You can leverage Azuure SQL, Azure PostgresDB, Azure MySQL, Cosmos DB to be the persistent database storage. This is managed separately from the AKS cluster which may be a benefit. As a best practice, this approach would be more ideal. One of the distinct benefits is more scalability and its positive PaaS characteristics. You can either manually set up the database and provide the appropriate connection string and access security mechanisms. A more streamlined approach is to use Open Service Broker for Azure (OSBA) to provision azure databases from within the AKS cluster. Note from my experiences that using OSBA is a little heavy with installing and getting used to the tools, CLI and helm charts to get started.
For further details:
- Kubernetes – Persistent Volumes
- Connecting Azure Kubernetes Service and Azure Database for PostgreSQL – Single Server
- Azure Database for PostgreSQL (Open Service Broker Azure)
What is the monthly budget?
AKS is partially a PaaS offering and IaaS offering. The PaaS portion is the cluster management that is free. The IaaS Portion are the AKS nodes which are paid virtual machines with same pricing model.
Here is an example of AKS pricing (CAD$) for a 1 node VM cluster in Canada Central region:
Summary of my personal recommendations for a development environment are as follows
- AKS cluster with at least 1 node (scale up as needed)
- Stick with Linux containers, but depends on your application technical requirements
- Depending on public or private network access choose Azure load balancer type accordingly.
- Create or use existing virtual network and then deploy AKS into a subnet
- Azure Container Networking Interface (CNI) plugin
- Azure AD Integration for identity and access management and RBAC support
- Azure PaaS Database solutions such as Azure SQL or Azure Postgres DB
- Budget at least $105 CAD/month for the smallest size
My hope is that I covered the essentials to give a summary and direction from starting from a development or proof of concept environment with the foundation and intention to a production grade AKS environment. There are many more considerations with respect to breadth and depth, but I hope this is a good starting point that I wish I had when I started out.
One thought on “Planning Essentials for an Azure Kubernetes Cluster – Part 2”
Pingback: Planning Essentials for an Azure Kubernetes Cluster – Part 1 – Roy Kim on Azure, Office 365 and SharePoint