Kategorie: Kubernetes

Introducing Docker for Windows Server 2016

Today, Microsoft is announcing general availability of Windows Server 2016 at the Ignite conference in Atlanta. For Windows developers and IT-pros, the most exciting new Windows feature is containers, and containers on Windows Server 2016 are powered by Docker.
The first version of Docker was released in 2013, and in the 3 years since launch, Docker has completely transformed how Linux developers and ops build, ship and run apps. With Docker Engine and containers now available natively on Windows, developers and IT-pros can begin the same transformation for Windows-based apps and infrastructure and start reaping the same benefits: better security, more agility, and improved portability and freedom to move on-prem apps to the cloud.
For developers and IT-pros that build and maintain heterogenous deployments with both Linux and Windows infrastructure, Docker on Windows holds even greater significance: The Docker platform now represents a single set of tools, APIs and image formats for managing both Linux and Windows apps. As Linux and Windows apps and servers are dockerized, developers and IT-pros can bridge the operating system divide with shared Docker terminology and interfaces for managing and evolving complex microservices deployments both on-prem and in the cloud.

Running Containers on Windows Server
Docker running containers on Windows is the result of a two-year collaboration between Microsoft that involved the Windows kernel growing containerization primitives, Docker and Microsoft collaborating on porting the Docker Engine and CLI to Windows to take advantage of those new primitives and Docker adding multi-arch image support to Docker Hub.
The result is that the awesome power of docker run to quickly start a fresh and fully isolated container is now available natively on Windows:
PC C:> docker run -ti microsoft/windowsservercore powershell
Windows PowerShell

Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:>
The kernel containerization features are available in all versions of Windows Server 2016, and are also on Windows 10 systems with the Anniversary Update, and the Windows-native Docker daemon runs on both Windows Server 2016 and Windows 10 (although only containers based on Windows Server build and run on Windows 10).
docker run on Windows comes with the same semantics as on Linux: Full process isolation and sandboxed filesystem (and Windows Registry!) with support for layering changes. Each container sees a clean Windows system and cannot interfere with other processes (containerized or not) on the system.
For example, two dockerized apps using different Internet Information Services (IIS) versions and different .NET frameworks can co-exist merrily on the same system. They can even write to their respective filesystems and registries without affecting each other.
With containerization, Windows IT-pros get most of the isolation and release-artifact-stability benefits of VMs, without the resource overhead and lost agility inherent in hardware virtualization.
Similar to how containers on Linux can run with different security profiles, containers on Windows run in one of two isolation modes:

Windows Server Containers use the same shared-kernel process-isolation paradigm known from Linux. Since containers run as normal (but isolated) processes, startup is fast and resource overhead is minimal.
With Hyper-V isolation, container processes run inside a very minimal hypervisor created during container start. This yields potentially better isolation at the cost of slower startup and some resource overhead.

Isolation can be set with a simple switch passed to docker run:
docker run –isolation=hyperv microsoft/nanoserver
As long as the underlying host supports the requested isolation mode, any Windows container image can be run as either a hyper-v or server container and a container host can run both side by side. Container processes are oblivious to the isolation mode they run in, and the Docker control API is the same for both modes.
This makes isolation mode not generally a developer concern and developers should use the default or what’s convenient on their system. Isolation mode does give IT-pros options when choosing how to deploy containerized apps in production.
Also note that, while Hyper-V is the runtime technology powering hyper-v isolation, hyper-v isolated containers are not Hyper-V VMs and cannot be managed with classic Hyper-V tools.
For readers interested in details of how containers are implemented on Windows, John Starks’ black belt session at DockerCon ‘16 is a great introduction.

Building Windows Container Images
Thanks to layering improvements to the Windows Registry and filesystem, docker build and Dockerfiles are fully supported for creating Windows Docker images. Below is an example Windows Dockerfile that Stefan Scherer has proposed for the Node.js official Docker library image. It can be built on Windows with docker build:
FROM microsoft/windowsservercore
ENV NPM_CONFIG_LOGLEVEL info
ENV NODE_VERSION 4.5.0
ENV NODE_SHA256 16aab15b29e79746d1bae708f6a5dbed8ef3c87426a9408f7261163d0cda0f56
RUN powershell -Command
$ErrorActionPreference = ‘Stop’ ;
(New-Object System.Net.WebClient).DownloadFile(‘https://nodejs.org/dist/v%NODE_VERSION%/node-v%NODE_VERSION%-win-x64.zip’, ‘node.zip’) ;
if ((Get-FileHash node.zip -Algorithm sha256).Hash -ne $env:NODE_SHA256) {exit 1} ;
Expand-Archive node.zip -DestinationPath C: ;
Rename-Item ‘C:node-v%NODE_VERSION%-win-x64′ ‘C:nodejs’ ;
New-Item ‘%APPDATA%npm’ ;
$env:PATH = ‘C:nodejs;%APPDATA%npm;’ + $env:PATH ;
[Environment]::SetEnvironmentVariable(‘PATH’, $env:PATH, [EnvironmentVariableTarget]::Machine) ;
Remove-Item -Path node.zip
CMD [ “node.exe” ]
Note how PowerShell is used to install and setup zip files and exes: Windows containers run Windows executables compiled for Windows APIs. To build and run a Windows container, a Windows system is required. While the Docker tools, control APIs and image formats are the same on Windows and Linux, a Docker Windows container won’t run on a Linux system and vice-versa.
Also note that the starting layer is microsoft/windowsservercore. Starting FROM scratch is not an option when creating Windows container images. Instead, images are based on either microsoft/windowsservercore or microsoft/nanoserver.
The Windows Server Core image comes with a mostly complete userland with the processes and DLLs found on a standard Windows Server Core install. With the exception of GUI apps and apps requiring Windows Remote Desktop, most apps that run on Windows Server can be dockerized to run in an image based on microsoft/windowsservercore with minimal effort. Examples include Microsoft SQL Server, Apache, Internet Information Services (IIS) and the full .NET framework.
This flexibility comes at the cost of some bulk: The microsoft/windowsservercore image takes up 10GB. Thanks to Docker’s highly efficient image layering, this is not a big problem in practice. Any given Docker host only needs to pull the base layer once, and any images pulled or built on that system simply reuse the base layer.
The other base layer option is Nano Server, a new and very minimal Windows version with a pared-down Windows API. Lots of software already runs on Nano Server, including IIS, the new .NET Core framework, Node.js and Go. And the Nano Server base image is an order of magnitude smaller than Windows Server Core, meaning it has less dependencies and surface area to keep updated. Nano Server is an exciting development, not only as a base for minimal containers that build and boot quickly, but also as a Minimalist Operating System that makes for a great container host OS running just the Docker daemon and containers, and nothing else.
With the choice of Windows Server Core and Nano Server, developers and IT-pros can opt to lift-and-shift existing Windows-based apps into Server Core containers or adopt Nano Server for greenfield development or incrementally as part of breaking monolithic apps into microservices components.
Docker is working with Microsoft and the community to build container images based on both Windows Server Core and Nano Server. Golang, Python and Mongo are available as official Docker images (more are on their way), and Microsoft also maintains a set of very popular sample images.
Summary
Today’s announcement of Docker Engine building, running and managing containers on Windows is the fruit of years of labor by teams at both Microsoft and Docker and by the Docker community. We’re incredibly proud of the work we’ve done with Microsoft to bring the benefits of containerization to Windows developers and IT-pros, and we’re excited about the prospect of getting Windows and Linux technologists building, shipping and running apps together with a common set of tools and APIs.
Here are some resources to help you get started

Sign up to be notified of GA and the Docker Datacenter for Windows Beta
Register for a webinar: Docker for Windows Server
Learn more about the Docker and Microsoft partnership

The post Introducing Docker for Windows Server 2016 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Announces Commercial Partnership with Microsoft to Double Container Market by Extending Docker Engine to Windows Server

With industry analysts declaring Windows Server with more than 60% of the x86 server market, and citing Microsoft Azure as the fastest-growing public cloud, it comes as no surprise that Microsoft, even at its current scale, is further extending its leadership as a strategic, trusted partner to enterprise IT.
It is this industry leadership that catalyzed our technical collaboration in the Docker open source project back in October 2014, to jointly bring the agility, portability, and security benefits of the Docker platform to Windows Server.  After two years of joint engineering, we are excited to unveil a new, commercial partnership to extend these benefits for both Windows developers targeting Windows Server and enterprise IT professionals.
Specifically, the commercial partnership entails:

The Commercially Supported Docker Engine aka “CS Docker Engine”, Docker, Inc.’s tested, validated, and supported package of Docker Engine, will be available to Windows Server 2016 customers at no additional cost
Microsoft will provide Windows Server 2016 customers enterprise support for CS Docker Engine, backed by Docker, Inc
Docker and Microsoft will jointly promote Docker Datacenter to enable IT Pros to secure the Windows Server software supply chain and manage containerized Windows Server workloads, whether on-prem, in the cloud, or hybrid.

These fruits of this partnership for the first time offer enterprise IT professionals with a single platform for both Windows and Linux applications on any infrastructure, whether bare metal, virtualized, or cloud.
 

CS Docker Engine and Docker Datacenter for Windows Server represent a major addition that complements several other joint initiatives as depicted above.
 

For developers, the integration of Visual Studio Tools for Docker and Docker for Windows provides complete desktop development environments for building Dockerized Windows apps;
To jumpstart app development, Microsoft has contributed Windows Server container base images and apps to Docker Hub;
For IT pros, Docker Datacenter will be designed to manage Windows Server environments in addition to the Linux environments Datacenter already manages.

Availability
Windows Server 2016 will be generally available in October, when Windows Server 2016 customers will be able to download the first version of the CS Docker Engine. Docker Datacenter for managing Windows Server containerized workloads will be available shortly thereafter.  While the announcements today represent another significant milestone in our partnership, Docker and Microsoft are just getting started.
Check out the below to learn more!

Learn more about Docker on Windows Server
Sign up to be notified of GA and the Docker Datacenter for Windows Beta
Register for a webinar: Docker for Windows Server
Learn more about the Docker and Microsoft partnership

The post Docker Announces Commercial Partnership with Microsoft to Double Container Market by Extending Docker Engine to Windows Server appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Walk, Jog, Run: Getting Smarter About Docker

I’ve spent most of the summer traveling to and speaking at a lot of different trade shows: EMC World, Cisco Live!, VMworld, HP Discover, Dockercon, and LinuxCon (as well as some meetups and smaller gatherings). A lot of the time, I’m speaking to people who are just getting familiar with Docker. They may have read an article or have had someone walk into their office and say “This Docker thing, so hot right now. Go figure it out”.
Certainly there are a number of companies running Docker in production, but there are still many who are asking fundamental questions about what Docker is, and how it can benefit their organization. To help folks out in that regard, I wrote an eBook.
After someone gets a grasp on what Docker is, they tend to want to dive in and start exploring, but often times they aren’t sure how to get started.
My advice (based on the approach I took when I joined Docker last year) is to walk, jog, and then run:
Walk: Decide where you want to run Docker, and install it. This could be Docker for Mac, Docker for Windows, or just installing Docker on Linux. Pick whatever makes the most sense for your environment and load it up.
From there run your first Docker app: hello-world
$ docker run hello-world
After you know you have Docker running, work your way through one of our labs. I’d suggest starting with this beginner lab we have on GitHub.
Jog: You’ve got Docker installed, and you have played with the command line a bit. You’ve probably run a few containers as well. The next step is to try and replicate a commonly deployed application in Docker.
When I started working with Docker the first application I tried to deploy was WordPress. It is a good example because it has a few moving parts (the web front end and a database backend), and there are about a thousand blogs on how to do it. Read a bunch of blogs, and then give it a go.
After WordPress I decided to build a very simple CI pipeline using Jenkins. CI is a great use case for Docker. Docker vastly simplifies your build environments, and, because containers deploy so quickly, customers can see some real time savings as well.
Run: So you’ve been able to stand up someone else’s application, now it’s time to take the next step. Deploy one of your own. Take an existing application, and move it into a container.
This will allow to build your own Dockerfile from scratch, and maybe even a Docker Compose file as well. Try and choose an app with on a few moving parts, and be mindful of things like static configs and port mappings which can add additional complexity.
So download the eBook  and get started walking. If you get stuck, ask for help from the community, or attend a meetup. There are a growing number of Docker experts out there who are always more than willing to lend a hand.

Practical advice to walk, jog, run your way to @Docker expertiseClick To Tweet

 
Here are some helpful links:

Download Docker onto your favorite environment
Check out all the hands on tutorials for Docker and product documentation
Learn more about our latest Docker 1.12 release
Join our community, or attend a meetup or ask a Docker expert for help

The post Walk, Jog, Run: Getting Smarter About Docker appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

High performance network policies in Kubernetes clusters

Editor’s note: today’s post is by Juergen Brendel, Pritesh Kothari and Chris Marino co-founders of Pani Networks, the sponsor of the Romana project, the network policy software used for these benchmark tests.Network PoliciesSince the release of Kubernetes 1.3 back in July, users have been able to define and enforce network policies in their clusters. These policies are firewall rules that specify permissible types of traffic to, from and between pods. If requested, Kubernetes blocks all traffic that is not explicitly allowed. Policies are applied to groups of pods identified by common labels. Labels can then be used to mimic traditional segmented networks often used to isolate layers in a multi-tier application: You might identify your front-end and back-end pods by a specific “segment” label, for example. Policies control traffic between those segments and even traffic to or from external sources.Segmenting trafficWhat does this mean for the application developer? At last, Kubernetes has gained the necessary capabilities to provide “defence in depth”. Traffic can be segmented and different parts of your application can be secured independently. For example, you can very easily protect each of your services via specific network policies: All the pods identified by a Replication Controller behind a service are already identified by a specific label. Therefore, you can use this same label to apply a policy to those pods.Defense in depth has long been recommended as best practice. This kind of isolation between different parts or layers of an application is easily achieved on AWS and OpenStack by applying security groups to VMs. However, prior to network policies, this kind of isolation for containers was not possible. VXLAN overlays can provide simple network isolation, but application developers need more fine grained control over the traffic accessing pods. As you can see in this simple example, Kubernetes network policies can manage traffic based on source and origin, protocol and port.apiVersion: extensions/v1beta1kind: NetworkPolicymetadata: name: pol1spec: podSelector:   matchLabels:     role: backend ingress: – from:   – podSelector:      matchLabels:       role: frontend   ports:   – protocol: tcp     port: 80Not all network backends support policiesNetwork policies are an exciting feature, which the Kubernetes community has worked on for a long time. However, it requires a networking backend that is capable of applying the policies. By themselves, simple routed networks or the commonly used flannel network driver, for example, cannot apply network policy.There are only a few policy-capable networking backends available for Kubernetes today: Romana, Calico, and Canal; with Weave indicating support in the near future. Red Hat’s OpenShift includes network policy features as well.We chose Romana as the back-end for these tests because it configures pods to use natively routable IP addresses in a full L3 configuration. Network policies, therefore, can be applied directly by the host in the Linux kernel using iptables rules. This results is a high performance, easy to manage network. Testing performance impact of network policiesAfter network policies have been applied, network packets need to be checked against those policies to verify that this type of traffic is permissible. But what is the performance penalty for applying a network policy to every packet? Can we use all the great policy features without impacting application performance? We decided to find out by running some tests.Before we dive deeper into these tests, it is worth mentioning that ‘performance’ is a tricky thing to measure, network performance especially so. Throughput (i.e. data transfer speed measured in Gpbs) and latency (time to complete a request) are common measures of network performance. The performance impact of running an overlay network on throughput and latency has been examined previously here and here. What we learned from these tests is that Kubernetes networks are generally pretty fast, and servers have no trouble saturating a 1G link, with or without an overlay. It’s only when you have 10G networks that you need to start thinking about the overhead of encapsulation. This is because during a typical network performance benchmark, there’s no application logic for the host CPU to perform, leaving it available for whatever network processing is required. For this reason we ran our tests in an operating range that did not saturate the link, or the CPU. This has the effect of isolating the impact of processing network policy rules on the host. For these tests we decided to measure latency as measured by the average time required to complete an HTTP request across a range of response sizes. Test setupHardware: Two servers with Intel Core i5-5250U CPUs (2 core, 2 threads per core) running at 1.60GHz, 16GB RAM and 512GB SSD. NIC: Intel Ethernet Connection I218-V (rev 03)Ubuntu 14.04.5Kubernetes 1.3 for data collection (verified samples on v1.4.0-beta.5)Romana v0.9.3.1Client and server load test softwareFor the tests we had a client pod send 2,000 HTTP requests to a server pod. HTTP requests were sent by the client pod at a rate that ensured that neither the server nor network ever saturated. We also made sure each request started a new TCP session by disabling persistent connections (i.e. HTTP keep-alive). We ran each test with different response sizes and measured the average request duration time (how long does it take to complete a request of that size). Finally, we repeated each set of measurements with different policy configurations. Romana detects Kubernetes network policies when they’re created, translates them to Romana’s own policy format, and then applies them on all hosts. Currently, Kubernetes network policies only apply to ingress traffic. This means that outgoing traffic is not affected.First, we conducted the test without any policies to establish a baseline. We then ran the test again, increasing numbers of policies for the test’s network segment. The policies were of the common “allow traffic for a given protocol and port” format. To ensure packets had to traverse all the policies, we created a number of policies that did not match the packet, and finally a policy that would result in acceptance of the packet.The table below shows the results, measured in milliseconds for different request sizes and numbers of policies:Response SizePolicies.5k1k10k100k1M00.7320.7381.0772.53210.487100.7440.7421.0842.57010.556500.7450.7551.0862.58010.5661000.7620.7701.1042.64010.5972000.7830.7831.1472.65210.677What we see here is that, as the number of policies increases, processing network policies introduces a very small delay, never more than 0.2ms, even after applying 200 policies. For all practical purposes, no meaningful delay is introduced when network policy is applied. Also worth noting is that doubling the response size from 0.5k to 1.0k had virtually no effect. This is because for very small responses, the fixed overhead of creating a new connection dominates the overall response time (i.e. the same number of packets are transferred).Note: .5k and 1k lines overlap at ~.8ms in the chart aboveEven as a percentage of baseline performance, the impact is still very small. The table below shows that for the smallest response sizes, the worst case delay remains at 7%, or less, up to 200 policies. For the larger response sizes the delay drops to about 1%. Response SizePolicies.5k1k10k100k1M00.0%0.0%0.0%0.0%0.0%10-1.6%-0.5%-0.6%-1.5%-0.7%50-1.8%-2.3%-0.8%-1.9%-0.8%100-4.1%-4.3%-2.5%-4.3%-1.0%200-7.0%-6.1%-6.5%-4.7%-1.8%What is also interesting in these results is that as the number of policies increases, we notice that larger requests experience a smaller relative (i.e. percentage) performance degradation.This is because when Romana installs iptables rules, it ensures that packets belonging to established connection are evaluated first. The full list of policies only needs to be traversed for the first packets of a connection. After that, the connection is considered ‘established’ and the connection’s state is stored in a fast lookup table. For larger requests, therefore, most packets of the connection are processed with a quick lookup in the ‘established’ table, rather than a full traversal of all rules. This iptables optimization results in performance that is largely independent of the number of network policies. Such ‘flow tables’ are common optimizations in network equipment and it seems that iptables uses the same technique quite effectively. Its also worth noting that in practise, a reasonably complex application may configure a few dozen rules per segment. It is also true that common network optimization techniques like Websockets and persistent connections will improve the performance of network policies even further (especially for small request sizes), since connections are held open longer and therefore can benefit from the established connection optimization.These tests were performed using Romana as the backend policy provider and other network policy implementations may yield different results. However, what these tests show is that for almost every application deployment scenario, network policies can be applied using Romana as a network back end without any negative impact on performance.If you wish to try it for yourself, we invite you to check out Romana. In our GitHub repo you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster.
Quelle: kubernetes