Developing containerized applications on Windows
Well-known container orchestration frameworks such as Kubernetes rose up in popularity meteorically with its widespread acceptance on Linux hosts. The ecosystem built using Kubernetes fueled the growth and made development on Linux hosts as mainstream. Applications that were developed on top of this framework were already modular and used smaller footprints than contemporary applications built for the cloud. With the popularity of macbooks for linux based development, it was easy to host the framework and the applications in personal computing space. The same did not hold for windows until later.
With the arrival of Docker runtime for windows and the Kubernetes cluster for windows, the situation changed. These tools allowed container images to be registered and the containers to be spun up with those images respectively which made it possible for applications to run on personal computers. Still, the existing popularity of supporting Linux virtual machines on Hyper-V reduced the wind on these efforts to allow native development of Kubernetes applications on Windows using these tools.
Two technologies made it possible for developers to overcome the reduced support on native development over Windows. First, the ability to specify insecure registry to house all the container images mean that the containers don’t require a login or have to go online to external registries to fetch their images. Second, the Kubernetes cluster for windows would accept this insecure registry as a parameter at startup to allow its orchestration framework to redirect all requests for container image lookups to the passed in registry. Together they helped the containers find and load their images for applications to run.
The entire developer workspace on the personal computers is in the hands of the developer. So the need to setup and use secure registries is of very little concern in the overall steps to run an application. The Kubernetes cluster for windows is also set up in a host facing network only which means that the traffic needs to be proxied or tunneled into the cluster even if there is outbound connectivity from the containers within the cluster. The insecure registry makes it easy for the developer to get going with the development rather than the otherwise elaborate deployment.
One of the advantages of hosting Docker and Kubernetes on Windows directly is that we can control their size. By provisioning the insecure registry entirely on a separate virtual machine, we can specify the storage to just exceed the total of all the images to be registered in that registry. This lets the Kubernetes on Windows to have a cpu and memory limit specified to support what is needed for the hosted application to run.
This separation of registry and container framework allows them to be more focused on their purpose and enables the developer to do more.
No comments:
Post a Comment