-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting Started Guide for Windows Support #1771
Conversation
Have you tried rendering this? I mostly wonder if it will get added to the site navigation automatically, or you need to do something special? Also, I have very little idea about anything Windows-specific, so I think it needs a different assignee... |
ping @jaredbhatti |
@errordeveloper I am not sure if it will get added to the site navigation automatically. @jaredbhatti might be able to help here |
@@ -0,0 +1,163 @@ | |||
# Running Windows Server Containers using Kubernetes | |||
Microsoft, in collaboration with Docker, is introducing a new feature called Windows Server Containers with Windows Server 2016, which enables Docker containers to run on Windows. We have enhanced Kubernetes to support Windows Server Containers (and Windows Server 2016 as a container host node). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kubernetes documentation typically does not highlight the work of a specific company, group or individual. (A blog post is a great place for giving credit.)
With that in mind, I'd suggest rewording the first two sentences to something like:
"Kubernetes supports nodes running Microsoft Windows Server 2016. Docker version x.xx is required . Pods are comprised of Windows Server Containers."
You can definitely link from various terms (e.g. Windows Server Containers) to product pages on the Microsoft and Docker websites.
I'd also suggest replacing "we" everywhere in this doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated as requested
|
||
Windows Server and .NET still account for a significant portion of the workloads in the enterprise, and with this work, customers will be able to run Windows-based and .NET-based applications inside containers on Kubernetes, making Kubernetes the first fully functional cross-platform cluster manager. Services that span Windows-based and Linux-based containers are now a reality. | ||
|
||
Windows Server Containers will be supported on Kubernetes as an alpha feature. Kubernetes control plane (API Server, Scheduler, Controller Manager etc) continue to run on Linux, while the kubelet and kube-proxy can be run on Windows Server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this expected to work with Kubernetes 1.5.0? If so, then say "are" rather than "will be". If not supported in 1.5.0, then we should consider whether this belongs in the 1.5.0 docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated as requested
The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the “public” NIC. | ||
|
||
### Windows | ||
To support networking requirements, we will need the following configuration on each Kubernetes Windows Server node: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace "To support networking requirements, we will need the following configuration on each Kubernetes Windows Server node" with "Each Window Server node should have the following configuration".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated as requested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this detailed documentation! A couple of comments.
Thanks for the review @erictune . I have updated the documentation as requested |
@erictune Can you please review the changes and let me know if your concerns are addressed |
@@ -0,0 +1,159 @@ | |||
# Running Windows Server Containers using Kubernetes | |||
Windows Server Containers are supported on Kubernetes as an alpha feature. Kubernetes control plane (API Server, Scheduler, Controller Manager etc) will continue to run on Linux, while the kubelet and kube-proxy can be run on Windows Server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reference a specific version; it helps the documentation from being rendered obsolete.
"Kubernetes version 1.5 introduces support for Windows Server Containers. In version 1.5, the Kubernetes control plane (API Server, Scheduler, Controller Manager, etc) continue to run on Linux, while the kubelet and kube-proxy can be run on Windows Server.
Note: Windows Server Containers on Kubernetes is an Alpha feature in Kubernetes 1.5."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @devin-donnelly. I am making the suggested changes
Windows Server Containers are supported on Kubernetes as an alpha feature. Kubernetes control plane (API Server, Scheduler, Controller Manager etc) will continue to run on Linux, while the kubelet and kube-proxy can be run on Windows Server. | ||
|
||
## Prerequisites | ||
With the alpha release, Windows Server Containers for Kubernetes is supported using the following: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"With the alpha release," -> "In Kubernetes version 1.5,"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @devin-donnelly. I am making the suggested changes
The following diagram illustrates the Windows Server networking setup for Kubernetes Setup | ||
![Windows Setup](windows-setup.png) | ||
|
||
## Setup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Three successive nested headings is indicative of major structural problems.
Better structure:
Setting up Windows Server Containers on Kubernetes
To run Windows Server Containers on Kubernetes, you'll need to set up both your host machines and the Kubernetes node components for Windows. The setup requirements for Windows Server Containers vary depending on whether or not you're using Windows or Linux Hosts.
Windows Host Setup
- Steps
Linux Host Setup (editorial note: Why? I thought the whole point of this document was how to do Windows node setups).
- Steps
Component Setup
Requirements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I have 3 successive nested headings is because Setup have 3 types Host, Component and Route. Host and Route instructions are different for Windows and Linux Hosts and Components setup have instructions for building kubelet
and kube-proxy
for Windows. So as each Setup type have 2 more child elements I thought it is easier to follow if it is nested headings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting up Windows Server Containers on Kubernetes
To run Windows Server Containers on Kubernetes, you'll need to set up both your host machines and the Kubernetes node components for Windows and setup Routes for Pod communication on different nodes
Host Setup
Windows Host Setup
- Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server
- DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from Docker master
- Pull the
apprenda/pause
image fromhttps://hub.docker.com/r/apprenda/pause
- RRAS (Routing) Windows feature enabled
Linux Host Setup
- Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using.
- CNI network plugin installed.
Component Setup
Requirements
- Git, Go 1.7.1+
- make (if using Linux or MacOS)
- Important notes and other dependencies are listed here
kubelet
To build the kubelet, run:
cd $GOPATH/src/k8s.io/kubernetes
- Build kubelet
- Linux/MacOS:
KUBE_BUILD_PLATFORMS=windows/amd64 make WHAT=cmd/kubelet
- Windows:
go build cmd/kubelet/kubelet.go
- Linux/MacOS:
kube-proxy
To build kube-proxy, run:
cd $GOPATH/src/k8s.io/kubernetes
- Build kube-proxy
- Linux/MacOS:
KUBE_BUILD_PLATFORMS=windows/amd64 make WHAT=cmd/kube-proxy
- Windows:
go build cmd/kube-proxy/proxy.go
- Linux/MacOS:
Route Setup
The below example setup assumes one Linux and two Windows Server 2016 nodes and a cluster CIDR 192.168.0.0/16
Hostname | Routable IP address | Pod CIDR |
---|---|---|
Lin01 | <IP of Lin01 host> |
192.168.0.0/24 |
Win01 | <IP of Win01 host> |
192.168.1.0/24 |
Win02 | <IP of Win02 host> |
192.168.2.0/24 |
Lin01
ip route add 192.168.1.0/24 via <IP of Win01 host>
ip route add 192.168.2.0/24 via <IP of Win02 host>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this acceptable resolution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's good.
|
||
#### kubelet | ||
|
||
In order to build the *kubelet*, run: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"In order" not necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @devin-donnelly. I am making the suggested changes
Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using. Linux hosts also require to have CNI Setup. | ||
|
||
### Component Setup | ||
In order to build the work node components, the *kubelet* and *kube-proxy* for Windows, the following needs to be installed on the host |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"In order" not necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @devin-donnelly. I am making the suggested changes
## Linux | ||
Use your preferred method to start Kubernetes cluster on Linux. Please note that Cluster CIDR might need to be updated. | ||
## Windows | ||
### kubelet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nested headings. Replace "### kubelet" with "To start kubelet on your Windows node:"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am accepting the suggestions and making the required changes
2. Run *kubelet* executable using the below command | ||
`kubelet.exe --hostname-override=<ip address/hostname of the windows node> --pod-infra-container-image="apprenda/pause" --resolv-conf="" --api_servers=<api server location>` | ||
|
||
### kube-proxy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace "### kube-proxy" with "To start kube-proxy on your Windows node:"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am accepting the suggestions and making the required changes
2. Run *kube-proxy* executable using the below command | ||
`.\proxy.exe --v=3 --proxy-mode=userspace --hostname-override=<ip address/hostname of the windows node> --master=<api server location> --bind-address=<ip address of the windows node>` | ||
|
||
## Scheduling PODs on Windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Pod" should not be all-caps. It's not an acronym.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am accepting the suggestions and making the required changes
`.\proxy.exe --v=3 --proxy-mode=userspace --hostname-override=<ip address/hostname of the windows node> --master=<api server location> --bind-address=<ip address of the windows node>` | ||
|
||
## Scheduling PODs on Windows | ||
As Kubernetes control plane currently runs on Linux, the resulting cluster will have both Linux and Windows nodes. TO schedule PODs on Windows, `nodeSelector` constraint has to be set with label `beta.kubernetes.io/os` having value `windows` as shown in the example below, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither "TO" nor "POD" should be all-caps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am accepting the suggestions and making the required changes
`.\proxy.exe --v=3 --proxy-mode=userspace --hostname-override=<ip address/hostname of the windows node> --master=<api server location> --bind-address=<ip address of the windows node>` | ||
|
||
## Scheduling PODs on Windows | ||
As Kubernetes control plane currently runs on Linux, the resulting cluster will have both Linux and Windows nodes. TO schedule PODs on Windows, `nodeSelector` constraint has to be set with label `beta.kubernetes.io/os` having value `windows` as shown in the example below, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested rephrase for clarity: "Because your cluster has both Linux and Windows nodes, you must explictly set the nodeSelector
constraint to be able to schedule Pods to Windows nodes. You must set nodeSelector
with the label beta.kubernetes.io/os
to the value windows
; see the following example:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am accepting the suggestions and making the required changes
Thanks for your review @devin-donnelly. I have made the suggested chances. |
Thanks for your patience on my review. This looks great. Excited to see this new way to use Kubernetes and Windows! LGTM. |
This PR is to add documentation for getting started guide for supporting Windows Server Containers on Kubernetes.
The work to support Windows Server Container is tracked by kubernetes/enhancements#116 and the code changes are already merged and tagged for Release 1.5
This change is