Merge remote-tracking branch 'upstream/master' into merged-master-dev-1.16
Tunde Oladipupo
commit
7728c1476a
|
|
@ -78,6 +78,11 @@ nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
|
|||
githubWebsiteRepo = "github.com/kubernetes/website"
|
||||
githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"
|
||||
|
||||
# param for displaying an announcement block on every page; see PR #16210
|
||||
announcement = false
|
||||
# announcement_message is only displayed when announcement = true; update with your specific message
|
||||
announcement_message = "The Kubernetes Documentation team would like your feedback! Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.16.0"
|
||||
version = "v1.16"
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ title: "Production-Grade Container Orchestration"
|
|||
abstract: "Automated container deployment, scaling, and management"
|
||||
cid: home
|
||||
---
|
||||
{{< announcement >}}
|
||||
|
||||
{{< deprecationwarning >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,10 +15,6 @@ weight: 40
|
|||
|
||||
StatefulSet is the workload API object used to manage stateful applications.
|
||||
|
||||
{{< note >}}
|
||||
StatefulSets are stable (GA) in 1.9.
|
||||
{{< /note >}}
|
||||
|
||||
{{< glossary_definition term_id="statefulset" length="all" >}}
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -43,7 +39,6 @@ provides a set of stateless replicas. Controllers such as
|
|||
|
||||
## Limitations
|
||||
|
||||
* StatefulSet was a beta resource prior to 1.9 and not available in any Kubernetes release prior to 1.5.
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
* Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
|
||||
* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
|
||||
|
|
|
|||
|
|
@ -55,14 +55,16 @@ PodTemplateList, not Pod Template List.
|
|||
Refer to API objects without saying "object," unless omitting "object"
|
||||
leads to an awkward construction.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>The Pod has two containers.</td><td>The pod has two containers.</td></tr>
|
||||
<tr><td>The Deployment is responsible for ...</td><td>The Deployment object is responsible for ...</td></tr>
|
||||
<tr><td>A PodList is a list of Pods.</td><td>A Pod List is a list of pods.</td></tr>
|
||||
<tr><td>The two ContainerPorts ...</td><td>The two ContainerPort objects ...</td></tr>
|
||||
<tr><td>The two ContainerStateTerminated objects ...</td><td>The two ContainerStateTerminateds ...</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - API objects" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
The Pod has two containers. | The pod has two containers.
|
||||
The Deployment is responsible for ... | The Deployment object is responsible for ...
|
||||
A PodList is a list of Pods. | A Pod List is a list of pods.
|
||||
The two ContainerPorts ... | The two ContainerPort objects ...
|
||||
The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ...
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Use angle brackets for placeholders
|
||||
|
||||
|
|
@ -77,36 +79,40 @@ represents.
|
|||
|
||||
### Use bold for user interface elements
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Click <b>Fork</b>.</td><td>Click "Fork".</td></tr>
|
||||
<tr><td>Select <b>Other</b>.</td><td>Select 'Other'.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Bold interface elements" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Click **Fork**. | Click "Fork".
|
||||
Select **Other**. | Select "Other".
|
||||
{{< /table >}}
|
||||
|
||||
### Use italics to define or introduce new terms
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>A <i>cluster</i> is a set of nodes ...</td><td>A "cluster" is a set of nodes ...</td></tr>
|
||||
<tr><td>These components form the <i>control plane.</i></td><td>These components form the <b>control plane.</b></td></tr>
|
||||
</table>
|
||||
|
||||
{{< table caption = "Do and Don't - Use italics for new terms" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
A _cluster_ is a set of nodes ... | A "cluster" is a set of nodes ...
|
||||
These components form the _control plane_. | These components form the **control plane**.
|
||||
{{< /table >}}
|
||||
|
||||
### Use code style for filenames, directories, and paths
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Open the <code>envars.yaml</code> file.</td><td>Open the envars.yaml file.</td></tr>
|
||||
<tr><td>Go to the <code>/docs/tutorials</code> directory.</td><td>Go to the /docs/tutorials directory.</td></tr>
|
||||
<tr><td>Open the <code>/_data/concepts.yaml</code><!--to-unbreak-atom-highlighting_--> file.</td><td>Open the /_data/concepts.yaml<!--to-unbreak-atom-highlighting_--> file.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use code style for filenames, directories, and paths" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Open the `envars.yaml` file. | Open the envars.yaml file.
|
||||
Go to the `/docs/tutorials` directory. | Go to the /docs/tutorials directory.
|
||||
Open the `/_data/concepts.yaml` file. | Open the /_data/concepts.yaml file.
|
||||
{{< /table >}}
|
||||
|
||||
### Use the international standard for punctuation inside quotes
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>events are recorded with an associated "stage".</td><td>events are recorded with an associated "stage."</td></tr>
|
||||
<tr><td>The copy is called a "fork".</td><td>The copy is called a "fork."</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use the international standard for punctuation inside quotes" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
events are recorded with an associated "stage". | events are recorded with an associated "stage."
|
||||
The copy is called a "fork". | The copy is called a "fork."
|
||||
{{< /table >}}
|
||||
|
||||
## Inline code formatting
|
||||
|
||||
|
|
@ -115,13 +121,17 @@ represents.
|
|||
For inline code in an HTML document, use the `<code>` tag. In a Markdown
|
||||
document, use the backtick (`).
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>The <code>kubectl run</code> command creates a Deployment.</td><td>The "kubectl run" command creates a Deployment.</td></tr>
|
||||
<tr><td>For declarative management, use <code>kubectl apply</code>.</td><td>For declarative management, use "kubectl apply".</td></tr>
|
||||
<tr><td>Enclose code samples with triple backticks. <code>(```)</code></td><td>Enclose code samples with any other syntax.</td></tr>
|
||||
<tr><td>Use single backticks to enclose inline code. For example, `var example = true`.</td><td>Use two asterisks (**) or an underscore (_) to enclose inline code. For example, **var example = true**.</td></tr><tr><td>Use triple backticks before and after a multi-line block of code for fenced code blocks.</td><td>Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations.</td></tr><tr><td>Use meaningful variable names that have a context.</td><td>Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context.</td></tr><tr><td>Remove trailing spaces in the code.</td><td>Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use code style for inline code and commands" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment.
|
||||
For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply".
|
||||
Enclose code samples with triple backticks. `(```)`| Enclose code samples with any other syntax.
|
||||
Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (**) or an underscore (_) to enclose inline code. For example, **var example = true**.
|
||||
Use triple backticks before and after a multi-line block of code for fenced code blocks. | Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations.
|
||||
Use meaningful variable names that have a context. | Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context.
|
||||
Remove trailing spaces in the code. | Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well.
|
||||
{{< /table >}}
|
||||
|
||||
{{< note >}}
|
||||
The website supports syntax highlighting for code samples, but specifying a language is optional. Syntax highlighting in the code block should conform to the [contrast guidelines.](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum)
|
||||
|
|
@ -129,31 +139,36 @@ The website supports syntax highlighting for code samples, but specifying a lang
|
|||
|
||||
### Use code style for object field names
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Set the value of the <code>replicas</code> field in the configuration file.</td><td>Set the value of the "replicas" field in the configuration file.</td></tr>
|
||||
<tr><td>The value of the <code>exec</code> field is an ExecAction object.</td><td>The value of the "exec" field is an ExecAction object.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use code style for object field names" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Set the value of the `replicas` field in the configuration file. | Set the value of the "replicas" field in the configuration file.
|
||||
The value of the `exec` field is an ExecAction object. | The value of the "exec" field is an ExecAction object.
|
||||
{{< /table >}}
|
||||
|
||||
### Use normal style for string and integer field values
|
||||
|
||||
For field values of type string or integer, use normal style without quotation marks.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Set the value of <code>imagePullPolicy</code> to Always.</td><td>Set the value of <code>imagePullPolicy</code> to "Always".</td></tr>
|
||||
<tr><td>Set the value of <code>image</code> to nginx:1.8.</td><td>Set the value of <code>image</code> to <code>nginx:1.8</code>.</td></tr>
|
||||
<tr><td>Set the value of the <code>replicas</code> field to 2.</td><td>Set the value of the <code>replicas</code> field to <code>2</code>.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use normal style for string and integer field values" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Set the value of `imagePullPolicy` to Always. | Set the value of `imagePullPolicy` to "Always".
|
||||
Set the value of `image` to nginx:1.8. | Set the value of `image` to `nginx:1.8`.
|
||||
Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`.
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
## Code snippet formatting
|
||||
|
||||
### Don't include the command prompt
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>kubectl get pods</td><td>$ kubectl get pods</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Don't include the command prompt" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
kubectl get pods | $ kubectl get pods
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Separate commands from output
|
||||
|
||||
|
|
@ -200,13 +215,14 @@ kind: Pod
|
|||
|
||||
A list of Kubernetes-specific terms and words to be used consistently across the site.
|
||||
|
||||
<table>
|
||||
<tr><th>Term</th><th>Usage</th></tr>
|
||||
<tr><td>Kubernetes</td><td>Kubernetes should always be capitalized.</td></tr>
|
||||
<tr><td>Docker</td><td>Docker should always be capitalized.</td></tr>
|
||||
<tr><td>SIG Docs</td><td>SIG Docs rather than SIG-DOCS or other variations.</td></tr>
|
||||
<tr><td>On-premises</td><td>On-premises or On-prem rather than On-premise or other variations.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Kubernetes.io word list" >}}
|
||||
Term | Usage
|
||||
:--- | :----
|
||||
Kubernetes | Kubernetes should always be capitalized.
|
||||
Docker | Docker should always be capitalized.
|
||||
SIG Docs | SIG Docs rather than SIG-DOCS or other variations.
|
||||
On-premises | On-premises or On-prem rather than On-premise or other variations.
|
||||
{{< /table >}}
|
||||
|
||||
## Shortcodes
|
||||
|
||||
|
|
@ -379,26 +395,33 @@ Use a single newline to separate block-level content like headings, lists, image
|
|||
### Headings
|
||||
People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Update the title in the front matter of the page or blog post.</td><td>Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading.</td></tr><tr><td>Use ordered headings to provide a meaningful high-level outline of your content.</td><td>Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.</td>
|
||||
<tr><td>Use pound or hash signs (#) for non-blog post content.</td><td> Use underlines (--- or ===) to designate first-level headings.</td></tr>
|
||||
<tr><td>Use sentence case for headings. For example, <b>Extend kubectl with plugins</b></td><td>Use title case for headings. For example, <b>Extend Kubectl With Plugins</b></td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Headings" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Update the title in the front matter of the page or blog post. | Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading.
|
||||
Use ordered headings to provide a meaningful high-level outline of your content. | Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.
|
||||
Use pound or hash signs (#) for non-blog post content. | Use underlines (--- or ===) to designate first-level headings.
|
||||
Use sentence case for headings. For example, **Extend kubectl with plugins** | Use title case for headings. For example, **Extend Kubectl With Plugins**
|
||||
{{< /table >}}
|
||||
|
||||
### Paragraphs
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Try to keep paragraphs under 6 sentences.</td><td>Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it.</td></tr>
|
||||
<tr><td>Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section.</td><td>Use horizontal rules for decoration.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Paragraphs" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Try to keep paragraphs under 6 sentences. | Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it.
|
||||
Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration.
|
||||
{{< /table >}}
|
||||
|
||||
### Links
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See <a href="#check-required-ports">Check required ports</a> for more details.</td><td>Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See <a href="#check-required-ports">here</a> for more details.</td></tr> <tr><td>Write Markdown-style links ([link text](URL)). For example, <code>[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)</code> and the output is <a href="/docs/contribute/style/hugo-shortcodes/#table-captions">Hugo shortcodes.</td><td>Write HTML-style links <code>(<link href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!)</code> or create links that open in new tabs or windows. For example, <code>[example website](https://example.com){target="_blank"}</code></td></tr>
|
||||
</table>
|
||||
|
||||
{{< table caption = "Do and Don't - Links" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See <a href="#check-required-ports">Check required ports</a> for more details. | Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See <a href="#check-required-ports">here</a> for more details.
|
||||
Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `<a href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!</a>`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}`
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Lists
|
||||
Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list.
|
||||
|
|
@ -430,21 +453,25 @@ This section contains suggested best practices for clear, concise, and consisten
|
|||
|
||||
### Use present tense
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>This command starts a proxy.</td><td>This command will start a proxy.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use present tense" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
This command starts a proxy. | This command will start a proxy.
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
Exception: Use future or past tense if it is required to convey the correct
|
||||
meaning.
|
||||
|
||||
### Use active voice
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>You can explore the API using a browser.</td><td>The API can be explored using a browser.</td></tr>
|
||||
<tr><td>The YAML file specifies the replica count.</td><td>The replica count is specified in the YAML file.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use active voice" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
You can explore the API using a browser. | The API can be explored using a browser.
|
||||
The YAML file specifies the replica count. | The replica count is specified in the YAML file.
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
Exception: Use passive voice if active voice leads to an awkward construction.
|
||||
|
||||
|
|
@ -452,31 +479,35 @@ Exception: Use passive voice if active voice leads to an awkward construction.
|
|||
|
||||
Use simple and direct language. Avoid using unnecessary phrases, such as saying "please."
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>To create a ReplicaSet, ...</td><td>In order to create a ReplicaSet, ...</td></tr>
|
||||
<tr><td>See the configuration file.</td><td>Please see the configuration file.</td></tr>
|
||||
<tr><td>View the Pods.</td><td>With this next command, we'll view the Pods.</td></tr>
|
||||
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Use simple and direct language" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
To create a ReplicaSet, ... | In order to create a ReplicaSet, ...
|
||||
See the configuration file. | Please see the configuration file.
|
||||
View the Pods. | With this next command, we'll view the Pods.
|
||||
{{< /table >}}
|
||||
|
||||
### Address the reader as "you"
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>You can create a Deployment by ...</td><td>We'll create a Deployment by ...</td></tr>
|
||||
<tr><td>In the preceding output, you can see...</td><td>In the preceding output, we can see ...</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Addressing the reader" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
You can create a Deployment by ... | We'll create a Deployment by ...
|
||||
In the preceding output, you can see... | In the preceding output, we can see ...
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Avoid Latin phrases
|
||||
|
||||
Prefer English terms over Latin abbreviations.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>For example, ...</td><td>e.g., ...</td></tr>
|
||||
<tr><td>That is, ...</td><td>i.e., ...</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Avoid Latin phrases" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
For example, ... | e.g., ...
|
||||
That is, ...| i.e., ...
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
Exception: Use "etc." for et cetera.
|
||||
|
||||
|
|
@ -487,22 +518,26 @@ Exception: Use "etc." for et cetera.
|
|||
Using "we" in a sentence can be confusing, because the reader might not know
|
||||
whether they're part of the "we" you're describing.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Version 1.4 includes ...</td><td>In version 1.4, we have added ...</td></tr>
|
||||
<tr><td>Kubernetes provides a new feature for ...</td><td>We provide a new feature ...</td></tr>
|
||||
<tr><td>This page teaches you how to use Pods.</td><td>In this page, we are going to learn about Pods.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Patterns to avoid" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Version 1.4 includes ... | In version 1.4, we have added ...
|
||||
Kubernetes provides a new feature for ... | We provide a new feature ...
|
||||
This page teaches you how to use Pods. | In this page, we are going to learn about Pods.
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Avoid jargon and idioms
|
||||
|
||||
Some readers speak English as a second language. Avoid jargon and idioms to help them understand better.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Internally, ...</td><td>Under the hood, ...</td></tr>
|
||||
<tr><td>Create a new cluster.</td><td>Turn up a new cluster.</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Avoid jargon and idioms" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
Internally, ... | Under the hood, ...
|
||||
Create a new cluster. | Turn up a new cluster.
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Avoid statements about the future
|
||||
|
||||
|
|
@ -515,11 +550,13 @@ information.
|
|||
Avoid words like "currently" and "new." A feature that is new today might not be
|
||||
considered new in a few months.
|
||||
|
||||
<table>
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>In version 1.4, ...</td><td>In the current version, ...</td></tr>
|
||||
<tr><td>The Federation feature provides ...</td><td>The new Federation feature provides ...</td></tr>
|
||||
</table>
|
||||
{{< table caption = "Do and Don't - Avoid statements that will soon be out of date" >}}
|
||||
Do | Don't
|
||||
:--| :-----
|
||||
In version 1.4, ... | In the current version, ...
|
||||
The Federation feature provides ... | The new Federation feature provides ...
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -19,24 +19,13 @@ Create a fork of the Kubernetes documentation repository as described in
|
|||
|
||||
As you prepare to write a new topic, think about the page type that would fit your content the best:
|
||||
|
||||
<table>
|
||||
|
||||
<tr>
|
||||
<td>Concept</td>
|
||||
<td>A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see <a href="/docs/concepts/architecture/nodes/">Nodes</a>.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Task</td>
|
||||
<td>A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">Configure a Pod to Use a Volume for Storage</a>. For an example of a longer task page, see <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">Configure Liveness and Readiness Probes</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Tutorial</td>
|
||||
<td>A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
{{< table caption = "Guidelines for choosing a page type" >}}
|
||||
Type | Description
|
||||
:--- | :----------
|
||||
Concept | A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see <a href="/docs/concepts/architecture/nodes/">Nodes</a>.
|
||||
Task | A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">Configure a Pod to Use a Volume for Storage</a>. For an example of a longer task page, see <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">Configure Liveness and Readiness Probes</a>
|
||||
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
|
||||
{{< /table >}}
|
||||
|
||||
Use a template for each new page. Each page type has a
|
||||
[template](/docs/contribute/style/page-templates/)
|
||||
|
|
|
|||
|
|
@ -8,10 +8,6 @@ title: Using ABAC Authorization
|
|||
content_template: templates/concept
|
||||
weight: 80
|
||||
---
|
||||
{{< note >}}
|
||||
{{< feature-state state="deprecated" for_k8s_version="1.6" >}}
|
||||
The ABAC Authorization feature has been considered deprecated from the Kubernetes 1.6 release.
|
||||
{{< /note >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,324 @@
|
|||
---
|
||||
title: Menetapkan Pod ke Kontainer
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
|
||||
|
||||
Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## nodeSelector
|
||||
|
||||
Penggunaan `nodeSelector` adalah cara pembatasan pemilihan node paling sederhana yang direkomendasikan. `nodeSelector` adalah sebuah _field_ pada PodSpec. `nodeSelector` memerinci sebuah map berisi pasangan kunci-nilai. Agar pod dapat dijalankan pada sebuah node yang memenuhi syarat, node tersebut harus memiliki masing-masing dari pasangan kunci-nilai yang dinyatakan sebagai label (namun node juga dapat memiliki label tambahan diluar itu). Penggunaan paling umum adalah satu pasang kunci-nilai.
|
||||
|
||||
Mari kita telusuri contoh dari penggunaan `nodeSelector`.
|
||||
|
||||
### Langkah Nol: Prasyarat
|
||||
|
||||
Contoh ini mengasumsikan bahwa kamu memiliki pemahaman dasar tentang pod Kubernetes dan kamu telah [membuat kluster Kubernetes](https://github.com/kubernetes/kubernetes#documentation).
|
||||
|
||||
### Langkah Satu: Menyematkan label pada node
|
||||
|
||||
Jalankan `kubectl get nodes` untuk mendapatkan nama dari node-node yang ada dalam kluster kamu. Temukan node yang akan kamu tambahkan label, kemudian jalankan perintah `kubectl label nodes <node-name> <label-key>=<label-value>` untuk menambahkan label pada node yang telah kamu pilih. Sebagai contoh, jika nama node yang saya pilih adalah 'kubernetes-foo-node-1.c.a-robinson.internal' dan label yang ingin saya tambahkan adalah 'disktype=ssd', maka saya dapat menjalankan `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
|
||||
|
||||
Jika terjadi kegagalan dengan kesalahan perintah yang tidak _valid_ ("_invalid command_"), kemungkinan besar kamu menggunakan kubectl dengan versi lebih lama yang tidak memiliki perintah `label`. Dalam hal ini, lihat [versi sebelumnya] (https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) dari petunjuk ini untuk instruksi tentang cara menetapkan label pada node.
|
||||
|
||||
Kamu dapat memastikan perintah telah berhasil dengan menjalankan ulang perintah `kubectl get nodes --show-labels` and memeriksa bahwa node yang dipilih sekarang sudah memiliki label yang ditambahkan. Kamu juga dapat menggunakan `kubectl describe node "nodename"` untuk melihat daftar lengkap label yang dimiliki sebuah node.
|
||||
|
||||
### Langkah Dua: Menambahkan sebuah nodeSelector ke konfigurasi pod kamu
|
||||
|
||||
Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
```
|
||||
|
||||
Kemudian tambahkan sebuah `nodeSelector` seperti berikut:
|
||||
|
||||
{{< codenew file="pods/pod-nginx.yaml" >}}
|
||||
|
||||
Ketika kamu menjalankan perintah `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`, pod tersebut akan dijadwalkan pada node yang memiliki label yang dirinci. Kamu dapat memastikan penambahan nodeSelector berhasil dengan menjalankan `kubectl get pods -o wide` dan melihat "NODE" tempat Pod ditugaskan.
|
||||
|
||||
## Selingan: label node _built-in_
|
||||
|
||||
Sebagai tambahan dari label yang kamu [sematkan](#step-one-attach-label-to-the-node), node sudah terisi dengan satu set label standar. Pada Kubernetes v1.4 label tersebut adalah
|
||||
|
||||
* `kubernetes.io/hostname`
|
||||
* `failure-domain.beta.kubernetes.io/zone`
|
||||
* `failure-domain.beta.kubernetes.io/region`
|
||||
* `beta.kubernetes.io/instance-type`
|
||||
* `kubernetes.io/os`
|
||||
* `kubernetes.io/arch`
|
||||
|
||||
{{< note >}}
|
||||
Nilai dari label-label tersebut spesifik untuk setiap penyedia layanan _cloud_ dan tidak dijamin reliabilitasnya.
|
||||
Contohnya, nilai dari `kubernetes.io/hostname` bisa saja sama dengan nama node pada beberapa lingkungan dan berbeda pada lingkungan lain.
|
||||
{{< /note >}}
|
||||
|
||||
## Isolasi/pembatasan Node
|
||||
|
||||
Menambahkan label pada objek node memungkinkan penargetan pod pada node atau grup node yang spesifik. Penambahan label ini dapat digunakan untuk memastikan pod yang spesifik hanya berjalan pada node dengan isolasi, keamanan, atau pengaturan tertentu. Saat menggunakan label untuk tujuan tersebut, memilih kunci label yang tidak bisa dimodifikasi oleh proses kubelet pada node sangat direkomendasikan. Hal ini mencegah node yang telah diubah untuk menggunakan kredensial kubelet-nya untuk mengatur label-label pada objek nodenya sediri, dan mempengaruhi scheduler untuk menjadwalkan _workload_ ke node yang telah diubah tersebut.
|
||||
|
||||
_Plugin_ penerimaan `NodeRestriction` mencegah kubeletes untuk megatur atau mengubah label dengan awalan `node-restriction.kubernetes.io/`.
|
||||
Untuk memanfaatkan awalan label untuk isolasi node:
|
||||
|
||||
1. Pastikan kamu menggunakan [_authorizer_ node](/docs/reference/access-authn-authz/node/) dan mengaktifkan [_plugin admission NodeRestriction_(/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
|
||||
|
||||
2. Tambah label dengan awalan `node-restriction.kubernetes.io/` ke objek node kamu, dan gunakan label tersebut pada node _selector_ kamu. Contohnya, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
|
||||
|
||||
## Afinitas dan anti-afinitas
|
||||
|
||||
`_Field_ nodeSelector` menyediakan cara yang sangat sederhana untuk membatasi pod ke node dengan label-label tertentu. Fitur afinitas/anti-afinitas saat ini bersifat beta dan memperluas tipe pembatasan yang dapat kamu nyatakan. Peningkatan kunci dari fitur ini adalah
|
||||
|
||||
1. Bahasa yang lebih ekspresif (tidak hanya "AND of exact match")
|
||||
2. Kamu dapat memberikan indikasi bahwa aturan yang dinyatakan bersifat rendah/preferensi dibanding dengan persyaratan mutlak sehingga jika scheduler tidak dapat memenuhinya, pod tetap akan dijadwalkan
|
||||
3. Kamu dapat membatasi dengan label pada pod-pod lain yang berjalan pada node (atau domain _topological_ lain), daripada dengan label pada node itu sendiri, yang memungkinkan pengaturan tentang pod yang dapat dan tidak dapat dilokasikan bersama.
|
||||
|
||||
Fitur afinitas terdiri dari dua tipe afinitas yaitu "node afinitas" dan "inter-pod afinitas/anti-afinitas"
|
||||
Node afinitas adalah seperti `nodeSelector` yang telah ada (tetapi dengam dua kelebihan pertama yang terdaftar di atas), sementara inter-pod afinitas/anti-afinitas membatasi pada label pod daripada label node, seperti yang dijelaskan pada item ketiga pada daftar di atas, sebagai tambahan dari item pertama dan kedua.
|
||||
|
||||
_Field_ `nodeSelector` tetap berjalan seperti biasa, namun pada akhirnya akan ditinggalkan karena afinitas node dapat menyatakan semua yang `nodeSelector` dapat nyatakan.
|
||||
|
||||
### Afinitas node (fitur beta)
|
||||
|
||||
Afinitas node diperkenalkan sebagai fitur alfa pada Kubernetes 1.2.
|
||||
Afinitas node secara konseptual mirip dengan `nodeSelector` yang memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod, berdasarkan label pada node.
|
||||
|
||||
Saat ini ada dia tipe afinitas node, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan
|
||||
`preferredDuringSchedulingIgnoredDuringExecution`. Kamu dapat menganggap dua tipe ini sebagai "kuat" dan "lemah" secara berurutan, dalam arti tipe pertama menyatakan peraturan yang *harus* dipenuhi agar pod dapat dijadwalkan pada node (sama seperti `nodeSelector` tetapi menggunakan sintaksis yang lebih ekpresif), sementara tipe kedua menyatakan *preferensi* yang akan dicoba dilaksanakan tetapi tidak akan dijamin oleh scheduler. Bagian "IgnoredDuringExecution" dari nama tipe ini berarti, mirip dengan cara kerja `nodeSelector`, jika label pada node berubah pada _runtime_ yang menyebabkan aturan afinitas pada pod tidak lagi terpenuhi, pod akan tetap berjalan pada node. Pada masa yang akan datang kami berencana menawarkan `requiredDuringSchedulingRequiredDuringExecution` yang akan berjalan seperti `requiredDuringSchedulingIgnoredDuringExecution` hanya saja tipe ini akan mengeluarkan pod dari node yang gagal untuk memenuhi persyaratan afinitas node pod.
|
||||
|
||||
Dengan denikian, contoh dari `requiredDuringSchedulingIgnoredDuringExecution` adalah "hanya jalankan pod pada node dengan Intel CPU" dan contoh dari `preferredDuringSchedulingIgnoredDuringExecution` adalah "coba jalankan set pod ini dalam zona ketersediaan XYZ, tetapi jika tidak memungkinkan, maka biarkan beberapa pod berjalan di tempat lain".
|
||||
|
||||
Afinitas node dinyatakan sebagai _field_ `nodeAffinity` dari _field_ `affinity` pada PodSpec.
|
||||
|
||||
Berikut ini contoh dari pod yang menggunakan afinitas node:
|
||||
|
||||
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
|
||||
|
||||
Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan.
|
||||
|
||||
Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
|
||||
|
||||
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
|
||||
|
||||
Jika kamu menyatakan beberapa `nodeSelectorTerms` yang terkait dengan tipe `nodeAffinity`, maka pod akan dijadwalkan pada node **jika salah satu** dari `nodeSelectorTerms` dapat terpenuhi.
|
||||
|
||||
Jika kamu menyatakan beberapa `matchExpressions` yang terkait dengan `nodeSelectorTerms`, makan pod dapat dijadwalkan pada node **hanya jika semua** `matchExpressions` dapat terpenuhi.
|
||||
|
||||
Jika kamu menghapus atau mengubah label pada node tempat pod dijadwalkan, pod tidak akan dihapus. Dengan kata lain, pemilihan afinitas hanya bekerja pada saat waktu penjadwalan pod.
|
||||
|
||||
_Field_ `weight` pada `preferredDuringSchedulingIgnoredDuringExecution` berada pada rentang nilai 1-100. Untuk setiap node yang memenuhi semua persyaratan penjadwalan (permintaan sumber daya, pernyataan afinitas RequiredDuringScheduling, dll.), _scheduler_ akan menghitung nilai jumlah dengan melakukan iterasi pada elemen-elemen dari _field_ ini dan menambah "bobot" pada jumlah jika node cocok dengan MatchExpressions yang sesuai. Nilai ini kemudian digabungkan dengan nilai dari fungsi prioritas lain untuk node. Node dengan nilai tertinggi adalah node lebih diutamakan.
|
||||
|
||||
Untuk informasi lebih lanjut tentang afinitas node kamu dapat melihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md).
|
||||
|
||||
|
||||
### Afinitas and anti-afinitas antar pod (fitur beta)
|
||||
|
||||
Afinitas and anti-afinitas antar pod diperkenalkan pada Kubernetes 1.4. Afinitas and anti-afinitas antar pod memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod *berdasarkan label-label pada pod yang sudah berjalan pada node* daripada berdasarkan label-label pada node. Aturan tersebut berbentuk "pod ini harus (atau, dalam kasus
|
||||
anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels).
|
||||
|
||||
{{< note >}}
|
||||
Afinitas and anti-afinitas antar pod membutuhkan jumlah pemrosesan yang substansial yang dapat memperlambat penjadwalan pada kluster berukuran besar secara signifikan. Kami tidak merekomendasikan penggunaan mereka pada kluster yang berukuran lebih besar dari beberapa ratus node.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Anti-afinitas pod mengharuskan node untuk diberi label secara konsisten, misalnya setiap node dalam kluster harus memiliki label sesuai yang cocok dengan `topologyKey`. Jika sebagian atau semua node tidak memiliki label `topologyKey` yang dinyatakan, hal ini dapat menyebabkan perilaku yang tidak diinginkan.
|
||||
{{< /note >}}
|
||||
|
||||
Seperti afinitas node, ada dua tipe afinitas dan anti-afinitas pod, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan
|
||||
`preferredDuringSchedulingIgnoredDuringExecution` yang menunjukan persyaratan "kuat" vs. "lemah". Lihat deskripsi pada bagian afinitas node sebelumnya.
|
||||
Sebuah contoh dari afinitas `requiredDuringSchedulingIgnoredDuringExecution` adalah "Tempatkan bersamaan pod layanan A dan layanan B di zona yang sama, karena mereka banyak berkomunikasi satu sama lain"
|
||||
dan contoh `preferDuringSchedulingIgnoredDuringExecution` anti-afinitas akan menjadi "sebarkan pod dari layanan ini di seluruh zona" (persyaratan kuat tidak masuk akal, karena kamu mungkin memiliki lebih banyak pod daripada zona).
|
||||
|
||||
Afinitas antar pod dinyatakan sebagai _field_ `podAffinity` dari _field_ `affinity` pada PodSpec dan anti-afinitas antar pod dinyatakan sebagai _field_ `podAntiAffinity` dari _field_ `affinity` pada PodSpec.
|
||||
|
||||
#### Contoh pod yang menggunakan pod affinity:
|
||||
|
||||
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
|
||||
|
||||
Afinitas pada pod tersebut menetapkan sebuah aturan afinitas pod dan aturan anti-afinitas pod. Pada contoh ini, `podAffinity` adalah `requiredDuringSchedulingIgnoredDuringExecution`
|
||||
sementara `podAntiAffinity` adalah `preferredDuringSchedulingIgnoredDuringExecution`. Aturan afinitas pod menyatakan bahwa pod dapat dijadwalkan pada node hanya jika node tersebut berada pada zona yang sama dengan minimal satu pod yang sudah berjalan yang memiliki label dengan kunci "security" dan bernilai "S1". (Lebih detail, pod dapat berjalan pada node N jika node N memiliki label dengan kunci `failure-domain.beta.kubernetes.io/zone`dan nilai V sehingga ada minimal satu node dalam kluster dengan kunci `failure-domain.beta.kubernetes.io/zone` dan bernilai V yang menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S1".) Aturan anti-afinitas pod menyatakan bahwa pod memilih untuk tidak dijadwalkan pada sebuah node jika node tersebut sudah menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S2". (Jika `topologyKey` adalah `failure-domain.beta.kubernetes.io/zone` maka dapat diartikan bahwa pod tidak dapat dijadwalkan pada node jika node berada pada zona yang sama dengan pod yang memiliki label dengan kunci "security" dan bernilai "S2".) Lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) untuk lebih banyak contoh afinitas dan anti-afinitas pod, baik `requiredDuringSchedulingIgnoredDuringExecution`
|
||||
maupun `preferredDuringSchedulingIgnoredDuringExecution`.
|
||||
|
||||
Operator yang sah untuk afinitas dan anti-afinitas pod adalah `In`, `NotIn`, `Exists`, `DoesNotExist`.
|
||||
|
||||
Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`:
|
||||
|
||||
1. Untuk afinitas and anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, `topologyKey` tidak boleh kosong.
|
||||
2. Untuk anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, pengontrol penerimaan `LimitPodHardAntiAffinityTopology` diperkenalkan untuk membatasi `topologyKey` pada `kubernetes.io/hostname`. Jika kamu menginginkan untuk membuatnya tersedia untuk topologi khusus, kamu dapat memodifikasi pengontrol penerimaan, atau cukup menonaktifkannya saja.
|
||||
3. Untuk anti-afinitas pod `preferredDuringSchedulingIgnoredDuringExecution`, `topologyKey` yang kosong diinterpretasikan sebagai "semua topologi" ("semua topologi" sekarang dibatasi pada kombinasi dari `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` dan `failure-domain.beta.kubernetes.io/region`).
|
||||
4. Kecuali untuk kasus-kasus di atas, `topologyKey` dapat berupa label-kunci apapun yang sah.
|
||||
|
||||
Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`)
|
||||
|
||||
Jika dihilangkan atau kosong, daftar ini sesuai standar akan merujuk pada _namespace_ dari pod tempat definisi afinitas/anti-afinitas dinyatakan.
|
||||
|
||||
Semua `matchExpressions` berkaitan dengan afinitas and anti-afinitas `requiredDuringSchedulingIgnoredDuringExecution` harus dipenuhi agar pod dapat dijadwalkan pada node.
|
||||
|
||||
#### Penggunaan yang lebih praktikal
|
||||
|
||||
Afinitas and anti-afinitas antar pod dapat menjadi lebih berguna saat digunakan bersamaan dengan koleksi dengan level yang lebih tinggi seperti ReplicaSets, StatefulSets, Deployments, dll. Pengguna dapat dengan mudah mengkonfigurasi bahwa satu set workload harus
|
||||
ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama.
|
||||
|
||||
##### Selalu ditempatkan bersamaan pada node yang sama
|
||||
|
||||
Dalam kluster berisi 3 node, sebuah aplikasi web memiliki in-memory cache seperti redis. Kita menginginkan agar _web-server_ dari aplikasi ini sebisa mungkin ditempatkan bersamaan dengan cache.
|
||||
|
||||
Berikut ini kutipan yaml dari deployment redis sederhana dengan 3 replika dan label selector `app=store`, Deployment memiliki konfigurasi `PodAntiAffinity` untuk memastikan _scheduler_ tidak menempatkan replika bersamaan pada satu node.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: redis-cache
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: store
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: store
|
||||
spec:
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: app
|
||||
operator: In
|
||||
values:
|
||||
- store
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
containers:
|
||||
- name: redis-server
|
||||
image: redis:3.2-alpine
|
||||
```
|
||||
|
||||
Kutipan yaml dari deployment webserver berikut ini memiliki konfigurasi `podAntiAffinity` dan `podAffinity`. Konfigurasi ini menginformasikan scheduler bahwa semua replika harus ditempatkan bersamaan dengan pod yang memiliki label selector `app=store`. Konfigurasi ini juga memastikan bahwa setiap replika webserver tidak ditempatkan bersamaan pada satu node.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: web-server
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: web-store
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: web-store
|
||||
spec:
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: app
|
||||
operator: In
|
||||
values:
|
||||
- web-store
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
podAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: app
|
||||
operator: In
|
||||
values:
|
||||
- store
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
containers:
|
||||
- name: web-app
|
||||
image: nginx:1.12-alpine
|
||||
```
|
||||
|
||||
Jika kita membuat kedua dployment di atas, kluster berisi 3 node kita seharusnya menjadi seperti berikut.
|
||||
|
||||
| node-1 | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| *webserver-1* | *webserver-2* | *webserver-3* |
|
||||
| *cache-1* | *cache-2* | *cache-3* |
|
||||
|
||||
|
||||
st
|
||||
Seperti yang kamu lihat, semua 3 replika dari `web-server` secara otomatis ditempatkan bersama dengan cache seperti yang diharapkan.
|
||||
|
||||
```
|
||||
$ kubectl get pods -o wide
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
|
||||
redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1
|
||||
redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2
|
||||
web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1
|
||||
web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3
|
||||
web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
|
||||
```
|
||||
|
||||
##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama
|
||||
|
||||
|
||||
Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy kluster redis sehingga tidak ada dua instance terletak pada hos yang sama.
|
||||
Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
|
||||
|
||||
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
|
||||
|
||||
Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
|
||||
|
||||
## nodeName
|
||||
|
||||
`nodeName` adalah bentuk paling sederhana dari pembatasan pemilihan node, tetapi karena
|
||||
keterbatasannya biasanya tidak digunakan. `nodeName` adalah sebuah _field_ dari
|
||||
PodSpec. Jika tidak kosong, scheduler mengabaikan pod dan
|
||||
kubelet yang berjalan pada node tersebut yang mencoba menjalankan pod. Maka, jika
|
||||
`nodeName` disediakan dalam PodSpec, ia memiliki hak yang lebih tinggi dibanding metode-metode di atas untuk pemilihan node.
|
||||
|
||||
Beberapa keterbatasan dari penggunaan `nodeName` untuk memilih node adalah:
|
||||
|
||||
- Jika node yang disebut tidak ada, maka pod tidak akan dijalankan, dan dalam beberapa kasus akan
|
||||
dihapus secara otomatis.
|
||||
- Jika node yang disebut tidak memiliki resource yang cukup untuk mengakomodasi pod, pod akan gagal
|
||||
dan alasannya akan mengindikasikan sebab kegagalan, misalnya OutOfmemory atau OutOfcpu.
|
||||
- Nama node pada lingkungan cloud tidak selalu dapat diprediksi atau stabil.
|
||||
|
||||
Berikut ini contoh konfigurasi pod menggunakan _field_ `nodeName`:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
nodeName: kube-01
|
||||
```
|
||||
Pod di atas akan berjalan pada node kube-01.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
nodeSelector:
|
||||
disktype: ssd
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: with-node-affinity
|
||||
spec:
|
||||
affinity:
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: kubernetes.io/e2e-az-name
|
||||
operator: In
|
||||
values:
|
||||
- e2e-az1
|
||||
- e2e-az2
|
||||
preferredDuringSchedulingIgnoredDuringExecution:
|
||||
- weight: 1
|
||||
preference:
|
||||
matchExpressions:
|
||||
- key: another-node-label-key
|
||||
operator: In
|
||||
values:
|
||||
- another-node-label-value
|
||||
containers:
|
||||
- name: with-node-affinity
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: with-pod-affinity
|
||||
spec:
|
||||
affinity:
|
||||
podAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: security
|
||||
operator: In
|
||||
values:
|
||||
- S1
|
||||
topologyKey: failure-domain.beta.kubernetes.io/zone
|
||||
podAntiAffinity:
|
||||
preferredDuringSchedulingIgnoredDuringExecution:
|
||||
- weight: 100
|
||||
podAffinityTerm:
|
||||
labelSelector:
|
||||
matchExpressions:
|
||||
- key: security
|
||||
operator: In
|
||||
values:
|
||||
- S2
|
||||
topologyKey: failure-domain.beta.kubernetes.io/zone
|
||||
containers:
|
||||
- name: with-pod-affinity
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Serviceを利用したクラスター内のアプリケーションへのアクセス
|
||||
title: Serviceを利用したクラスター内のアプリケーションへのアクセス
|
||||
content_template: templates/tutorial
|
||||
weight: 60
|
||||
---
|
||||
|
|
@ -35,13 +35,13 @@ weight: 60
|
|||
1. クラスタでHello Worldアプリケーションを稼働させます:
|
||||
```shell
|
||||
kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080
|
||||
```
|
||||
```
|
||||
このコマンドは
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
オブジェクトとそれに紐付く
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
|
||||
オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの
|
||||
[Pod](/docs/concepts/workloads/pods/pod/)
|
||||
[Pod](/ja/docs/concepts/workloads/pods/pod/)
|
||||
から構成されます。
|
||||
|
||||
1. Deploymentの情報を表示します:
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Pod内で実行されているコンテナでシェルを実行します:
|
|||
ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。
|
||||
|
||||
Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。
|
||||
コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/docs/user-guide/pods/#termination-of-pods)を参照してください。
|
||||
コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#podの終了)を参照してください。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。
|
||||
|
|
@ -75,8 +75,8 @@ Kubernetesは、Podが *終了* したときにのみpreStopイベントを送
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
|
||||
* [Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)の詳細
|
||||
* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細
|
||||
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の詳細
|
||||
|
||||
|
||||
### 参照
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Podが長期間`Unknown`または`Terminating`の状態になっていること
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
[Init Containerのデバッグ](/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
|
||||
[Init Containerのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ kubectl delete pods -l app=myapp
|
|||
|
||||
### 永続ボリューム
|
||||
|
||||
StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
|
||||
StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#podの終了)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
|
||||
|
||||
{{< note >}}
|
||||
データを損失する可能性があるため、PVCを削除するときは注意してください。
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 30
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、[StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
このページでは、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
コントローラーを使用して、レプリカを持つステートフルアプリケーションを実行する方法を説明します。
|
||||
ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。
|
||||
|
||||
|
|
@ -21,8 +21,8 @@ weight: 30
|
|||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* {{< include "default-storage-class-prereqs.md" >}}
|
||||
* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/)
|
||||
と[StatefulSet](/docs/concepts/workloads/controllers/statefulset/)、
|
||||
さらには[Pod](/docs/concepts/workloads/pods/pod/)、
|
||||
と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、
|
||||
さらには[Pod](/ja/docs/concepts/workloads/pods/pod/)、
|
||||
[Service](/docs/concepts/services-networking/service/)、
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの
|
||||
他のコアな概念に精通していることを前提としています。
|
||||
|
|
@ -134,7 +134,7 @@ MySQLレプリケーションの起動を順序正しく実行します。
|
|||
### 構成を生成する
|
||||
|
||||
Podスペック内のコンテナを起動する前に、Podは最初に
|
||||
[初期化コンテナ](/docs/concepts/workloads/pods/init-containers/)を定義された順序で実行します。
|
||||
[初期化コンテナ](/ja/docs/concepts/workloads/pods/init-containers/)を定義された順序で実行します。
|
||||
|
||||
最初の初期化コンテナは`init-mysql`という名前で、序数インデックスに基づいて特別なMySQL設定ファイルを生成します。
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ ConfigMapから内容を`conf.d`にコピーすることによって適用しま
|
|||
このトポロジー例は単一のMySQLマスターと任意の数のスレーブで構成されているため、
|
||||
スクリプトは単に序数の`0`がマスターになるように、それ以外のすべてがスレーブになるように割り当てます。
|
||||
StatefulSetコントローラーによる
|
||||
[デプロイ順序の保証](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/)と組み合わせると、
|
||||
[デプロイ順序の保証](/ja/docs/concepts/workloads/controllers/statefulset/#デプロイとスケーリングの保証)と組み合わせると、
|
||||
スレーブが作成される前にMySQLマスターがReady状態になるため、スレーブはレプリケーションを開始できます。
|
||||
|
||||
### 既存データをクローンする
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ mysql>
|
|||
|
||||
* アプリケーションをスケールしないでください。このセットアップは単一レプリカのアプリケーション専用です。
|
||||
下層にあるPersistentVolumeは1つのPodにしかマウントできません。
|
||||
クラスター化されたステートフルアプリケーションについては、[StatefulSetのドキュメント](/docs/concepts/workloads/controllers/statefulset/)を参照してください。
|
||||
クラスター化されたステートフルアプリケーションについては、[StatefulSetのドキュメント](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。
|
||||
* Deploymentを定義するYAMLファイルでは`strategy: type: Recreate`を使用して下さい。
|
||||
この設定はKubernetesにローリングアップデートを使用 _しない_ ように指示します。
|
||||
同時に複数のPodを実行することはできないため、ローリングアップデートは使用できません。
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ weight: 50
|
|||
* StatefulSetはKubernetesバージョン1.5以降でのみ利用可能です。
|
||||
Kubernetesのバージョンを確認するには、`kubectl version`を実行してください。
|
||||
|
||||
* すべてのステートフルアプリケーションがうまくスケールできるわけではありません。StatefulSetがスケールするかどうかわからない場合は、[StatefulSetの概念](/docs/concepts/workloads/controllers/statefulset/)または[StatefulSetのチュートリアル](/docs/tutorials/stateful-application/basic-stateful-set/)を参照してください。
|
||||
* すべてのステートフルアプリケーションがうまくスケールできるわけではありません。StatefulSetがスケールするかどうかわからない場合は、[StatefulSetの概念](/ja/docs/concepts/workloads/controllers/statefulset/)または[StatefulSetのチュートリアル](/docs/tutorials/stateful-application/basic-stateful-set/)を参照してください。
|
||||
|
||||
* ステートフルアプリケーションクラスターが完全に健全であると確信できる場合にのみ、スケーリングを実行してください。
|
||||
|
||||
|
|
@ -75,6 +75,6 @@ spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断で
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [StatefulSetの削除](/docs/tasks/run-application/delete-stateful-set/)の詳細
|
||||
* [StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)の詳細
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Windowsに手動でMinikubeをダウンロードする場合、[`minikube-window
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Minikubeを使ってローカルでKubernetesを実行する](/docs/setup/minikube/)
|
||||
* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/minikube/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1063,7 +1063,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
|
|||
|
||||
#### 디플로이먼트 재생성
|
||||
|
||||
기존의 모든 파드는 `.spec.strategy.type==Recreate` 일면 새 파드가 생성되기 전에 죽는다.
|
||||
기존의 모든 파드는 `.spec.strategy.type==Recreate` 이면 새 파드가 생성되기 전에 죽는다.
|
||||
|
||||
#### 디플로이먼트 롤링 업데이트
|
||||
|
||||
|
|
|
|||
|
|
@ -11,12 +11,13 @@
|
|||
{{ partial "docs/top-menu.html" . }}
|
||||
</section>
|
||||
{{ end }}
|
||||
{{ block "announcement" . }}{{ partial "announcement.html" . }}{{ end }}
|
||||
{{ block "deprecation" . }}{{ partial "deprecation-warning.html" . }}{{ end }}
|
||||
<section id="encyclopedia">
|
||||
{{ block "side-menu" . }}<div id="docsToc" style="display:none;"></div>{{ end }}
|
||||
<div id="{{ block "content-id" . }}docsContent{{ end }}">
|
||||
{{ block "content" . }}{{ end }}
|
||||
|
||||
|
||||
{{ partial "feedback.html" . }}
|
||||
|
||||
{{ partial "git-info.html" . }}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
{{ if .Param "announcement"}}
|
||||
<section id="announcement">
|
||||
<main>
|
||||
<div class="content announcement">
|
||||
<h3>
|
||||
{{ .Param "announcement_message" | markdownify }}
|
||||
</h3>
|
||||
</div>
|
||||
</main>
|
||||
</section>
|
||||
{{ end }}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
{{ if .Page.Param "announcement" }}
|
||||
<section id="announcement">
|
||||
<main>
|
||||
<div class="content announcement">
|
||||
<h3>
|
||||
{{ .Page.Param "announcement_message" | markdownify }}
|
||||
</h3>
|
||||
</div>
|
||||
</main>
|
||||
</section>
|
||||
{{ end }}
|
||||
|
|
@ -5,6 +5,9 @@
|
|||
- `test_examples.sh`: This script tests whether a change affects example files bundled in the website.
|
||||
- `check-headers-file.sh`: This script checks the headers if you are in a production environment.
|
||||
- `hugo-version-check.sh`: This script checks whether your local Hugo version matches the version used in production.
|
||||
- `diff_l10n_branches.py`: This script generates a report of outdated contents in `content/<l10n-lang>` directory
|
||||
by comparing two l10n team milestone branches.
|
||||
|
||||
|
||||
## Requirements
|
||||
|
||||
|
|
@ -71,3 +74,22 @@ This script checks the headers if you are in a production environment.
|
|||
This script checks whether your local Hugo version matches the version used in production.
|
||||
|
||||
./scripts/hugo-version-check.sh
|
||||
|
||||
## diff_l10n_branches.py
|
||||
|
||||
```
|
||||
$ scripts/diff_l10n_branches.py --help
|
||||
Usage: diff_l10n_branches.py [OPTIONS] L10N_LANG L_COMMIT R_COMMIT
|
||||
|
||||
This script generates a report of outdated contents in `content/<l10n-
|
||||
lang>` directory by comparing two l10n team milestone branches.
|
||||
|
||||
L10n team owners can open a GitHub issue with the report generated by this
|
||||
script when they start a new team milestone.
|
||||
|
||||
ex: `scripts/diff_l10n_branches.py ko dev-1.15-ko.3 dev-1.15-ko.4`
|
||||
|
||||
Options:
|
||||
--src-lang TEXT Source language
|
||||
--help Show this message and exit.
|
||||
```
|
||||
|
|
|
|||
|
|
@ -0,0 +1,137 @@
|
|||
#!/usr/bin/env python
|
||||
|
||||
import os
|
||||
import subprocess
|
||||
import jinja2
|
||||
import click
|
||||
|
||||
DEVNULL = open(os.devnull, 'w')
|
||||
ISSUE_TEMPLATE = """\
|
||||
# This is a Bug Report
|
||||
## Problem
|
||||
Outdated files in the {{ r_commit }} branch.
|
||||
|
||||
### {{ files_to_be_modified | count }} files to be modified
|
||||
{% for m_file in files_to_be_modified -%}
|
||||
1. [ ] {{ m_file.filepath }} {{ m_file.shortstat }}
|
||||
{% endfor %}
|
||||
|
||||
### {{ files_to_be_renamed | count }} files to be renamed
|
||||
{% for r_file in files_to_be_renamed -%}
|
||||
1. [ ] {{ r_file.diff_status_letter }} {{ r_file.src_filepath }} -> {{ r_file.dest_filepath }}
|
||||
{% endfor %}
|
||||
|
||||
### {{ files_to_be_deleted | count }} files to be deleted
|
||||
{% for d_file in files_to_be_deleted -%}
|
||||
1. [ ] {{ d_file }}
|
||||
{% endfor %}
|
||||
|
||||
## Proposed Solution
|
||||
|
||||
{% if files_to_be_modified %}
|
||||
|
||||
Use `git diff` to check what is changed in the upstream. And apply the upstream changes manually
|
||||
to the `{{ l10n_lang_path }}` of `{{ r_commit }}` branch.
|
||||
|
||||
For example:
|
||||
```
|
||||
# checkout `{{ r_commit }}`
|
||||
...
|
||||
# check what is updated in the upstream
|
||||
git diff {{ l_commit }} {{ r_commit }} -- {{ files_to_be_modified.0.filepath }}
|
||||
# apply changes to content/ko
|
||||
vi {{ files_to_be_modified.0.filepath | replace(src_lang_path, l10n_lang_path) }}
|
||||
...
|
||||
# commit and push
|
||||
...
|
||||
# make PR to `{{ r_commit }}`
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Pages to Update
|
||||
|
||||
"""
|
||||
|
||||
files_to_be_deleted = []
|
||||
files_to_be_renamed = []
|
||||
files_to_be_modified = []
|
||||
|
||||
|
||||
def git_diff(filepath, l_commit, r_commit, shortstat=False):
|
||||
cmd = ["git", "diff", l_commit, r_commit, "--", filepath]
|
||||
|
||||
if shortstat:
|
||||
cmd = ["git", "diff", l_commit, r_commit, "--shortstat", "--", filepath]
|
||||
|
||||
return subprocess.check_output(cmd).decode("UTF-8").strip()
|
||||
|
||||
|
||||
def git_exists(path, filepath):
|
||||
cmd = ["git", "cat-file", "-e", "{}:{}".format(path, filepath)]
|
||||
ret_code = subprocess.call(cmd, stderr=DEVNULL)
|
||||
return ret_code == 0
|
||||
|
||||
|
||||
def process_diff_status(diff_status, l_commit, r_commit, src_lang_path,
|
||||
l10n_lang_path):
|
||||
status_letter = diff_status[0]
|
||||
filepath = diff_status[1]
|
||||
|
||||
if git_exists(r_commit, filepath.replace(src_lang_path, l10n_lang_path)):
|
||||
if status_letter == 'D':
|
||||
files_to_be_deleted.append(filepath)
|
||||
elif status_letter.startswith('R'):
|
||||
replaced = {"diff_status_letter": diff_status[0],
|
||||
"src_filepath": diff_status[1],
|
||||
"dest_filepath": diff_status[2]}
|
||||
files_to_be_renamed.append(replaced)
|
||||
elif status_letter == 'M':
|
||||
modified = {"filepath": filepath,
|
||||
"shortstat": git_diff(filepath, l_commit, r_commit,
|
||||
shortstat=True),
|
||||
"diff": git_diff(filepath, l_commit, r_commit)}
|
||||
files_to_be_modified.append(modified)
|
||||
|
||||
|
||||
def git_diff_name_status(l_commit, r_commit, src_lang_path, l10n_lang_path):
|
||||
cmd = ["git", "diff", l_commit, r_commit, "--name-status", "--",
|
||||
src_lang_path]
|
||||
name_status_output = subprocess.check_output(cmd).strip()
|
||||
for line in name_status_output.decode('utf-8').splitlines():
|
||||
diff_status = line.split()
|
||||
process_diff_status(diff_status, l_commit, r_commit, src_lang_path,
|
||||
l10n_lang_path)
|
||||
|
||||
|
||||
@click.command()
|
||||
@click.argument("l10n-lang")
|
||||
@click.argument("l-commit")
|
||||
@click.argument("r-commit")
|
||||
@click.option("--src-lang", help="Source language", default="en")
|
||||
def main(l10n_lang, src_lang, l_commit, r_commit):
|
||||
"""
|
||||
This script generates a report of outdated contents in `content/<l10n-lang>`
|
||||
directory by comparing two l10n team milestone branches.
|
||||
|
||||
L10n team owners can open a GitHub issue with the report generated by this
|
||||
script when they start a new team milestone.
|
||||
|
||||
ex: `scripts/diff_l10n_branches.py ko dev-1.15-ko.3 dev-1.15-ko.4`
|
||||
"""
|
||||
l10n_lang_path = "content/" + l10n_lang
|
||||
src_lang_path = "content/" + src_lang
|
||||
git_diff_name_status(l_commit, r_commit, src_lang_path,
|
||||
l10n_lang_path)
|
||||
issue_template = jinja2.Template(ISSUE_TEMPLATE)
|
||||
ret = issue_template.render(l_commit=l_commit, r_commit=r_commit,
|
||||
src_lang_path=src_lang_path,
|
||||
l10n_lang_path=l10n_lang_path,
|
||||
files_to_be_deleted=files_to_be_deleted,
|
||||
files_to_be_modified=files_to_be_modified,
|
||||
files_to_be_renamed=files_to_be_renamed)
|
||||
print(ret)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
.announcement {
|
||||
padding: 20px;
|
||||
margin: 20px 0;
|
||||
border-radius: 3px;
|
||||
background-color: #eeeeee;
|
||||
}
|
||||
|
|
@ -55697,7 +55697,7 @@ $ curl -X GET 'http://127.0.0.1:8001/apis/extensions/v1beta1/watch/namespaces/de
|
|||
</DIV>
|
||||
<SCRIPT src="/js/jquery-3.2.1.min.js"></SCRIPT>
|
||||
<SCRIPT src="jquery.scrollTo.min.js"></SCRIPT>
|
||||
<SCRIPT src="/js/bootstrap-3.3.7.min.js"></SCRIPT>
|
||||
<SCRIPT src="/js/bootstrap-4.3.1.min.js"></SCRIPT>
|
||||
<SCRIPT src="navData.js"></SCRIPT>
|
||||
<SCRIPT src="scroll.js"></SCRIPT>
|
||||
</BODY>
|
||||
|
|
|
|||
Loading…
Reference in New Issue