Translated from 日本語 • View original Hello. This is Akiyama from Azure Cloud Solution Architect.
In this article, we will write about how it has been and what has changed after one year since we started implementing AKS in our service.
Here's an article about Azure Kubenetes Service (AKS) migration that I wrote one year ago:
- Vol.1 Deciding to Migrate from App Service to AKS
- Vol.2 AKS(k8s) Preparations for Migration
- Vol.3 AKS(k8s) Migration
Update Management for AKS Cluster Versions
AKS supports minor versions from the latest version to two generations ago, so you need to catch up on minor versions released every 4-5 months. Reference: AKS Kubernetes Release Schedule
Mamoru Biz updates AKS clusters using a technique called in-place upgrades. This is a method of upgrading the version of the cluster that the system is using, and then upgrade the nodes in order. Reference: Upgrade your Azure Kubernetes Service (AKS) cluster
We also considered another method called Blue/Green deployment, but we didn't use it. As shown in the figure below, you can prepare a new version of the cluster in addition to the current cluster and switch between Front Door or Traffic Manager.
The benefits of in-place upgrades include:
- In-place (compared to switching to Blue/Green) if you only understand k8s in-place, you don't need to understand the Azure infrastructure configuration (in most cases)
- You need to register an IP address that can access the external APIs used by the service. If your outbound IP address changes, you need to take care of it.
The disadvantages of in-place upgrades are as follows:
- Blue/Green allows you to change versions at once, while in-place requires 0.1 upgrades.
- In Blue/Green, you can return to the original environment by switching back, but you can't do that in-place (in-place covers this point by pre-verifying in the three environments of development, verification, and production)
Considering these advantages and disadvantages, we are currently updating them through in-place upgrades.
Division of roles between development and infrastructure teams
The division of roles gradually changed in one year. When we migrated AKS a year ago, it was led by infrastructure members, who managed the manifest of Azure and, of course, k8s, and the developers were mainly responsible for modifying the application code. The figure is as follows.
As K8s has become more catch-up among developers, developers now write their own manifests for feature requests. The burden on infrastructure members has been significantly reduced, such as measures to keep the cluster running stably and developers' Pull Reqeuest reviews. The figure is as follows.
Future Prospects
Azure Container Apps was GA at Microsoft Build the other day. Reference: Azure Container Apps | Microsoft Azure
AKS cluster management is good for deeply understanding and utilizing k8s, but it is a relatively labor-expensive task. We are considering Azure Container Apps as a solution that can comprehensively manage microservices and reduce management costs.
Conclusion
Mamoru Biz is steadily growing its user base and needs to continue to have a stable infrastructure and scalability to deliver new features. Recently, not only Mamoru Biz, but also the development of our own services has been gradually increasing.
Therefore, we started working as an infrastructure team that consistently supports our overall services from a system in which infrastructure members operate separately for each individual. The members themselves are still working in conjunction with other tasks, but the organization is changing little by little.
At Colorkrew, you can experience both the development of your own services and the contract business. If you are interested in our company, please enter from the recruitment page .
If you are interested in supporting the introduction of a container-configured system, please contact us below. Serverless/Container Implementation Support |
