Server Man
Well-Known Member
- May 17, 2015
- Windows 10
- Chrome 69.0.3497.100
Share On: Twitter
This blog is part of a series for the Top 10 Networking Features in Windows Server 2019!
-- Click HERE to see the other blogs in this series. This concludes our
Top 10 List. We hope to see you at Ignite next week!
Look for the Try it out sections then give us some feedback in the comments!
In today’s increasingly competitive and fast-paced technology market, enterprises are constantly discovering amazing new ways to innovate and evolve. One such area with expanding interest in recent years is application modernization using containers and container orchestration. The numbers speak for themselves — a recent press release (06/18) by Allied Market Research concluded that:
The global application container market was valued at $698 million in 2016, and is projected to reach $8.2 billion by 2025.
As applications are lifted-and-shifted from VMs to containers, IT Pros and Dev Ops teams require the same network management agility of Software-Defined Datacenter (SDDC). Kubernetes, the de facto container orchestration tool, addresses this gap under the umbrella of a standardized & open-sourced framework.
In Kubernetes version 1.9 with Windows Server, version 1709 we first announced beta for Windows Server containers. Now, with Windows Server 2019, we greatly improved usability of Kubernetes on Windows by enhancing platform networking resiliency and support of container networking plugins.
Additionally, customers deploying workloads on Kubernetes demand network security to protect both Linux and Windows services using embedded tooling. The Windows Networking team has been working closely with Tigera, who is an industry-recognized leader in this space, and is pleased to announce upcoming availability of Tigera Calico for Windows. Both companies are working jointly with TAP customers to deploy Calico on Windows in POC environments, with current focus on network policy enforcement. Network management using dynamic routing (BGP) and IPAM is also on Tigera’s roadmap, with forthcoming Calico CNI support on Windows.
Kubernetes + Windows Server 2019
The Windows Networking team (together with the Kubernetes community) has done tremendous work on both the platform and open-source front to enable a smooth interoperability between Windows and other first-class citizens belonging to the Kubernetes project.
Windows Server 2019 supports all the Kubernetes networking building blocks (“primitives”), such that you’re able to deploy mixed-OS Kubernetes clusters in the environment of your choice. Whether you’re looking for maximum control in your own on-premises datacenter, or conveniently getting it all provisioned on Azure infrastructure – all the networking pieces are ready for composing your own cluster now.
Here is a timeline summarizing the groundbreaking achievements that enabled Windows to pursue its very own “Kubistential” awakening:
Figure 1: Kubernetes improvements since Windows Server 2016
The major headline from the graphic above, is that Kubernetes for Windows is projected to GA with Kubernetes 1.13, including official support on Windows Server 2019. Considering that Kubernetes is the most actively discussed GitHub project in the world today, this means you have a really compelling new force gravitating you towards Kubernetes on Windows: both open-source community and platform-level support from Microsoft enterprise.
Equally exciting to us, is that customers and users are also beginning to see these incremental improvements:
“My windows node successfully joined the cluster and I’m able to schedule a pod on it. Definitely a victory.”
– Nikhil Shampur, ESRI.
“To me, it’s great to see that Kubernetes on Windows is now working so smoothly!”
– Ulrich Rabenstein, SAP, Developer
Let’s make things more concrete through the lens of a (simplified) deployment example to demonstrate how Kubernetes features (all supported on Windows Server 2019) address the needs of an enterprise.
Deploying Kubernetes on Windows Server 2019: A reference example
Consider a Windows-based, .NET application consisting of an ordering service, location service, and identity service. Here are some basic, yet plausible example needs:
Figure 2: Monolithic application
In theory, we could take this application and simply run it in a container, with each of these services communicating via shared networking and compute resources. However, in pursuit of technical benefits such as high cohesion and low coupling (see microservices architecture), work could also be done to refactor the application, and split it up into more manageable components.
Figure 3: Microservices application
In doing so, it quickly becomes apparent that the most effective way to redesign the architecture and standardize this distributed system, is through a container orchestrator. Why? Well, Kubernetes already provides native features that satisfy these requirements, it enhances portability in case of future changes, and there is no need to reinvent the wheel. Here’s the Kubernetes solution:
Figure 4: Containerized application on Kubernetes
Notice how most of these requirements are not really unique to our simplified example, but applicable to many other domains. Lower maintenance outages thanks to a fault-tolerant solution designed with failure in mind, or a more responsive, light-weight infrastructure are universal needs.
Here is also a video that we took to demonstrate the aforementioned features in action:
Ready to get started? Great, let’s take a look at the different avenues to get started today!
Option 1: Do-it-yourself deployment (on-premise)
Description
Perhaps the most challenging option to deploy (albeit giving you most control), is to just develop and deploy Kubernetes yourself on your own datacenter. This has the advantage that it reduces reliance on third parties and keeps proprietary data on your own infrastructure. For this, Windows supports Flannel CNI (in host-gateway mode) for route management, as well as Calico CNI for network policy enforcement. For maximum networking control, you can also just program static routes yourself and leverage the “wincni” container networking plugin.
Requires
Ready to give it a shot!? Download the latest Insider build and try it out:
Flannel, recommended for starting out! Wincni + manual route mangement Calico (beta) for network policy enforcement
In the future
Option 2: Deploy a Kubernetes cluster on Azure (acs-engine)
Description
Acs-engine is an open-source project from Azure that enables you to generate ARM (Azure Resource Manager) templates describing the size, shape, configuration, and version of your Kubernetes cluster. It can then use your template to generate and provision a cluster attached to a private Azure virtual network (Azure vNet) matching your desired description. This solution utilizes Azure CNI which was specifically developed for integration with the Azure vNet.
Requires
Ready to give it a shot!? Download the latest Insider build and: Try it out!
In the future
In addition to the options outlined above, we’ve partnered with RedHat to bring Windows Server containers to the RedHat OpenShift Container Platform (currently under private developer preview). This enterprise-grade container platform tailors particularly well to convenience-oriented IT Pros that want to forego complex deployment procedures (who doesn’t?!) while managing mixed-OS workloads through a familiar single pane of glass. Here are the most recent announcements from primary sources:
We covered motivations behind Kubernetes, what it is, as well as how-to deploy it. We also gave an overview of both the platform and open-source improvements since Windows Server 2016. Finally, we gave a brief teaser on what’s coming next in the Kubernetes world from a Windows standpoint.
Even though Kubernetes on Windows will GA soon, the road doesn’t end there. The Windows networking team is dedicated to continue working together with the open-source community to bring more Kubernetes networking goodness and CNI support to Windows. If you are curious about some of the technical platform work that enabled Kubernetes to run on Windows Server 2019 today, I’ll point you to these blog posts that already offer excellent insight:
Right now, much of the groundbreaking work is happening on upstream open-source bits, where anyone can contribute! If you want to stay up to date on any announcements, or want to make your voice heard, please join the dedicated Windows Kubernetes community at the #sig-windows meetups!
Thanks for reading!
David Schott
Continue reading...
This blog is part of a series for the Top 10 Networking Features in Windows Server 2019!
-- Click HERE to see the other blogs in this series. This concludes our
Top 10 List. We hope to see you at Ignite next week!
Look for the Try it out sections then give us some feedback in the comments!
In today’s increasingly competitive and fast-paced technology market, enterprises are constantly discovering amazing new ways to innovate and evolve. One such area with expanding interest in recent years is application modernization using containers and container orchestration. The numbers speak for themselves — a recent press release (06/18) by Allied Market Research concluded that:
The global application container market was valued at $698 million in 2016, and is projected to reach $8.2 billion by 2025.
As applications are lifted-and-shifted from VMs to containers, IT Pros and Dev Ops teams require the same network management agility of Software-Defined Datacenter (SDDC). Kubernetes, the de facto container orchestration tool, addresses this gap under the umbrella of a standardized & open-sourced framework.
In Kubernetes version 1.9 with Windows Server, version 1709 we first announced beta for Windows Server containers. Now, with Windows Server 2019, we greatly improved usability of Kubernetes on Windows by enhancing platform networking resiliency and support of container networking plugins.
Additionally, customers deploying workloads on Kubernetes demand network security to protect both Linux and Windows services using embedded tooling. The Windows Networking team has been working closely with Tigera, who is an industry-recognized leader in this space, and is pleased to announce upcoming availability of Tigera Calico for Windows. Both companies are working jointly with TAP customers to deploy Calico on Windows in POC environments, with current focus on network policy enforcement. Network management using dynamic routing (BGP) and IPAM is also on Tigera’s roadmap, with forthcoming Calico CNI support on Windows.
Kubernetes + Windows Server 2019
The Windows Networking team (together with the Kubernetes community) has done tremendous work on both the platform and open-source front to enable a smooth interoperability between Windows and other first-class citizens belonging to the Kubernetes project.
Windows Server 2019 supports all the Kubernetes networking building blocks (“primitives”), such that you’re able to deploy mixed-OS Kubernetes clusters in the environment of your choice. Whether you’re looking for maximum control in your own on-premises datacenter, or conveniently getting it all provisioned on Azure infrastructure – all the networking pieces are ready for composing your own cluster now.
Here is a timeline summarizing the groundbreaking achievements that enabled Windows to pursue its very own “Kubistential” awakening:
Figure 1: Kubernetes improvements since Windows Server 2016
The major headline from the graphic above, is that Kubernetes for Windows is projected to GA with Kubernetes 1.13, including official support on Windows Server 2019. Considering that Kubernetes is the most actively discussed GitHub project in the world today, this means you have a really compelling new force gravitating you towards Kubernetes on Windows: both open-source community and platform-level support from Microsoft enterprise.
Equally exciting to us, is that customers and users are also beginning to see these incremental improvements:
“My windows node successfully joined the cluster and I’m able to schedule a pod on it. Definitely a victory.”
– Nikhil Shampur, ESRI.
“To me, it’s great to see that Kubernetes on Windows is now working so smoothly!”
– Ulrich Rabenstein, SAP, Developer
Let’s make things more concrete through the lens of a (simplified) deployment example to demonstrate how Kubernetes features (all supported on Windows Server 2019) address the needs of an enterprise.
Deploying Kubernetes on Windows Server 2019: A reference example
Consider a Windows-based, .NET application consisting of an ordering service, location service, and identity service. Here are some basic, yet plausible example needs:
- I can safeguard confidential data by defining network security policies to control access to my workloads.
- I need a highly available system that is always accessible (zero downtime).
- My applications can scale with demand during high-traffic periods (Cyber Monday for example).
- My Windows services can communicate with my Linux services, and vice-versa.
Figure 2: Monolithic application
In theory, we could take this application and simply run it in a container, with each of these services communicating via shared networking and compute resources. However, in pursuit of technical benefits such as high cohesion and low coupling (see microservices architecture), work could also be done to refactor the application, and split it up into more manageable components.
Figure 3: Microservices application
In doing so, it quickly becomes apparent that the most effective way to redesign the architecture and standardize this distributed system, is through a container orchestrator. Why? Well, Kubernetes already provides native features that satisfy these requirements, it enhances portability in case of future changes, and there is no need to reinvent the wheel. Here’s the Kubernetes solution:
- I can safeguard confidential data by defining network security policies to control access to my workloads.
- Solution: Use the network policy feature that gives you a granular way to restrict traffic and isolate containers running your workloads.
- (See an example of this on Windows Server 2019 here).
- Solution: Use the network policy feature that gives you a granular way to restrict traffic and isolate containers running your workloads.
- I need a highly available system that is always accessible (zero downtime).
- Solution: Use the deployment feature for health monitoring + automatic replication of your containers in case of failure.
- (See an example of this on Windows Server 2019 here).
- Solution: Use the deployment feature for health monitoring + automatic replication of your containers in case of failure.
- My applications can scale with demand during high-traffic periods (Cyber Monday for example).
- Solution: Use the service feature together with deployments to define a set of load-balanced pods that can easily be scaled to handle incoming network traffic.
- (See an example of this on Windows Server 2019 here).
- *Tip*: Stay tuned for a more automated version of this solution called HPA (horizontal pod autoscaling), also coming soon with Windows GA.
- Solution: Use the service feature together with deployments to define a set of load-balanced pods that can easily be scaled to handle incoming network traffic.
- My Windows services can communicate with my Linux services, and vice-versa.
- Solution: See connecting application services about Kubernetes service discovery that allows services on any OS to communicate with each other via IP or name.
- (See an example of this on Windows Server 2019 here).
- Solution: See connecting application services about Kubernetes service discovery that allows services on any OS to communicate with each other via IP or name.
Figure 4: Containerized application on Kubernetes
Notice how most of these requirements are not really unique to our simplified example, but applicable to many other domains. Lower maintenance outages thanks to a fault-tolerant solution designed with failure in mind, or a more responsive, light-weight infrastructure are universal needs.
Here is also a video that we took to demonstrate the aforementioned features in action:
- 3:51 – Load Balancing across a set of pods
- 6:01 – Connecting Services across Windows + Linux
- 10:05 – Network policy enforcement on Windows
Ready to get started? Great, let’s take a look at the different avenues to get started today!
Option 1: Do-it-yourself deployment (on-premise)
Description
Perhaps the most challenging option to deploy (albeit giving you most control), is to just develop and deploy Kubernetes yourself on your own datacenter. This has the advantage that it reduces reliance on third parties and keeps proprietary data on your own infrastructure. For this, Windows supports Flannel CNI (in host-gateway mode) for route management, as well as Calico CNI for network policy enforcement. For maximum networking control, you can also just program static routes yourself and leverage the “wincni” container networking plugin.
Requires
- You have a computer or VM (requires virtualization and MAC spoofing) running Windows Server 2019.
- You have a computer or VM running a Linux OS which supports Kubernetes (needed for master node).
Ready to give it a shot!? Download the latest Insider build and try it out:
Flannel, recommended for starting out! Wincni + manual route mangement Calico (beta) for network policy enforcement
In the future
- Simplified & scalable network configuration thanks to network management and IPAM provided by Calico CNI!
- Overlay networking on Flannel!
- DNS support for multiple namespaces!
Option 2: Deploy a Kubernetes cluster on Azure (acs-engine)
Description
Acs-engine is an open-source project from Azure that enables you to generate ARM (Azure Resource Manager) templates describing the size, shape, configuration, and version of your Kubernetes cluster. It can then use your template to generate and provision a cluster attached to a private Azure virtual network (Azure vNet) matching your desired description. This solution utilizes Azure CNI which was specifically developed for integration with the Azure vNet.
Requires
- Azure subscription with service principal profile
- JSON configuration file with cluster description
- Azure CLI or Azure Powershell
- Acs-engine CLI
Ready to give it a shot!? Download the latest Insider build and: Try it out!
In the future
- AKS (Azure Kubernetes Service) with Windows Server containers!
In addition to the options outlined above, we’ve partnered with RedHat to bring Windows Server containers to the RedHat OpenShift Container Platform (currently under private developer preview). This enterprise-grade container platform tailors particularly well to convenience-oriented IT Pros that want to forego complex deployment procedures (who doesn’t?!) while managing mixed-OS workloads through a familiar single pane of glass. Here are the most recent announcements from primary sources:
- RedHat OpenShift and Microsoft Windows Containers
- RedHat and Microsoft co-develop the first Red Hat OpenShift jointly managed service on a public cloud
- OpenShift on Azure: The easiest, fully managed OpenShift in the cloud
We covered motivations behind Kubernetes, what it is, as well as how-to deploy it. We also gave an overview of both the platform and open-source improvements since Windows Server 2016. Finally, we gave a brief teaser on what’s coming next in the Kubernetes world from a Windows standpoint.
Even though Kubernetes on Windows will GA soon, the road doesn’t end there. The Windows networking team is dedicated to continue working together with the open-source community to bring more Kubernetes networking goodness and CNI support to Windows. If you are curious about some of the technical platform work that enabled Kubernetes to run on Windows Server 2019 today, I’ll point you to these blog posts that already offer excellent insight:
Right now, much of the groundbreaking work is happening on upstream open-source bits, where anyone can contribute! If you want to stay up to date on any announcements, or want to make your voice heard, please join the dedicated Windows Kubernetes community at the #sig-windows meetups!
Thanks for reading!
David Schott
Continue reading...