Diversity is in the air, even in the cloud. While Kubernetes was once solely the domain of Linux fans, Windows devotees can at long last fully leverage the power of container orchestration and realize the significant operational and cost savings it delivers.
Windows containers aren’t quite full Kubernetes citizens yet — for example, control pane nodes must run Linux — but they’re solid permanent residents. And major cloud providers such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) have added support for them to their managed Kubernetes services. There’s still a missing piece for many Windows developers and DevOps engineers, however — end-to-end visibility into every component of their applications.
A need for container-native monitoring
Over the past several years, businesses have begun containerizing their applications to realize benefits such as portability, efficiency and elasticity. But in order to manage their Windows workloads using Kubernetes, they had to rewrite their full Microsoft .NET Framework applications in .NET Core and then deploy them as Linux containers. In general, this process of refactoring, testing and replatforming is expensive and time-consuming. It also increases the risk of introducing bugs into the system.
Since the release of version 1.14, however, Kubernetes provides production-level support for Windows containers. Windows and Linux nodes work alongside each other seamlessly in mixed clusters, and DevOps teams can manage them from a common interface.
While this was a very welcome step forward and Windows containers rapidly gained traction in production Kubernetes clusters, two critical pain points remain:
- There’s no application monitoring on Kubernetes Windows containers. Reliance on logs alone is reactive, which is simply not sufficient.
- No traditional application performance monitoring (APM) tool supports native instrumentation of full .NET Framework application containers running on Kubernetes.
Read on to discover how you can solve these problems using AppDynamics.
Overcoming the observability challenges
DevOps teams and business owners need performance visibility into containerized Windows applications in Kubernetes environments. The AppDynamics cloud-native monitoring solution provides this capability using a lightweight .NET Micro Agent and ensures that the developers’ build process is agnostic of the instrumentation process, thus maintaining immutability and idempotency.
Performance problems don’t always originate in application code, however, and technology teams must often look further when investigating the root cause of slowdowns and outages. Data gathered from application logs, the network and the underlying infrastructure can be extremely helpful during this process. The design of our Windows container monitoring solution took all of this into consideration and provides proactive monitoring across the application and all layers of the platform stack, focusing on four main areas:
- Application health. Deep visibility into business transactions and the overall health of containerized full .NET Framework applications allows technology teams to quickly resolve issues and create better customer experiences.
- Kubernetes cluster health. Insight into a cluster’s health, the pods it contains and the Windows containers that run within them helps engineers manage workloads efficiently and allocate resources and capacity effectively.
- Infrastructure monitoring. Performance metrics from Windows worker nodes are directly correlated to a container’s health. DevOps teams can use this data to optimize resource allocations and troubleshoot resource constraints that may lead to pod evictions, errors and restarts.
- Log analytics. Log analytics link business transaction performance data to the log files, making root cause analysis less time and resource intensive.
Eliminating integration headaches
Deep application and business performance insights are valuable, but so are the time and effort involved in gaining access to them. Turning this visibility on should be as straightforward, repeatable and idempotent as any other DevOps process. AppDynamics simplifies the deployment, configuration and instrumentation of Cluster Agents and seamlessly unlocks a view across your application environment.
Visibility into application health
AppDynamics allows DevOps teams to monitor Microsoft Internet Information Services (IIS) ASP. NET and stand-alone (.exe) Windows applications using the init container Kubernetes pattern as shown in the following code example. In this context, init containers act as a delivery mechanism and copy the .NET Micro Agent files into the application container at deploy time rather than build time. This approach provides distinct advantages over explicitly copying the agent files and dependencies into the image and simplifies the build process because:
- You do not need to update each application’s Dockerfile to copy the agent files.
- The application image does not need to be rebuilt, which simplifies agent upgrades.
- The application image is lean. (Size is a key consideration with Windows images.)
Learn how to monitor ASP.NET and console applications in Kubernetes using init containers.
View a GitHub repository with example HashiCorp Configuration Language (HCL) files that illustrate how to instrument containerized Windows applications in Kubernetes.
Visibility into worker node health
With AppDynamics, separate agents monitor Linux and Windows nodes. Each agent is typically deployed in a Kubernetes cluster as a DaemonSet with one instance per host, providing visibility into the health of all cluster nodes in a single step.
The AppDynamics Operator works with our custom resource InfraViz to launch DaemonSets. A new property — nodeOS — can be set that tells the operator which DaemonSet to create. When it’s set to “all” as in the code example below, it will launch two DaemonSets simultaneously, deploying one to the Linux nodes and the other to the Windows nodes. (The fact that two DaemonSets exist remains transparent to users.)
View the full spec.
Initially it was intended that the AppDynamics Operator would automatically track whether a cluster contains Windows nodes. This is relatively easy to do — it would simply have to watch for cluster nodes. The reconciliation loop could then use this information to create, update or remove DaemonSets accordingly. However, since a cluster role is required to access a cluster node and we are trying to keep the operator’s scope limited to a single namespace, we deferred this enhancement. Despite this limitation, it is safe to deploy the InfraViz resource with the nodeOS property set to “all.” The Windows DaemonSet won’t have any pods until at least one Windows node joins the cluster.
There may be times when monitoring requirements (and configuration settings) differ between the two operating systems. In these cases, AppDynamics users have the flexibility to manage Linux and Windows server monitoring separately. They can launch two different InfraViz instances as in the following code example, one with the nodeOS property set to “linux” and the other set to “windows.” The end result will be the same — two DaemonSets will exist for each set of cluster nodes, but the respective agents will be managed completely independently of each other.
View the full spec.
Learn more about managing visibility in mixed operating system clusters.
Bigger isn’t better for images
Windows container base images tend to be on the larger side, which can be an issue. Luckily there are multiple solutions to choose from.
Windows Server Core and Nano Server are the most common base images, but the latter has a significantly smaller on-disk footprint. One of the downsides of targeting this type of image, though, is that DevOps teams will likely need to install additional packages in order for their applications to run. In addition, it only supports .NET Core (not .NET Framework) and you cannot run Microsoft Active Directory (AD), Microsoft System Center Configuration Manager (SCCM) or 32-bit applications.
If you make extensive use of Microsoft PowerShell, however, you’ve got another alternative — powershell:Its-nanoserver — which is the smallest available base image. AppDynamics uses this image to collect log analytics.
Contrary to popular belief in the Windows container community, it’s possible to have a mixture of different Windows base images in a pod. The application itself may target a Windows Server Core image, while any sidecar containers can be built off a Nano Server variant. However, there’s a general constraint that applies across the board — when running Windows containers, the major release of the host operating system must be equal to or newer than the base image operating system of the application container.
Making use of a sidecar
One way to set up log monitoring with our solution is to point the Analytics Agent to the application log file. The easiest and least invasive way to do this in Kubernetes is to deploy the agent in a sidecar container as illustrated in the code example below. In this scenario, the application is configured to log to a local file, and the logging directory in the application container is mounted to a shared volume of the pod (i.e., an emptyDir volume). The sidecar — which is also mounted to the emptyDir volume — then has access to all the files in the logging directory. As the application produces logs, the Analytics Agent picks them up in real time and sends them to the AppDynamics Events Service where they are analyzed and correlated with the rest of the monitoring data. This approach keeps the overhead of the sidecar to a minimum and allows it to scale easily along with the application.
View the full manifest.
Learn more
If your business is deploying Windows containers on Kubernetes, you need end-to-end visibility into every component of your applications and environment. Download our e-book to gain additional insight into where traditional monitoring approaches fall short and learn why you should — and how you can — rethink your strategy.
This blog may contain product roadmap information of AppDynamics LLC (“AppDynamics”). AppDynamics reserves the right to change any product roadmap information at any time, for any reason, and without notice. This information is intended to outline AppDynamics’ general product direction, it is not a guarantee of future product features, and it should not be relied on in making a purchasing decision. The development, release, and timing of any features or functionality described for AppDynamics’ products remain at AppDynamics’ sole discretion. AppDynamics reserves the right to change any planned features at any time before making them generally available as well as never making them generally available.