whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'main' into tweak-localization

Browse Source
This commit is contained in:
Qiming Teng
2022-06-21 10:44:14 +08:00
committed by GitHub
parent 700433da48 a5316fb677
commit a35c434664
33 changed files with 4059 additions and 877 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/community/code-of-conduct.md
+2 -2
View File
@@ -8,9 +8,9 @@ community_styles_migrated: true
<div class="community-section" id="cncf-code-of-conduct-intro">
<p>
Kubernetes follows the
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF Code of Conduct</a>.
<a href="https://github.com/cncf/foundation/blob/main/code-of-conduct.md">CNCF Code of Conduct</a>.
The text of the CNCF CoC is replicated below, as of
<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">commit 214585e</a>.
<a href="https://github.com/cncf/foundation/blob/71b12a2f8b4589788ef2d69b351a3d035c68d927/code-of-conduct.md">commit 71b12a2</a>.
If you notice that this is out of date, please
<a href="https://github.com/kubernetes/website/issues/new">file an issue</a>.
</p>
content/en/community/static/cncf-code-of-conduct.md
+53 -26
View File
@@ -1,45 +1,72 @@
<!-- Do not edit this file directly. Get the latest from
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
## CNCF Community Code of Conduct v1.0
https://github.com/cncf/foundation/blob/main/code-of-conduct.md -->
## CNCF Community Code of Conduct v1.1
### Contributor Code of Conduct
As contributors and maintainers of this project, and in the interest of fostering
As contributors and maintainers in the CNCF community, and in the interest of fostering
an open and welcoming community, we pledge to respect all people who contribute
through reporting issues, posting feature requests, updating documentation,
submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for
everyone, regardless of level of experience, gender, gender identity and expression,
We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression,
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.
Examples of unacceptable behavior by participants include:
## Scope
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
### CNCF Events
CNCF events, or events run by the Linux Foundation with professional events staff, are governed by the Linux Foundation [Events Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be used in conjunction with the CNCF Code of Conduct.
## Our Standards
Examples of behavior that contributes to a positive environment include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the
overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses,
without explicit permission
* Other unethical or unprofessional conduct.
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are not
aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
commit themselves to fairly and consistently applying these principles to every aspect
of managing this project. Project maintainers who do not follow or enforce the Code of
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.
By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect
of managing this project.
Project maintainers who do not follow or enforce the Code of
Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community.
## Reporting
Instances of abusive, harassing, or otherwise unacceptable behavior in Kubernetes may be reported by contacting the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via <conduct@kubernetes.io>. For other projects, please contact a CNCF project maintainer or our mediator, Mishi Choudhary <mishi@linux.com>.
For incidents occuring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via <conduct@kubernetes.io>. You can expect a response within three business days.
For other projects, please contact the CNCF staff via <conduct@cncf.io>. You can expect a response within three business days.
In matters that require an outside mediator, CNCF has retained Mishi Choudhary (mishi@linux.com). Use of an outside mediator can be requested when reporting or used at CNCF staff's discretion. In general, contacting <conduct@cncf.io> directly is preferred.
## Enforcement
The Kubernetes project's [Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) enforces code of conduct issues. For all other projects, the CNCF enforces code of conduct issues.
Both bodies try to resolve incidents without punishment, but may remove people from the project or CNCF communities at their discretion.
## Acknowledgements
This Code of Conduct is adapted from the Contributor Covenant
(https://contributor-covenant.org), version 1.2.0, available at
https://contributor-covenant.org/version/1/2/0/
### CNCF Events Code of Conduct
CNCF events are governed by the Linux Foundation [Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.
(http://contributor-covenant.org), version 2.0 available at
http://contributor-covenant.org/version/2/0/code_of_conduct/
content/en/docs/concepts/workloads/controllers/job.md
-1
View File
@@ -691,7 +691,6 @@ In order to use this behavior, you must enable the `JobTrackingWithFinalizers`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/)
and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
It is enabled by default.
When enabled, the control plane tracks new Jobs using the behavior described
below. Jobs created before the feature was enabled are unaffected. As a user,
content/en/docs/concepts/workloads/pods/downward-api.md
+3 -3
View File
@@ -16,7 +16,7 @@ or API server.
An example is an existing application that assumes a particular well-known
environment variable holds a unique identifier. One possibility is to wrap the
application, but that is tedious and error prone, and it violates the goal of low
application, but that is tedious and error-prone, and it violates the goal of low
coupling. A better option would be to use the Pod's name as an identifier, and
inject the Pod's name into the well-known environment variable.
@@ -119,8 +119,8 @@ for resources such as CPU and memory.
If CPU and memory limits are not specified for a container, and you use the
downward API to try to expose that information, then the
kubelet defaults to exposing the maximum allocatable value for CPU and memory
(based on the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
calculation).
based on the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
calculation.
## {{% heading "whatsnext" %}}
content/en/docs/contribute/advanced.md
+2 -2
View File
@@ -136,7 +136,7 @@ The role of co-chair is one of service: co-chairs build contributor capacity, ha
Responsibilities include:
- Keep SIG Docs focused on maximizing developer happiness through excellent documentation
- Exemplify the [community code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and hold SIG members accountable to it
- Exemplify the [community code of conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) and hold SIG members accountable to it
- Learn and set best practices for the SIG by updating contribution guidelines
- Schedule and run SIG meetings: weekly status updates, quarterly retro/planning sessions, and others as needed
- Schedule and run doc sprints at KubeCon events and other conferences
@@ -147,7 +147,7 @@ Responsibilities include:
To schedule and run effective meetings, these guidelines show what to do, how to do it, and why.
**Uphold the [community code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**:
**Uphold the [community code of conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)**:
- Hold respectful, inclusive discussions with respectful, inclusive language.
content/en/docs/contribute/localization.md
+1 -1
View File
@@ -198,7 +198,7 @@ For example, for German the strings live in `data/i18n/de/de.toml`, and
### Localize the community code of conduct
Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages)
Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/main/code-of-conduct-languages)
repository to add the code of conduct in your language.
### Setting up the OWNERS files
content/en/docs/contribute/new-content/blogs-case-studies.md
+115 -49
View File
@@ -16,16 +16,17 @@ Case studies require extensive review before they're approved.
## The Kubernetes Blog
The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community.
This includes end users and developers.
Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too!
The Kubernetes blog is used by the project to communicate new features, community reports, and any
news that might be relevant to the Kubernetes community. This includes end users and developers.
Most of the blog's content is about things happening in the core project, but we encourage you to
submit about things happening elsewhere in the ecosystem too!
Anyone can write a blog post and submit it for review.
### Submit a Post
Blog posts should not be commercial in nature and should consist of original content that applies broadly to the Kubernetes community.
Appropriate blog content includes:
Blog posts should not be commercial in nature and should consist of original content that applies
broadly to the Kubernetes community. Appropriate blog content includes:
- New Kubernetes capabilities
- Kubernetes projects updates
@@ -43,75 +44,138 @@ Unsuitable content includes:
To submit a blog post, follow these steps:
1. [Sign the CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla) if you have not yet done so.
1. Have a look at the Markdown format for existing blog posts in the [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
1. [Sign the CLA](https://github.com/kubernetes/community/blob/master/CLA.md)
if you have not yet done so.
1. Have a look at the Markdown format for existing blog posts in the
[website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
1. Write out your blog post in a text editor of your choice.
1. On the same link from step 2, click the Create new file button. Paste your content into the editor. Name the file to match the proposed title of the blog post, but don’t put the date in the file name. The blog reviewers will work with you on the final file name and the date the blog will be published.
1. On the same link from step 2, click the Create new file button. Paste your content into the editor.
Name the file to match the proposed title of the blog post, but don’t put the date in the file name.
The blog reviewers will work with you on the final file name and the date the blog will be published.
1. When you save the file, GitHub will walk you through the pull request process.
1. A blog post reviewer will review your submission and work with you on feedback and final details. When the blog post is approved, the blog will be scheduled for publication.
1. A blog post reviewer will review your submission and work with you on feedback and final details.
When the blog post is approved, the blog will be scheduled for publication.
### Guidelines and expectations
- Blog posts should not be vendor pitches.
- Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties.
- Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog.
- Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out.
- Articles must contain content that applies broadly to the Kubernetes community. For example, a
submission should focus on upstream Kubernetes as opposed to vendor-specific configurations.
Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for
what is typically allowed on Kubernetes properties.
- Links should primarily be to the official Kubernetes documentation. When using external
references, links should be diverse - For example a submission shouldn't contain only links
back to a single company's blog.
- Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/)
is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't
hesitate to reach out.
- Blog posts are not published on specific dates.
- Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees.
- Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle.
- If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post.
- Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time.
- Articles are reviewed by community volunteers. We'll try our best to accommodate specific
timing, but we make no guarantees.
- Many core parts of the Kubernetes projects submit blog posts during release windows, delaying
publication times. Consider submitting during a quieter period of the release cycle.
- If you are looking for greater coordination on post release dates, coordinating with
[CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post.
- Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs,
you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/)
to ask in real time.
- Blog posts should be relevant to Kubernetes users.
- Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts).
- The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
- Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
- Blog posts about contributing to the Kubernetes project should be in the [Kubernetes Contributors site](https://kubernetes.dev)
- Topics related to participation in or results of Kubernetes SIGs activities are always on
topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines)
for support on these posts).
- The components of Kubernetes are purposely modular, so tools that use existing integration
points like CNI and CSI are on topic.
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team
before submitting a draft.
- Many CNCF projects have their own blog. These are often a better choice for posts. There are
times of major feature or milestone for a CNCF project that users would be interested in
reading on the Kubernetes blog.
- Blog posts about contributing to the Kubernetes project should be in the
[Kubernetes Contributors site](https://kubernetes.dev)
- Blog posts should be original content
- The official blog is not for repurposing existing content from a third party as new content.
- The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
- The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows
commercial use of the content for commercial purposes, but not the other way around.
- Blog posts should aim to be future proof
- Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader.
- It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post.
- Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care.
- Given the development velocity of the project, we want evergreen content that won't require
updates to stay accurate for the reader.
- It can be a better choice to add a tutorial or update official documentation than to write a
high level overview as a blog post.
- Consider concentrating the long technical content as a call to action of the blog post, and
focus on the problem space or why readers should care.
### Technical Considerations for submitting a blog post
Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack.
Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator
for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use
this technology stack.
We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out.
We recognize that this requirement makes the process more difficult for less-familiar folks to
submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to
lower the barrier, please volunteer to help out.
The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)
manages the review process for blog posts. For more information, see
[Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
To submit a blog post follow these directions:
- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) directory.
- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post.
New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts)
directory.
- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
- Ensure that your blog post follows the correct naming conventions and the following frontmatter
(metadata) information:
- The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build.
- The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example,
`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes
failures during a build.
- The front matter must include the following:
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
- The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible.
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
- The first or initial commit message should be a short summary of the work being done and
should stand alone as a description of the blog post. Please note that subsequent edits to
your blog will be squashed into this main commit, so it should be as useful as possible.
- Examples of a good commit message:
- _Add blog post on the foo kubernetes feature_
- _blog: foobar announcement_
- _Add blog post on the foo kubernetes feature_
- _blog: foobar announcement_
- Examples of bad commit message:
- _Add blog post_
- _._
- _initial commit_
- _draft post_
- The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published.
- If the content of the blog post contains only content that is not expected to require updates to stay accurate for the reader, it can be marked as evergreen and exempted from the automatic warning about outdated content added to blog posts older than one year.
- The blog team will then review your PR and give you comments on things you might need to fix.
After that the bot will merge your PR and your blog post will be published.
- If the content of the blog post contains only content that is not expected to require updates
to stay accurate for the reader, it can be marked as evergreen and exempted from the automatic
warning about outdated content added to blog posts older than one year.
- To mark a blog post as evergreen, add this to the front matter:
```yaml
@@ -121,13 +185,15 @@ To submit a blog post follow these directions:
- **Tutorials** that only apply to specific releases or versions and not all future versions
- References to pre-GA APIs or features
## Submit a case study
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies.
Case studies highlight how organizations are using Kubernetes to solve real-world problems. The
Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}
collaborate with you on all case studies.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/main/content/en/case-studies).
Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.
Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)
and submit your request as outlined in the guidelines.
content/en/docs/contribute/review/reviewing-prs.md
+1 -1
View File
@@ -27,7 +27,7 @@ Before reviewing, it's a good idea to:
Before you start a review:
- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and ensure that you abide by it at all times.
- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) and ensure that you abide by it at all times.
- Be polite, considerate, and helpful.
- Comment on positive aspects of PRs as well as changes.
- Be empathetic and mindful of how your review may be received.
content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
-256
View File
@@ -1,256 +0,0 @@
---
reviewers:
- jayunit100
- jsturtevant
- marosset
- perithompson
title: Adding Windows nodes
min-kubernetes-server-version: 1.17
content_type: tutorial
weight: 30
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
## {{% heading "prerequisites" %}}
{{< version-check >}}
* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
(or higher) in order to configure the Windows node that hosts Windows containers.
If you are using VXLAN/Overlay networking you must have also have [KB4489899](https://support.microsoft.com/help/4489899) installed.
* A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)).
## {{% heading "objectives" %}}
* Register a Windows node to the cluster
* Configure networking so Pods and Services on Linux and Windows can communicate with each other
<!-- lessoncontent -->
## Getting Started: Adding a Windows Node to Your Cluster
### Networking Configuration
Once you have a Linux-based Kubernetes control-plane node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity.
#### Configuring Flannel
1. Prepare Kubernetes control plane for Flannel
Some minor preparation is recommended on the Kubernetes control plane in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. The following command must be run on all Linux nodes:
```bash
sudo sysctl net.bridge.bridge-nf-call-iptables=1
```
1. Download & configure Flannel for Linux
Download the most recent Flannel manifest:
```bash
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
```
Modify the `net-conf.json` section of the flannel manifest in order to set the VNI to 4096 and the Port to 4789. It should look as follows:
```json
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
"VNI": 4096,
"Port": 4789
}
}
```
{{< note >}}The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
for an explanation of these fields.{{< /note >}}
{{< note >}}To use L2Bridge/Host-gateway mode instead change the value of `Type` to `"host-gw"` and omit `VNI` and `Port`.{{< /note >}}
1. Apply the Flannel manifest and validate
Let's apply the Flannel configuration:
```bash
kubectl apply -f kube-flannel.yml
```
After a few minutes, you should see all the pods as running if the Flannel pod network was deployed.
```bash
kubectl get pods -n kube-system
```
The output should include the Linux flannel DaemonSet as running:
```
NAMESPACE NAME READY STATUS RESTARTS AGE
...
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
```
1. Add Windows Flannel and kube-proxy DaemonSets
Now you can add Windows-compatible versions of Flannel and kube-proxy. In order
to ensure that you get a compatible version of kube-proxy, you'll need to substitute
the tag of the image. The following example shows usage for Kubernetes {{< param "fullversion" >}},
but you should adjust the version for your own deployment.
```bash
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
```
{{< note >}}
If you're using host-gateway use https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml instead
{{< /note >}}
{{< note >}}
If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line:
```powershell
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
```
in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly.
```bash
# Example
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
```
{{< /note >}}
### Joining a Windows worker node
{{< note >}}
All code snippets in Windows sections are to be run in a PowerShell environment
with elevated permissions (Administrator) on the Windows worker node.
{{< /note >}}
{{< tabs name="tab-windows-kubeadm-runtime-installation" >}}
{{% tab name="CRI-containerD" %}}
#### Install containerD
```powershell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1
.\Install-Containerd.ps1
```
{{< note >}}
To install a specific version of containerD specify the version with -ContainerDVersion.
```powershell
# Example
.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
```
If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, specify the name with `-netAdapterName`.
```powershell
# Example
.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2"
```
{{< /note >}}
#### Install wins, kubelet, and kubeadm
```PowerShell
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
```
Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools)
which is required so that kubeadm can talk to the CRI endpoint.
#### Run `kubeadm` to join the node
Use the command that was given to you when you ran `kubeadm init` on a control plane host.
If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command`
(on a control plane host) to generate a new token and join command.
{{% /tab %}}
{{% tab name="Docker Engine" %}}
#### Install Docker Engine
Install the `Containers` feature
```powershell
Install-WindowsFeature -Name containers
```
Install Docker
Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker).
[Install cri-dockerd](https://github.com/Mirantis/cri-dockerd) which is required so that the kubelet
can communicate with Docker on a CRI compatible endpoint.
{{< note >}}
Docker Engine does not implement the [CRI](/docs/concepts/architecture/cri/)
which is a requirement for a container runtime to work with Kubernetes.
For that reason, an additional service [cri-dockerd](https://github.com/Mirantis/cri-dockerd)
has to be installed. cri-dockerd is a project based on the legacy built-in
Docker Engine support that was [removed](/dockershim) from the kubelet in version 1.24.
{{< /note >}}
Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools)
which is required so that kubeadm can talk to the CRI endpoint.
#### Install wins, kubelet, and kubeadm
```PowerShell
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
#### Run `kubeadm` to join the node
Use the command that was given to you when you ran `kubeadm init` on a control plane host.
If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command`
(on a control plane host) to generate a new token and join command.
{{% /tab %}}
{{< /tabs >}}
### Verifying your installation
You should now be able to view the Windows node in your cluster by running:
```bash
kubectl get nodes -o wide
```
If your new node is in the `NotReady` state it is likely because the flannel image is still downloading.
You can check the progress as before by checking on the flannel pods in the `kube-system` namespace:
```shell
kubectl -n kube-system get pods -l app=flannel
```
Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads.
## {{% heading "whatsnext" %}}
- [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
+16 -11
View File
@@ -34,7 +34,7 @@ upgrade the control plane nodes before upgrading your Windows nodes.
```powershell
# replace {{< param "fullversion" >}} with your desired version
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
curl.exe -Lo <path-to-kubeadm.exe> https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
```
### Drain the node
@@ -62,16 +62,28 @@ upgrade the control plane nodes before upgrading your Windows nodes.
kubeadm upgrade node
```
### Upgrade kubelet
### Upgrade kubelet and kube-proxy
1. From the Windows node, upgrade and restart the kubelet:
```powershell
stop-service kubelet
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
curl.exe -Lo <path-to-kubelet.exe> https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
restart-service kubelet
```
2. From the Windows node, upgrade and restart the kube-proxy.
```powershell
stop-service kube-proxy
curl.exe -Lo <path-to-kube-proxy.exe> https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kube-proxy.exe
restart-service kube-proxy
```
{{< note >}}
If you are running kube-proxy in a HostProcess container within a Pod, and not as a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests.
{{< /note >}}
### Uncordon the node
1. From a machine with access to the Kubernetes API,
@@ -81,14 +93,7 @@ bring the node back online by marking it schedulable:
# replace <node-to-drain> with the name of your node
kubectl uncordon <node-to-drain>
```
### Upgrade kube-proxy
1. From a machine with access to the Kubernetes API, run the following,
again replacing {{< param "fullversion" >}} with your desired version:
```shell
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
```
content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
+1 -1
View File
@@ -34,7 +34,7 @@ Kubernetes cluster.
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
```
1. Chose one of your nodes, and add a label to it:
1. Choose one of your nodes, and add a label to it:
```shell
kubectl label nodes <your-node-name> disktype=ssd
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+40 -31
View File
@@ -14,7 +14,7 @@ weight: 30
<!-- overview -->
This page shows how to run a replicated stateful application using a
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller.
{{< glossary_tooltip term_id="statefulset" >}}.
This application is a replicated MySQL database. The example topology has a
single primary server and multiple replicas, using asynchronous row-based
replication.
@@ -24,12 +24,10 @@ replication.
on general patterns for running stateful applications in Kubernetes.
{{< /note >}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "task-tutorial-prereqs.md" >}}
* {{< include "default-storage-class-prereqs.md" >}}
* This tutorial assumes you are familiar with
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
@@ -46,7 +44,7 @@ on general patterns for running stateful applications in Kubernetes.
## {{% heading "objectives" %}}
* Deploy a replicated MySQL topology with a StatefulSet controller.
* Deploy a replicated MySQL topology with a StatefulSet.
* Send MySQL client traffic.
* Observe resistance to downtime.
* Scale the StatefulSet up and down.
@@ -60,7 +58,7 @@ on general patterns for running stateful applications in Kubernetes.
The example MySQL deployment consists of a ConfigMap, two Services,
and a StatefulSet.
### ConfigMap
### Create a ConfigMap {#configmap}
Create the ConfigMap from the following YAML configuration file:
@@ -71,7 +69,7 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
```
This ConfigMap provides `my.cnf` overrides that let you independently control
configuration on the primary MySQL server and replicas.
configuration on the primary MySQL server and its replicas.
In this case, you want the primary server to be able to serve replication logs to replicas
and you want replicas to reject any writes that don't come via replication.
@@ -80,7 +78,7 @@ portions to apply to different Pods.
Each Pod decides which portion to look at as it's initializing,
based on information provided by the StatefulSet controller.
### Services
### Create Services {#services}
Create the Services from the following YAML configuration file:
@@ -90,23 +88,24 @@ Create the Services from the following YAML configuration file:
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
```
The Headless Service provides a home for the DNS entries that the StatefulSet
controller creates for each Pod that's part of the set.
Because the Headless Service is named `mysql`, the Pods are accessible by
The headless Service provides a home for the DNS entries that the StatefulSet
{{< glossary_tooltip text="controllers" term_id="controller" >}} creates for each
Pod that's part of the set.
Because the headless Service is named `mysql`, the Pods are accessible by
resolving `<pod-name>.mysql` from within any other Pod in the same Kubernetes
cluster and namespace.
The Client Service, called `mysql-read`, is a normal Service with its own
The client Service, called `mysql-read`, is a normal Service with its own
cluster IP that distributes connections across all MySQL Pods that report
being Ready. The set of potential endpoints includes the primary MySQL server and all
replicas.
Note that only read queries can use the load-balanced Client Service.
Note that only read queries can use the load-balanced client Service.
Because there is only one primary MySQL server, clients should connect directly to the
primary MySQL Pod (through its DNS entry within the Headless Service) to execute
primary MySQL Pod (through its DNS entry within the headless Service) to execute
writes.
### StatefulSet
### Create the StatefulSet {#statefulset}
Finally, create the StatefulSet from the following YAML configuration file:
@@ -122,7 +121,7 @@ You can watch the startup progress by running:
kubectl get pods -l app=mysql --watch
```
After a while, you should see all 3 Pods become Running:
After a while, you should see all 3 Pods become `Running`:
```
NAME READY STATUS RESTARTS AGE
@@ -132,8 +131,11 @@ mysql-2 2/2 Running 0 1m
```
Press **Ctrl+C** to cancel the watch.
{{< note >}}
If you don't see any progress, make sure you have a dynamic PersistentVolume
provisioner enabled as mentioned in the [prerequisites](#before-you-begin).
provisioner enabled, as mentioned in the [prerequisites](#before-you-begin).
{{< /note >}}
This manifest uses a variety of techniques for managing stateful Pods as part of
a StatefulSet. The next section highlights some of these techniques to explain
@@ -155,10 +157,10 @@ properties to perform orderly startup of MySQL replication.
### Generating configuration
Before starting any of the containers in the Pod spec, the Pod first runs any
[Init Containers](/docs/concepts/workloads/pods/init-containers/)
[init containers](/docs/concepts/workloads/pods/init-containers/)
in the order defined.
The first Init Container, named `init-mysql`, generates special MySQL config
The first init container, named `init-mysql`, generates special MySQL config
files based on the ordinal index.
The script determines its own ordinal index by extracting it from the end of
@@ -166,8 +168,7 @@ the Pod name, which is returned by the `hostname` command.
Then it saves the ordinal (with a numeric offset to avoid reserved values)
into a file called `server-id.cnf` in the MySQL `conf.d` directory.
This translates the unique, stable identity provided by the StatefulSet
controller into the domain of MySQL server IDs, which require the same
properties.
into the domain of MySQL server IDs, which require the same properties.
The script in the `init-mysql` container also applies either `primary.cnf` or
`replica.cnf` from the ConfigMap by copying the contents into `conf.d`.
@@ -187,7 +188,7 @@ logs might not go all the way back to the beginning of time.
These conservative assumptions are the key to allow a running StatefulSet
to scale up and down over time, rather than being fixed at its initial size.
The second Init Container, named `clone-mysql`, performs a clone operation on
The second init container, named `clone-mysql`, performs a clone operation on
a replica Pod the first time it starts up on an empty PersistentVolume.
That means it copies all existing data from another running Pod,
so its local state is consistent enough to begin replicating from the primary server.
@@ -202,7 +203,7 @@ Ready before starting Pod `N+1`.
### Starting replication
After the Init Containers complete successfully, the regular containers run.
After the init containers complete successfully, the regular containers run.
The MySQL Pods consist of a `mysql` container that runs the actual `mysqld`
server, and an `xtrabackup` container that acts as a
[sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
@@ -291,13 +292,13 @@ endpoint might be selected upon each connection attempt:
You can press **Ctrl+C** when you want to stop the loop, but it's useful to keep
it running in another window so you can see the effects of the following steps.
## Simulating Pod and Node downtime
## Simulate Pod and Node failure {#simulate-pod-and-node-downtime}
To demonstrate the increased availability of reading from the pool of replicas
instead of a single server, keep the `SELECT @@server_id` loop from above
running while you force a Pod out of the Ready state.
### Break the Readiness Probe
### Break the Readiness probe
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
@@ -371,14 +372,18 @@ NAME READY STATUS RESTARTS AGE IP NODE
mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-node-9l2t
```
Then drain the Node by running the following command, which cordons it so
Then, drain the Node by running the following command, which cordons it so
no new Pods may schedule there, and then evicts any existing Pods.
Replace `<node-name>` with the name of the Node you found in the last step.
This might impact other applications on the Node, so it's best to
**only do this in a test cluster**.
{{< caution >}}
Draining a Node can impact other workloads and applications
running on the same node. Only perform the following step in a test
cluster.
{{< /caution >}}
```shell
# See above advice about impact on other workloads
kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets
```
@@ -413,8 +418,9 @@ kubectl uncordon <node-name>
## Scaling the number of replicas
With MySQL replication, you can scale your read query capacity by adding replicas.
With StatefulSet, you can do this with a single command:
When you use MySQL replication, you can scale your read query capacity by
adding replicas.
For a StatefulSet, you can achieve this with a single command:
```shell
kubectl scale statefulset mysql --replicas=5
@@ -453,10 +459,13 @@ Scaling back down is also seamless:
kubectl scale statefulset mysql --replicas=3
```
Note, however, that while scaling up creates new PersistentVolumeClaims
{{< note >}}
Although scaling up creates new PersistentVolumeClaims
automatically, scaling down does not automatically delete these PVCs.
This gives you the choice to keep those initialized PVCs around to make
scaling back up quicker, or to extract data before deleting them.
{{< /note >}}
You can see this by running:
content/en/examples/application/mysql/mysql-configmap.yaml
+1
View File
@@ -4,6 +4,7 @@ metadata:
name: mysql
labels:
app: mysql
app.kubernetes.io/name: mysql
data:
primary.cnf: |
# Apply this config only on the primary.
content/en/examples/application/mysql/mysql-services.yaml
+3
View File
@@ -5,6 +5,7 @@ metadata:
name: mysql
labels:
app: mysql
app.kubernetes.io/name: mysql
spec:
ports:
- name: mysql
@@ -21,6 +22,8 @@ metadata:
name: mysql-read
labels:
app: mysql
app.kubernetes.io/name: mysql
readonly: "true"
spec:
ports:
- name: mysql
content/en/examples/application/mysql/mysql-statefulset.yaml
+3 -1
View File
@@ -5,13 +5,15 @@ metadata:
spec:
selector:
matchLabels:
app: mysql
app: mysql-server
app.kubernetes.io/name: mysql
serviceName: mysql
replicas: 3
template:
metadata:
labels:
app: mysql
app.kubernetes.io/name: mysql
spec:
initContainers:
- name: init-mysql