As we welcome Windows Server 2019 to the world, we bid farewell to Windows Server 2008. Support ends January 14, 2020.
How’s your migration plan shaping up? For many organizations, an end-of-support migration is pure drudgery. Yes, you should use a supported OS. But the move is a distraction that sucks resources away from the important stuff, like cloud-native or Kubernetes.
But it doesn’t have to be this way!
Migrate Windows 2008 Workloads to Kubernetes with Pivotal Container Service (PKS)
The GA of Enterprise PKS 1.5 means you can move your workloads to a supported Windows runtime, without code changes. Plus, you will enjoy the benefits of containers running in Kubernetes.
It’s all possible because PKS 1.5 includes Kubernetes 1.14.5, which adds support for Windows Server nodes. PKS 1.5 also builds on the proven support for managing Windows Server instances in the Pivotal platform. This all means your workloads that depend on the full .NET framework can now run on PKS. Windows support in PKS 1.5 will initially be a Beta feature as we gather customer feedback on this exciting new capability.
Migration Magic, Thanks to Multiple Versions of .NET
How does it work? When you move Windows apps to PKS, your .NET installation is done on a per-container basis, not per-VM. So you can have multiple versions of .NET running on the same Windows Server 2019 kernel, including .NET 3.5.
Version 3.5, of course, is the most popular flavor for Windows Server 2008 apps. Since you’re using v3.5, your migration is dramatically simpler. In most cases you won’t need to make any code changes to migrate the application.
So if the original developers of an app no longer work at your firm – or even if you don’t have the source code – you can still reap the benefits of Kubernetes and run on a supported environment!
Tutorial: Hands-On with Windows Apps on Kubernetes
So what’s the operator experience? Well, PKS is a lot like a Kubernetes cluster vending machine, with a number of standard clusters available to vend, known as “Plans,” for both Linux and Windows. Let’s use Windows as our example.
First, the operator creates and configures one or more Windows plans:
Now that they’ve created a Windows Server plan, the operator then needs to provide a Windows Server 2019 Stemcell image. (PKS will use this to provision worker node VMs.) The Stemcell is a powerful concept in PKS, enabling worker nodes to be provisioned and updated automatically. In other Kubernetes platforms and clouds, you’d need to provision and manage the lifecycle of a Windows Server VM yourself.
Next, the cluster manager creates (“vends”) a new Windows Server cluster using the plan created by the operator. It looks like this in the PKS command-line interface:
$ pks create-cluster my-windows-beta -p Plan-11-Windows-Beta --external-hostname mywindows-beta.pks.hinterlands.cfapp.com
The operator can view the status of the cluster and worker nodes using PKS and Kubectl commands respectively:
$ pks clusters Name Plan Name Status Action My-windows-beta Plan-11-Windows-Beta succeeded CREATE $ kubectl get nodes NAME VERSION OS-IMAGE KERNEL-VERSION 37… v1.14.1 Windows Server 2019 Datacenter 10.0.17763.557 40… v1.14.1 Windows Server 2019 Datacenter 10.0.17763.557 54… v1.14.1 Windows Server 2019 Datacenter 10.0.17763.557 Ec… v1.14.1 Ubuntu 16.04.6 LTS 4.15.0.54-generic
The Developer Experience
For .NET developers, the experience is pure Kubernetes. In fact, you won’t need to worry about source code at all. You just need to build the (docker) container that gets deployed in the pod.
Think of the container as your infrastructure. You start with a base layer operating system, on which you install (via powershell) features like .NET Framework, IIS, certificates, user accounts, etc. Then you include the published application and create the container image. Push that image to your registry of choice (we prefer Harbor) and use kubectl to deploy the pod.
FROM mcr.microsoft.com/dotnet/framework/aspnet:3.5 # Clean out default site RUN powershell -NoProfile -Command Remove-Item -Recurse C:inetpubwwwroot* WORKDIR /inetpub/wwwroot #Copy the app artifact in (assumes you are in the publish folder when building docker image) COPY wwwroot/* .
All your containers will run on the same, standard Windows Server 2019 kernel. Inside each container is a customized environment, specific to the app running in the container. So, now you can run different versions of the .NET side by side. Imagine the possibilities when the challenges of infrastructure are removed, and the app’s environment is totally scripted. Windows clusters in Kubernetes offers a world of new options!
Microsoft has made things simple by providing a collection of premade container images you can use as a start-point for building your app’s container. Their docker hub includes IIS, ASP.NET, 3.x & 4.x runtimes, as well as other images. Visit the Kubernetes area of our .NET cookbook to find common legacy .NET recipes as well as “getting started” ideas.
Additional Features new in PKS 1.5
We’ve focused on migrating Windows workloads in this blog, but PKS 1.5 will also come with a rich set of enhancements for running Kubernetes in production, including individual cluster upgrades, Harbor 1.8, and an expanded management console. Check out VMware’s blog for more details of all these features, and stay tuned for the PKS 1.5 GA bits later this month.
Learn more
SAFE HARBOR STATEMENT
This blog contains statements relating to Pivotal’s expectations, projections, beliefs and prospects which are "forward-looking statements” within the meaning of the federal securities laws and by their nature are uncertain. These include statements about upcoming releases of Enterprise PKS. Words such as "believe," "may," "will," "estimate," "continue," "anticipate," "intend," "expect," "plans," and similar expressions are also intended to identify forward-looking statements. Such forward-looking statements are not guarantees of future performance, and you are cautioned not to place undue reliance on these forward-looking statements. Actual results could differ materially from those projected in the forward-looking statements as a result of many factors, including but not limited to: (i) our limited operating history as an independent company, which makes it difficult to evaluate our prospects; (ii) the substantial losses we have incurred and the risks of not being able to generate sufficient revenue to achieve and sustain profitability; (iii) our future success depending in large part on the growth of our target markets; (iv) our future growth depending largely on Pivotal Cloud Foundry and our platform-related services; (v) our subscription revenue growth rate not being indicative of our future performance or ability to grow; (vi) our business and prospects being harmed if our customers do not renew their subscriptions or expand their use of our platform; (vii) any failure by us to compete effectively; (viii) our long and unpredictable sales cycles that vary seasonally and which can cause significant variation in the number and size of transactions that can close in a particular quarter; (ix) our lack of control of and inability to predict the future course of open-source technologies, including those used in Pivotal Cloud Foundry; and (x) any security or privacy breaches. All information set forth in this release is current as of the date of this release. These forward-looking statements are based on current expectations and are subject to uncertainties, risks, assumptions, and changes in condition, significance, value and effect as well as other risks disclosed previously and from time to time in documents filed by us with the U.S. Securities and Exchange Commission (SEC), including our Annual Report on Form 10-K. Additional information will be made available in our quarterly report on Form 10-Q and other future reports that we may file with the SEC, which could cause actual results to vary from expectations. We disclaim any obligation to, and do not currently intend to, update any such forward-looking statements, whether written or oral, that may be made from time to time except as required by law.
This blog also contains statements which are intended to outline the general direction of certain of Pivotal's offerings. It is intended for information purposes only and may not be incorporated into any contract. Any information regarding the pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. All software releases are on an if and when available basis and are subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal's offerings. Any purchasing decisions should only be based on features currently available. The development, release, and timing of any features or functionality described for Pivotal's offerings in this blog remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward-looking information in this blog.
