Skip to content

Commit 6145b61

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #27658 from jihoon-seo/210422_Add_line_breaks_in_Markdown_code
Add line breaks in Markdown code
2 parents 487e932 + 0e26501 commit 6145b61

File tree

2 files changed

+84
-28
lines changed

2 files changed

+84
-28
lines changed

‎content/en/docs/setup/production-environment/container-runtimes.md

Lines changed: 16 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,10 @@ Install containerd:
9999
{{< tabs name="tab-cri-containerd-installation" >}}
100100
{{% tab name="Linux" %}}
101101

102-
1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server).
102+
1. Install the `containerd.io` package from the official Docker repositories.
103+
Instructions for setting up the Docker repository for your respective Linux distribution and
104+
installing the `containerd.io` package can be found at
105+
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
103106

104107
2. Configure containerd:
105108

@@ -117,7 +120,8 @@ Install containerd:
117120
{{% /tab %}}
118121
{{% tab name="Windows (PowerShell)" %}}
119122

120-
Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands:
123+
Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`),
124+
and then run the following commands:
121125

122126
1. Download containerd:
123127

@@ -243,7 +247,8 @@ sudo apt-get install cri-o cri-o-runc
243247

244248
{{% tab name="Ubuntu" %}}
245249

246-
To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table:
250+
To install on the following operating systems, set the environment variable `OS`
251+
to the appropriate field in the following table:
247252

248253
| Operating system | `$OS` |
249254
| ---------------- | ----------------- |
@@ -278,7 +283,8 @@ sudo apt-get install cri-o cri-o-runc
278283

279284
{{% tab name="CentOS" %}}
280285

281-
To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table:
286+
To install on the following operating systems, set the environment variable `OS`
287+
to the appropriate field in the following table:
282288

283289
| Operating system | `$OS` |
284290
| ---------------- | ----------------- |
@@ -358,7 +364,10 @@ in sync.
358364

359365
### Docker
360366

361-
1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
367+
1. On each of your nodes, install the Docker for your Linux distribution as per
368+
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
369+
You can find the latest validated version of Docker in this
370+
[dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
362371

363372
2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
364373

@@ -377,7 +386,8 @@ in sync.
377386
```
378387
379388
{{< note >}}
380-
`overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above.
389+
`overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher,
390+
or RHEL or CentOS using version 3.10.0-514 and above.
381391
{{< /note >}}
382392
383393
3. Restart Docker and enable on boot:

‎content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md

Lines changed: 68 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,8 @@ weight: 75
1111

1212
<!-- overview -->
1313

14-
Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
14+
Windows applications constitute a large portion of the services and applications that run in many organizations.
15+
This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
1516

1617

1718

@@ -24,12 +25,18 @@ Windows applications constitute a large portion of the services and applications
2425

2526
## Before you begin
2627

27-
* Create a Kubernetes cluster that includes a [master and a worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)
28-
* It is important to note that creating and deploying services and workloads on Kubernetes behaves in much the same way for Linux and Windows containers. [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. The example in the section below is provided to jumpstart your experience with Windows containers.
28+
* Create a Kubernetes cluster that includes a
29+
[master and a worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)
30+
* It is important to note that creating and deploying services and workloads on Kubernetes
31+
behaves in much the same way for Linux and Windows containers.
32+
[Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical.
33+
The example in the section below is provided to jumpstart your experience with Windows containers.
2934

3035
## Getting Started: Deploying a Windows container
3136

32-
To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below:
37+
To deploy a Windows container on Kubernetes, you must first create an example application.
38+
The example YAML file below creates a simple webserver application.
39+
Create a service spec named `win-webserver.yaml` with the contents below:
3340

3441
```yaml
3542
apiVersion: v1
@@ -76,7 +83,8 @@ spec:
7683
```
7784
7885
{{< note >}}
79-
Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service.
86+
Port mapping is also supported, but for simplicity in this example
87+
the container port 80 is exposed directly to the service.
8088
{{< /note >}}
8189
8290
1. Check that all nodes are healthy:
@@ -98,51 +106,85 @@ Port mapping is also supported, but for simplicity in this example the container
98106

99107
* Two containers per pod on the Windows node, use `docker ps`
100108
* Two pods listed from the Linux master, use `kubectl get pods`
101-
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response
102-
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec
103-
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods
109+
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master
110+
to check for a web server response
111+
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node)
112+
using docker exec or kubectl exec
113+
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`)
114+
from the Linux master and from individual pods
104115
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
105116
* Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
106117
* Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
107118

108119
{{< note >}}
109-
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
120+
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack.
121+
Only Windows pods are able to access service IPs.
110122
{{< /note >}}
111123

112124
## Observability
113125

114126
### Capturing logs from workloads
115127

116-
Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs <pod>`.
128+
Logs are an important element of observability; they enable users to gain insights
129+
into the operational aspect of workloads and are a key ingredient to troubleshooting issues.
130+
Because Windows containers and workloads inside Windows containers behave differently from Linux containers,
131+
users had a hard time collecting logs, limiting operational visibility.
132+
Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows)
133+
or push entries to the application event log.
134+
[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft,
135+
is the recommended way to monitor configured log sources inside a Windows container.
136+
LogMonitor supports monitoring event logs, ETW providers, and custom application logs,
137+
piping them to STDOUT for consumption by `kubectl logs <pod>`.
117138

118-
Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT.
139+
Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files
140+
to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT.
119141

120142
## Using configurable Container usernames
121143

122-
Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
144+
Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes
145+
with different usernames than the image defaults.
146+
The way this is achieved is a bit different from the way it is done for Linux containers.
147+
Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
123148

124149
## Managing Workload Identity with Group Managed Service Accounts
125150

126-
Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
151+
Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA).
152+
Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management,
153+
simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.
154+
Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA.
155+
Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
127156

128157
## Taints and Tolerations
129158

130-
Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
159+
Users today need to use some combination of taints and node selectors in order to
160+
keep Linux and Windows workloads on their respective OS-specific nodes.
161+
This likely imposes a burden only on Windows users. The recommended approach is outlined below,
162+
with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
131163

132164
### Ensuring OS-specific workloads land on the appropriate container host
133165

134-
Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:
166+
Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations.
167+
All Kubernetes nodes today have the following default labels:
135168

136169
* kubernetes.io/os = [windows|linux]
137170
* kubernetes.io/arch = [amd64|arm64|...]
138171

139-
If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
172+
If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`,
173+
it is possible the Pod can be scheduled on any host, Windows or Linux.
174+
This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux.
175+
The best practice is to use a nodeSelector.
140176

141-
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
177+
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers,
178+
as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators.
179+
In those situations, you may be hesitant to make the configuration change to add nodeSelectors.
180+
The alternative is to use Taints. Because the kubelet can set Taints during registration,
181+
it could easily be modified to automatically add a taint when running on Windows only.
142182

143183
For example: `--register-with-taints='os=windows:NoSchedule'`
144184

145-
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
185+
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods).
186+
In order for a Windows Pod to be scheduled on a Windows node,
187+
it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
146188

147189
```yaml
148190
nodeSelector:
@@ -160,9 +202,11 @@ tolerations:
160202
The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
161203
Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
162204

163-
Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
205+
Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this.
206+
If you're running an older version, then it's recommended to add this label manually to Windows nodes.
164207

165-
This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
208+
This label reflects the Windows major, minor, and build number that need to match for compatibility.
209+
Here are values used today for each Windows Server version.
166210

167211
| Product Name | Build Number(s) |
168212
|--------------------------------------|------------------------|
@@ -173,10 +217,12 @@ This label reflects the Windows major, minor, and build number that need to matc
173217

174218
### Simplifying with RuntimeClass
175219

176-
[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
220+
[RuntimeClass] can be used to simplify the process of using taints and tolerations.
221+
A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
177222

178223

179-
1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
224+
1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector`
225+
for the Windows OS, architecture, and version.
180226

181227
```yaml
182228
apiVersion: node.k8s.io/v1

0 commit comments

Comments
 (0)