Merge branch 'main' into patch-9
ixodie
GitHub
commit
46fc61cd04
|
|
@ -123,6 +123,7 @@ id = "UA-00000000-0"
|
|||
[params]
|
||||
copyright_k8s = "The Kubernetes Authors"
|
||||
copyright_linux = "Copyright © 2020 The Linux Foundation ®."
|
||||
|
||||
# privacy_policy = "https://policies.google.com/privacy"
|
||||
|
||||
# First one is picked as the Twitter card image if not set on page.
|
||||
|
|
|
|||
|
|
@ -260,12 +260,6 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p
|
|||
|
||||
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
|
||||
### Nuage Networks VCS (Virtualized Cloud Services)
|
||||
|
||||
[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
|
||||
### OVN (Open Virtual Networking)
|
||||
|
||||
OVN is an opensource network virtualization solution developed by the
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@ weight: 30
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes supports multiple virtual clusters backed by the same physical cluster.
|
||||
These virtual clusters are called namespaces.
|
||||
In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -48,6 +48,21 @@ with shared namespaces and shared filesystem volumes.
|
|||
|
||||
## Using Pods
|
||||
|
||||
The following is an example of a Pod which consists of a container running the image `nginx:1.14.2`.
|
||||
|
||||
{{< codenew file="pods/simple-pod.yaml" >}}
|
||||
|
||||
To create the Pod shown above, run the following command:
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
|
||||
```
|
||||
|
||||
Pods are generally not created directly and are created using workload resources.
|
||||
See [Working with Pods](#working-with-pods) for more information on how Pods are used
|
||||
with workload resources.
|
||||
|
||||
### Workload resources for managing pods
|
||||
|
||||
Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
|
||||
term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
|
||||
If your Pods need to track state, consider the
|
||||
|
|
|
|||
|
|
@ -29,6 +29,8 @@ Kubernetes documentation contributors:
|
|||
- Translate the documentation
|
||||
- Manage and publish the documentation parts of the Kubernetes release cycle
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Getting started
|
||||
|
|
@ -44,18 +46,98 @@ to work effectively in the Kubernetes community.
|
|||
To get involved with documentation:
|
||||
|
||||
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
|
||||
1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
|
||||
2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
|
||||
and the website's [static site generator](https://gohugo.io).
|
||||
1. Make sure you understand the basic processes for
|
||||
3. Make sure you understand the basic processes for
|
||||
[opening a pull request](/docs/contribute/new-content/open-a-pr/) and
|
||||
[reviewing changes](/docs/contribute/review/reviewing-prs/).
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart TB
|
||||
subgraph third[Open PR]
|
||||
direction TB
|
||||
U[ ] -.-
|
||||
Q[Improve content] --- N[Create content]
|
||||
N --- O[Translate docs]
|
||||
O --- P[Manage/publish docs parts<br>of K8s release cycle]
|
||||
|
||||
end
|
||||
|
||||
subgraph second[Review]
|
||||
direction TB
|
||||
T[ ] -.-
|
||||
D[Look over the<br>K8s/website<br>repository] --- E[Check out the<br>Hugo static site<br>generator]
|
||||
E --- F[Understand basic<br>GitHub commands]
|
||||
F --- G[Review open PR<br>and change review <br>processes]
|
||||
end
|
||||
|
||||
subgraph first[Sign up]
|
||||
direction TB
|
||||
S[ ] -.-
|
||||
B[Sign the CNCF<br>Contributor<br>License Agreement] --- C[Join sig-docs<br>Slack channel]
|
||||
C --- V[Join kubernetes-sig-docs<br>mailing list]
|
||||
V --- M[Attend weekly<br>sig-docs calls<br>or slack meetings]
|
||||
end
|
||||
|
||||
A([fa:fa-user New<br>Contributor]) --> first
|
||||
A --> second
|
||||
A --> third
|
||||
A --> H[Ask Questions!!!]
|
||||
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
|
||||
class S,T,U spacewhite
|
||||
class first,second,third white
|
||||
{{</ mermaid >}}
|
||||
***Figure - Getting started for a new contributor***
|
||||
|
||||
The figure above outlines a roadmap for new contributors. You can follow some or all of the steps for `Sign up` and `Review`. Now you are ready to open PRs that achieve your contribution objectives with some listed under `Open PR`. Again, questions are always welcome!
|
||||
|
||||
Some tasks require more trust and more access in the Kubernetes organization.
|
||||
See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
|
||||
roles and permissions.
|
||||
|
||||
## Your first contribution
|
||||
|
||||
You can prepare for your first contribution by reviewing several steps beforehand. The figure below outlines the steps and the details follow.
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
subgraph second[First Contribution]
|
||||
direction TB
|
||||
S[ ] -.-
|
||||
G[Review PRs from other<br>K8s members] -->
|
||||
A[Check K8s/website<br>issues list for<br>good first PRs] --> B[Open a PR!!]
|
||||
end
|
||||
subgraph first[Suggested Prep]
|
||||
direction TB
|
||||
T[ ] -.-
|
||||
D[Read contribution overview] -->E[Read K8s content<br>and style guides]
|
||||
E --> F[Learn about Hugo page<br>content types<br>and shortcodes]
|
||||
end
|
||||
|
||||
|
||||
first ----> second
|
||||
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class A,B,D,E,F,G grey
|
||||
class S,T spacewhite
|
||||
class first,second white
|
||||
{{</ mermaid >}}
|
||||
***Figure - Preparation for your first contribution***
|
||||
|
||||
- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
|
||||
learn about the different ways you can contribute.
|
||||
- Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/)
|
||||
|
|
@ -92,10 +174,12 @@ SIG Docs communicates with different methods:
|
|||
introduce yourself!
|
||||
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
|
||||
where broader discussions take place and official decisions are recorded.
|
||||
- Join the [weekly SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs). Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
|
||||
- Join the [SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs) held every two weeks. Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
|
||||
- Join the SIG Docs async Slack standup meeting on those weeks when the in-person Zoom video meeting does not take place. Meetings are always announced on `#sig-docs`. You can contribute to any one of the threads up to 24 hours after meeting announcement.
|
||||
|
||||
## Other ways to contribute
|
||||
|
||||
- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
|
||||
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
|
||||
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
|
||||
|
||||
|
|
|
|||
|
|
@ -5,10 +5,48 @@ main_menu: true
|
|||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This section contains information you should know before contributing new content.
|
||||
This section contains information you should know before contributing new
|
||||
content.
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
subgraph second[Before you begin]
|
||||
direction TB
|
||||
S[ ] -.-
|
||||
A[Sign the CNCF CLA] --> B[Choose Git branch]
|
||||
B --> C[One language per PR]
|
||||
C --> F[Check out<br>contributor tools]
|
||||
end
|
||||
subgraph first[Contributing Basics]
|
||||
direction TB
|
||||
T[ ] -.-
|
||||
D[Write docs in markdown<br>and build site with Hugo] --- E[source in GitHub]
|
||||
E --- G[_'/content/../docs'_ folder contains docs<br>for multiple languages]
|
||||
G --- H[Review Hugo page content<br>types and shortcodes]
|
||||
end
|
||||
|
||||
|
||||
first ----> second
|
||||
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class A,B,C,D,E,F,G,H grey
|
||||
class S,T spacewhite
|
||||
class first,second white
|
||||
{{</ mermaid >}}
|
||||
|
||||
***Figure - Contributing new content preparation***
|
||||
|
||||
The figure above depicts the information you should know
|
||||
prior to submitting new content. The information details follow.
|
||||
|
||||
|
||||
|
||||
|
|
@ -16,28 +54,43 @@ This section contains information you should know before contributing new conten
|
|||
|
||||
## Contributing basics
|
||||
|
||||
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
|
||||
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
|
||||
- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
|
||||
- Write Kubernetes documentation in Markdown and build the Kubernetes site
|
||||
using [Hugo](https://gohugo.io/).
|
||||
- The source is in [GitHub](https://github.com/kubernetes/website). You can find
|
||||
Kubernetes documentation at `/content/en/docs/`. Some of the reference
|
||||
documentation is automatically generated from scripts in
|
||||
the `update-imported-docs/` directory.
|
||||
- [Page content types](/docs/contribute/style/page-content-types/) describe the
|
||||
presentation of documentation content in Hugo.
|
||||
- In addition to the standard Hugo shortcodes, we use a number of
|
||||
[custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
|
||||
[custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our
|
||||
documentation to control the presentation of content.
|
||||
- Documentation source is available in multiple languages in `/content/`. Each
|
||||
language has its own folder with a two-letter code determined by the
|
||||
[ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
|
||||
example, English documentation source is stored in `/content/en/docs/`.
|
||||
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
|
||||
[ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php)
|
||||
. For example, English documentation source is stored in `/content/en/docs/`.
|
||||
- For more information about contributing to documentation in multiple languages
|
||||
or starting a new translation,
|
||||
see [localization](/docs/contribute/localization).
|
||||
|
||||
## Before you begin {#before-you-begin}
|
||||
|
||||
### Sign the CNCF CLA {#sign-the-cla}
|
||||
|
||||
All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
|
||||
All Kubernetes contributors **must** read
|
||||
the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
|
||||
and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md)
|
||||
.
|
||||
|
||||
Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
|
||||
Pull requests from contributors who haven't signed the CLA fail the automated
|
||||
tests. The name and email you provide must match those found in
|
||||
your `git config`, and your git name and email must match those used for the
|
||||
CNCF CLA.
|
||||
|
||||
### Choose which Git branch to use
|
||||
|
||||
When opening a pull request, you need to know in advance which branch to base your work on.
|
||||
When opening a pull request, you need to know in advance which branch to base
|
||||
your work on.
|
||||
|
||||
Scenario | Branch
|
||||
:---------|:------------
|
||||
|
|
@ -45,20 +98,21 @@ Existing or new English language content for the current release | `main`
|
|||
Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
|
||||
Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
|
||||
|
||||
|
||||
If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
|
||||
|
||||
{{< note >}}
|
||||
If you already submitted your pull request and you know that the base branch
|
||||
was wrong, you (and only you, the submitter) can change it.
|
||||
{{< /note >}}
|
||||
{{< note >}} If you already submitted your pull request and you know that the
|
||||
base branch was wrong, you (and only you, the submitter) can change it. {{<
|
||||
/note >}}
|
||||
|
||||
### Languages per PR
|
||||
|
||||
Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
|
||||
Limit pull requests to one language per PR. If you need to make an identical
|
||||
change to the same code sample in multiple languages, open a separate PR for
|
||||
each language.
|
||||
|
||||
## Tools for contributors
|
||||
|
||||
The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
|
||||
|
||||
The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
|
||||
directory in the `kubernetes/website` repository contains tools to help your
|
||||
contribution journey go more smoothly.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,40 @@ If your changes are large, read [Work from a local fork](#fork-the-repo) to lear
|
|||
## Changes using GitHub
|
||||
|
||||
If you're less experienced with git workflows, here's an easier method of
|
||||
opening a pull request.
|
||||
opening a pull request. The figure below outlines the steps and the details follow.
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
A([fa:fa-user New<br>Contributor]) --- id1[(K8s/Website<br>GitHub)]
|
||||
subgraph tasks[Changes using GitHub]
|
||||
direction TB
|
||||
0[ ] -.-
|
||||
1[1. Edit this page] --> 2[2. Use GitHub markdown<br>editor to make changes]
|
||||
2 --> 3[3. fill in Propose file change]
|
||||
|
||||
end
|
||||
subgraph tasks2[ ]
|
||||
direction TB
|
||||
4[4. select Propose file change] --> 5[5. select Create pull request] --> 6[6. fill in Open a pull request]
|
||||
6 --> 7[7. select Create pull request]
|
||||
end
|
||||
|
||||
id1 --> tasks --> tasks2
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class A,1,2,3,4,5,6,7 grey
|
||||
class 0 spacewhite
|
||||
class tasks,tasks2 white
|
||||
class id1 k8s
|
||||
{{</ mermaid >}}
|
||||
|
||||
***Figure - Steps for opening a PR using GitHub***
|
||||
|
||||
1. On the page where you see the issue, select the pencil icon at the top right.
|
||||
You can also scroll to the bottom of the page and select **Edit this page**.
|
||||
|
|
@ -89,6 +122,37 @@ work from a local fork.
|
|||
|
||||
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
|
||||
|
||||
The figure below shows the steps to follow when you work from a local fork. The details for each step follow.
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
1[Fork the K8s/website<br>repository] --> 2[Create local clone<br>and set upstream]
|
||||
subgraph changes[Your changes]
|
||||
direction TB
|
||||
S[ ] -.-
|
||||
3[Create a branch<br>example: my_new_branch] --> 3a[Make changes using<br>text editor] --> 4["Preview your changes<br>locally using Hugo<br>(localhost:1313)<br>or build container image"]
|
||||
end
|
||||
subgraph changes2[Commit / Push]
|
||||
direction TB
|
||||
T[ ] -.-
|
||||
5[Commit your changes] --> 6[Push commit to<br>origin/my_new_branch]
|
||||
end
|
||||
|
||||
2 --> changes --> changes2
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class 1,2,3,3a,4,5,6 grey
|
||||
class S,T spacewhite
|
||||
class changes,changes2 white
|
||||
{{</ mermaid >}}
|
||||
***Figure - Working from a local fork to make your changes***
|
||||
|
||||
### Fork the kubernetes/website repository
|
||||
|
||||
1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
|
||||
|
|
@ -289,6 +353,34 @@ Alternately, install and use the `hugo` command on your computer:
|
|||
|
||||
### Open a pull request from your fork to kubernetes/website {#open-a-pr}
|
||||
|
||||
The figure below shows the steps to open a PR from your fork to the K8s/website. The details follow.
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
subgraph first[ ]
|
||||
direction TB
|
||||
1[1. Go to K8s/website repository] --> 2[2. Select New Pull Request]
|
||||
2 --> 3[3. Select compare across forks]
|
||||
3 --> 4[4. Select your fork from<br>head repository drop-down menu]
|
||||
end
|
||||
subgraph second [ ]
|
||||
direction TB
|
||||
5[5. Select your branch from<br>the compare drop-down menu] --> 6[6. Select Create Pull Request]
|
||||
6 --> 7[7. Add a description<br>to your PR]
|
||||
7 --> 8[8. Select Create pull request]
|
||||
end
|
||||
|
||||
first --> second
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
class 1,2,3,4,5,6,7,8 grey
|
||||
class first,second white
|
||||
{{</ mermaid >}}
|
||||
***Figure - Steps to open a PR from your fork to the K8s/website***
|
||||
|
||||
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
|
||||
2. Select **New Pull Request**.
|
||||
3. Select **compare across forks**.
|
||||
|
|
@ -303,7 +395,7 @@ Alternately, install and use the `hugo` command on your computer:
|
|||
|
||||
8. Select the **Create pull request** button.
|
||||
|
||||
Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
|
||||
Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
|
||||
|
||||
|
||||
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
|
||||
|
|
@ -414,7 +506,6 @@ If another contributor commits changes to the same file in another PR, it can cr
|
|||
|
||||
The pull request no longer shows any conflicts.
|
||||
|
||||
|
||||
### Squashing commits
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -500,11 +591,8 @@ Most repositories use issue and PR templates. Have a look through some open
|
|||
issues and PRs to get a feel for that team's processes. Make sure to fill out
|
||||
the templates with as much detail as possible when you file issues or PRs.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,38 @@ Before you start a review:
|
|||
|
||||
## Review process
|
||||
|
||||
In general, review pull requests for content and style in English.
|
||||
In general, review pull requests for content and style in English. The figure below outlines the steps for the review process. The details for each step follow.
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
subgraph fourth[Start review]
|
||||
direction TB
|
||||
S[ ] -.-
|
||||
M[add comments] --> N[review changes]
|
||||
N --> O[new contributors should<br>choose Comment]
|
||||
end
|
||||
subgraph third[Select PR]
|
||||
direction TB
|
||||
T[ ] -.-
|
||||
J[read description<br>and comments]--> K[preview changes in<br>Netlify preview build]
|
||||
end
|
||||
|
||||
A[Review open PR list]--> B[Filter open PRs<br>by label]
|
||||
B --> third --> fourth
|
||||
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class A,B,J,K,M,N,O grey
|
||||
class S,T spacewhite
|
||||
class third,fourth white
|
||||
{{</ mermaid >}}
|
||||
|
||||
***Figure - Review process steps***
|
||||
|
||||
1. Go to
|
||||
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
|
||||
|
|
|
|||
|
|
@ -134,6 +134,21 @@ The output is similar to this:
|
|||
no
|
||||
```
|
||||
|
||||
Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
|
||||
can list Pods in the Namespace `target`:
|
||||
|
||||
```bash
|
||||
kubectl auth can-i list pods \
|
||||
--namespace target \
|
||||
--as system:serviceaccount:dev:dev-sa
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
|
||||
`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
|
||||
exposes the API server authorization to external services. Other resources in
|
||||
this group include:
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ aka:
|
|||
tags:
|
||||
- fundamental
|
||||
---
|
||||
An abstraction used by Kubernetes to support multiple virtual clusters on the same physical {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
|
||||
An abstraction used by Kubernetes to support isolation of groups of resources within a single {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.
|
||||
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ behind one command, with support for both planning an upgrade and actually perfo
|
|||
|
||||
## kubeadm upgrade guidance
|
||||
|
||||
The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
The steps for performing an upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.
|
||||
|
||||
You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests.
|
||||
|
|
|
|||
|
|
@ -325,6 +325,10 @@ Here is an example:
|
|||
```shell
|
||||
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
|
||||
```
|
||||
Another example for restoring using etcdutl options:
|
||||
```shell
|
||||
ETCDCTL_API=3 etcdutl --data-dir <data-dir-location> snapshot restore snapshotdb
|
||||
```
|
||||
|
||||
For more information and examples on restoring a cluster from a snapshot file, see
|
||||
[etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).
|
||||
|
|
|
|||
|
|
@ -27,8 +27,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo
|
|||
* [Enable systemd with user session](https://rootlesscontaine.rs/getting-started/common/login/)
|
||||
* [Configure several sysctl values, depending on host Linux distribution](https://rootlesscontaine.rs/getting-started/common/sysctl/)
|
||||
* [Ensure that your unprivileged user is listed in `/etc/subuid` and `/etc/subgid`](https://rootlesscontaine.rs/getting-started/common/subuid/)
|
||||
|
||||
* `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
* Enable the `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -86,9 +85,10 @@ Rootless Docker/Podman or LXC/LXD, you are all set, and you can go to the next s
|
|||
Otherwise you have to create a user namespace by yourself, by calling `unshare(2)` with `CLONE_NEWUSER`.
|
||||
|
||||
A user namespace can be also unshared by using command line tools such as:
|
||||
|
||||
- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
|
||||
- [RootlessKit](https://github.com/rootless-containers/rootlesskit)
|
||||
- [become-root](https://github.com/giuseppe/become-root)
|
||||
- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
|
||||
|
||||
After unsharing the user namespace, you will also have to unshare other namespaces such as mount namespace.
|
||||
|
||||
|
|
@ -123,29 +123,37 @@ On your node, systemd must already be configured to allow delegation; for more d
|
|||
Containers documentation.
|
||||
|
||||
### Configuring network
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
The network namespace of the Node components has to have a non-loopback interface, which can be for example configured with
|
||||
slirp4netns, VPNKit, or lxc-user-nic.
|
||||
[slirp4netns](https://github.com/rootless-containers/slirp4netns),
|
||||
[VPNKit](https://github.com/moby/vpnkit), or
|
||||
[lxc-user-nic(1)](https://www.man7.org/linux/man-pages/man1/lxc-user-nic.1.html).
|
||||
|
||||
The network namespaces of the Pods can be configured with regular CNI plugins.
|
||||
For multi-node networking, Flannel (VXLAN, 8472/UDP) is known to work.
|
||||
|
||||
Ports such as the kubelet port (10250/TCP) and `NodePort` service ports have to be exposed from the Node network namespace to
|
||||
the host with an external port forwarder, such as RootlessKit, slirp4netns, or socat.
|
||||
the host with an external port forwarder, such as RootlessKit, slirp4netns, or
|
||||
[socat(1)](https://linux.die.net/man/1/socat).
|
||||
|
||||
You can use the port forwarder from K3s; see https://github.com/k3s-io/k3s/blob/v1.21.2+k3s1/pkg/rootlessports/controller.go
|
||||
You can use the port forwarder from K3s.
|
||||
See [Running K3s in Rootless Mode](https://rancher.com/docs/k3s/latest/en/advanced/#known-issues-with-rootless-mode)
|
||||
for more details.
|
||||
|
||||
### Configuring CRI
|
||||
|
||||
The kubelet relies on a container runtime. You should deploy a container runtime such as containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
|
||||
The kubelet relies on a container runtime. You should deploy a container runtime such as
|
||||
containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
|
||||
|
||||
{{< tabs name="cri" >}}
|
||||
{{% tab name="containerd" %}}
|
||||
|
||||
Running CRI plugin of containerd in a user namespace is supported since containerd 1.4.
|
||||
|
||||
Running containerd within a user namespace requires the following configuration:
|
||||
Running containerd within a user namespace requires the following configurations
|
||||
in `/etc/containerd/containerd-config.toml`.
|
||||
|
||||
```toml
|
||||
version = 2
|
||||
|
|
@ -175,7 +183,7 @@ Running CRI-O in a user namespace is supported since CRI-O 1.22.
|
|||
|
||||
CRI-O requires an environment variable `_CRIO_ROOTLESS=1` to be set.
|
||||
|
||||
The following configuration is also recommended:
|
||||
The following configurations (in `/etc/crio/crio.conf`) are also recommended:
|
||||
|
||||
```toml
|
||||
[crio]
|
||||
|
|
@ -197,8 +205,8 @@ The following configuration is also recommended:
|
|||
Running kubelet in a user namespace requires the following configuration:
|
||||
|
||||
```yaml
|
||||
kind: KubeletConfiguration
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
featureGates:
|
||||
KubeletInUserNamespace: true
|
||||
# We use cgroupfs that is delegated by systemd, so we do not use "systemd" driver
|
||||
|
|
@ -206,22 +214,23 @@ featureGates:
|
|||
cgroupDriver: "cgroupfs"
|
||||
```
|
||||
|
||||
When the `KubeletInUserNamespace` feature gate is enabled, kubelet ignores errors that may happen during setting the following sysctl values:
|
||||
When the `KubeletInUserNamespace` feature gate is enabled, the kubelet ignores errors
|
||||
that may happen during setting the following sysctl values on the node.
|
||||
|
||||
- `vm.overcommit_memory`
|
||||
- `vm.panic_on_oom`
|
||||
- `kernel.panic`
|
||||
- `kernel.panic_on_oops`
|
||||
- `kernel.keys.root_maxkeys`
|
||||
- `kernel.keys.root_maxbytes`.
|
||||
(these are sysctl values for the host, not for the containers).
|
||||
|
||||
Within a user namespace, the kubelet also ignores any error raised from trying to open `/dev/kmsg`.
|
||||
This feature gate also allows kube-proxy to ignore an error during setting `RLIMIT_NOFILE`.
|
||||
|
||||
The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.
|
||||
|
||||
Running kubelet in a user namespace without using this feature gate is also possible by mounting a specially crafted proc filesystem,
|
||||
but not officially supported.
|
||||
Running kubelet in a user namespace without using this feature gate is also possible
|
||||
by mounting a specially crafted proc filesystem, but not officially supported.
|
||||
|
||||
### Configuring kube-proxy
|
||||
|
||||
|
|
@ -251,9 +260,11 @@ For more on this, see the [Caveats and Future work](https://rootlesscontaine.rs/
|
|||
on the rootlesscontaine.rs website.
|
||||
|
||||
## {{% heading "seealso" %}}
|
||||
|
||||
- [rootlesscontaine.rs](https://rootlesscontaine.rs/)
|
||||
- [Rootless Containers 2020 (KubeCon NA 2020)](https://www.slideshare.net/AkihiroSuda/kubecon-na-2020-containerd-rootless-containers-2020)
|
||||
- [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/)
|
||||
- [Usernetes](https://github.com/rootless-containers/usernetes)
|
||||
- [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
|
||||
- [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless)
|
||||
|
||||
|
|
|
|||
|
|
@ -329,6 +329,9 @@ spec:
|
|||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
volumeMounts:
|
||||
- name: ephemeral
|
||||
mountPath: "/tmp"
|
||||
- name: log-aggregator
|
||||
image: images.my-company.example/log-aggregator:v6
|
||||
resources:
|
||||
|
|
@ -336,6 +339,12 @@ spec:
|
|||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
volumeMounts:
|
||||
- name: ephemeral
|
||||
mountPath: "/tmp"
|
||||
volumes:
|
||||
- name: ephemeral
|
||||
emptyDir: {}
|
||||
```
|
||||
|
||||
### Como son programados los Pods con solicitudes de almacenamiento efímero
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ weight: 40
|
|||
* ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
|
||||
* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードの集合です。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはインターネットに公開されていません。
|
||||
* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。クラウドプロバイダーが管理するゲートウェイや、物理的なハードウェアの一部である場合もあります。
|
||||
* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
|
||||
* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
|
||||
* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodの集合を特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に指定がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つものとして扱われます。
|
||||
|
||||
## Ingressとは何か
|
||||
|
|
@ -66,7 +66,7 @@ Ingressリソースの最小構成の例は以下のとおりです。
|
|||
|
||||
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
|
||||
|
||||
他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
|
||||
他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
|
||||
|
||||
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
|
||||
|
||||
|
|
@ -346,7 +346,7 @@ IngressでこのSecretを参照すると、クライアントとロードバラ
|
|||
|
||||
Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
|
||||
|
||||
Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
|
||||
Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
|
||||
|
||||
## Ingressの更新
|
||||
|
||||
|
|
@ -451,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
|
|||
## {{% heading "whatsnext" %}}
|
||||
* [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
|
||||
* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
|
||||
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/)
|
||||
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/ja/docs/tasks/access-application-cluster/ingress-minikube/)
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実
|
|||
1. wins、kubelet、kubeadmをインストールします。
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ POD-NAMEの部分を実際のPodの名前に書き換えてください。
|
|||
|
||||
### RedisのマスターのServiceを作成する
|
||||
|
||||
ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
|
||||
ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/ja/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
|
||||
|
||||
|
|
@ -199,7 +199,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
|||
|
||||
### フロントエンドのServiceを作成する
|
||||
|
||||
適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
|
||||
適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/ja/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
|
||||
|
||||
もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。
|
||||
|
||||
|
|
@ -363,8 +363,8 @@ DeploymentとServiceを削除すると、実行中のPodも削除されます。
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
|
||||
* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
|
||||
* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる
|
||||
* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
|
||||
* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む
|
||||
* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
|
||||
* [リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
|
||||
|
|
|
|||
|
|
@ -246,7 +246,7 @@ By default, the Kubernetes API server serves HTTP on 2 ports:
|
|||
- is intended for testing and bootstrap, and for other components of the master node
|
||||
(scheduler, controller-manager) to talk to the API
|
||||
- no TLS
|
||||
- default is port 8080, change with `--insecure-port` flag.
|
||||
- default is port 8080
|
||||
- default IP is localhost, change with `--insecure-bind-address` flag.
|
||||
- request **bypasses** authentication and authorization modules.
|
||||
- request handled by admission control module(s).
|
||||
|
|
@ -266,7 +266,7 @@ By default, the Kubernetes API server serves HTTP on 2 ports:
|
|||
|
||||
- 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信
|
||||
- 没有 TLS
|
||||
- 默认为端口 8080，使用 `--insecure-port` 进行更改
|
||||
- 默认为端口 8080
|
||||
- 默认 IP 为 localhost，使用 `--insecure-bind-address` 进行更改
|
||||
- 请求 **绕过** 身份认证和鉴权模块
|
||||
- 由准入控制模块处理的请求
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ objects.
|
|||
|
||||
All of this is best illustrated by examples. Imagine a Kubernetes release,
|
||||
version X, which introduces a new API group. A new Kubernetes release is made
|
||||
every approximately 3 months (4 per year). The following table describes which
|
||||
every approximately 4 months (3 per year). The following table describes which
|
||||
API versions are supported in a series of subsequent releases.
|
||||
-->
|
||||
用户必须能够升级到 Kubernetes 新的发行版本，之后再回滚到前一个发行版本，且
|
||||
|
|
@ -215,7 +215,7 @@ API versions are supported in a series of subsequent releases.
|
|||
就对象的存储表示而言，这一点尤其是不言自明的。
|
||||
|
||||
以上所有规则最好通过例子来说明。假定现有 Kubernetes 发行版本为 X，其中引入了
|
||||
新的 API 组。大约每隔 3 个月会有一个新的 Kubernetes 版本被发布（每年 4 个版本）。
|
||||
新的 API 组。大约每隔 4 个月会有一个新的 Kubernetes 版本被发布（每年 3 个版本）。
|
||||
下面的表格描述了在一系列后续的发布版本中哪些 API 版本是受支持的。
|
||||
|
||||
<table>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ no_list: true
|
|||
A production-quality Kubernetes cluster requires planning and preparation.
|
||||
If your Kubernetes cluster is to run critical workloads, it must be configured to be resilient.
|
||||
This page explains steps you can take to set up a production-ready cluster,
|
||||
or to uprate an existing cluster for production use.
|
||||
or to promote an existing cluster for production use.
|
||||
If you're already familiar with production setup and want the links, skip to
|
||||
[What's next](#what-s-next).
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -305,11 +305,11 @@ kubectl 为 Bash 和 Zsh 提供自动补全功能，可以减轻许多输入的
|
|||
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
|
||||
```
|
||||
<!--
|
||||
1. Validate the binary (optional)
|
||||
2. Validate the binary (optional)
|
||||
|
||||
Download the kubectl-convert checksum file:
|
||||
-->
|
||||
1. 验证该可执行文件（可选步骤）
|
||||
2. 验证该可执行文件（可选步骤）
|
||||
|
||||
下载 kubectl-convert 校验和文件：
|
||||
|
||||
|
|
@ -352,18 +352,18 @@ kubectl 为 Bash 和 Zsh 提供自动补全功能，可以减轻许多输入的
|
|||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. Install kubectl-convert
|
||||
3. Install kubectl-convert
|
||||
-->
|
||||
1. 安装 kubectl-convert
|
||||
3. 安装 kubectl-convert
|
||||
|
||||
```bash
|
||||
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Verify plugin is successfully installed
|
||||
4. Verify plugin is successfully installed
|
||||
-->
|
||||
1. 验证插件是否安装成功
|
||||
4. 验证插件是否安装成功
|
||||
|
||||
```shell
|
||||
kubectl convert --help
|
||||
|
|
|
|||
Loading…
Reference in New Issue