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

Merge pull request #2 from kubernetes/master

Browse Source 
merge
This commit is contained in:
bryan
2020-03-23 22:58:16 +08:00
committed by GitHub
parent c19f351603 fbaeb89823
commit 3bb12b851c
109 changed files with 3014 additions and 2177 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWNERS_ALIASES
+1
View File
@@ -64,6 +64,7 @@ aliases:
- makoscafee
- onlydole
- rajakavitha1
- rajeshdeshpande02
- sftim
- steveperry-53
- tengqm
assets/sass/_base.sass
+9 -3
View File
@@ -109,6 +109,7 @@ header
box-shadow: 0 0 0 transparent
transition: 0.3s
text-align: center
overflow: hidden
.logo
@@ -244,8 +245,7 @@ header
background-color: white
#mainNav
display: none
h5
color: $blue
font-weight: normal
@@ -578,6 +578,9 @@ section
li
display: inline-block
height: 100%
margin-right: 10px
&:last-child
margin-right: 0
a
display: block
@@ -598,11 +601,11 @@ section
#vendorStrip
line-height: 44px
max-width: 100%
overflow-x: auto
-webkit-overflow-scrolling: touch
ul
float: none
overflow-x: auto
#searchBox
float: none
@@ -1052,6 +1055,9 @@ dd
a.issue
margin-left: 0px
.gridPageHome .flyout-button
display: none
.feedback--no
margin-left: 1em
content/de/docs/home/_index.md
+1 -1
View File
@@ -3,7 +3,7 @@ title: Kubernetes Dokumentation
noedit: true
cid: docsHome
layout: docsportal_home
class: gridPage
class: gridPage gridPageHome
linkTitle: "Home"
main_menu: true
weight: 10
content/en/blog/_posts/Kong-Ingress-Controller-and-Service-Mesh.md
+11 -10
View File
@@ -11,8 +11,8 @@ Kubernetes has become the de facto way to orchestrate containers and the service
Ingress is a group of rules that will proxy inbound connections to endpoints defined by a backend. However, Kubernetes does not know what to do with Ingress resources without an Ingress controller, which is where an open source controller can come into play. In this post, we are going to use one option for this: the Kong Ingress Controller. The Kong Ingress Controller was open-sourced a year ago and recently reached one million downloads. In the recent 0.7 release, service mesh support was also added. Other features of this release include:
* **Built-In Kubernetes Admission Controller,** which validates Custom Resource Definitions (CRD) as they are created or updated and rejects any invalid configurations.
* **n-Memory Mode** - Each pod’s controller actively configures the Kong container in its pod, which limits the blast radius of failure of a single container of Kong or controller container to that pod only.
* **Built-In Kubernetes Admission Controller**, which validates Custom Resource Definitions (CRD) as they are created or updated and rejects any invalid configurations.
* **In-memory Mode** - Each pod’s controller actively configures the Kong container in its pod, which limits the blast radius of failure of a single container of Kong or controller container to that pod only.
* **Native gRPC Routing** - gRPC traffic can now be routed via Kong Ingress Controller natively with support for method-based routing.
![K4K-gRPC](/images/blog/Kong-Ingress-Controller-and-Service-Mesh/KIC-gRPC.png)
@@ -50,7 +50,7 @@ $ kubectl label namespace kong istio-injection=enabled
namespace/kong labeled
```
Having both namespaces labeled istio-injection=enabled is necessary. Or else the default configuration will not inject a sidecar into the pods of your namespaces.
Having both namespaces labeled `istio-injection=enabled` is necessary. Or else the default configuration will not inject a sidecar container into the pods of your namespaces.
Now deploy your BookInfo application with the following command:
@@ -72,7 +72,7 @@ serviceaccount/bookinfo-productpage created
deployment.apps/productpage-v1 created
```
Let’s double-check our services and pods to make sure that we have it all set up correctly:
Let’s double-check our Services and Pods to make sure that we have it all set up correctly:
```
$ kubectl get services
@@ -87,6 +87,7 @@ reviews ClusterIP 10.104.207.136 <none> 9080/TCP 28s
You should see four new services: details, productpage, ratings, and reviews. None of them have an external IP so we will use the [Kong gateway](https://github.com/Kong/kong) to expose the necessary services. And to check pods, run the following command:
```
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
details-v1-c5b5f496d-9wm29 2/2 Running 0 101s
productpage-v1-7d6cfb7dfd-5mc96 2/2 Running 0 100s
@@ -96,7 +97,7 @@ reviews-v2-ccffdd984-9jnsj 2/2 Running 0 101s
reviews-v3-98dc67b68-nzw97 2/2 Running 0 101s
```
is command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. With that said, you should now be able to access your product page!
This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. With that said, you should now be able to access your product page!
```
$ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
@@ -131,11 +132,11 @@ NAME READY STATUS RESTARTS AGE
pod/ingress-kong-8b44c9856-9s42v 3/3 Running 0 2m26s
```
There will be three containers within this pod. The first container is the Kong Gateway that will be the Ingress point to your cluster. The second container is the Ingress controller. It uses Ingress resources and updates the proxy to follow rules defined in the resource. And lastly, the third container is the Envoy proxy injected by Istio. Kong will route traffic through the Envoy sidecar proxy to the appropriate service. To send requests into the cluster via our newly deployed Kong Gateway, setup an environment variable with the IP address at which Kong is accessible.
There will be three containers within this pod. The first container is the Kong Gateway that will be the Ingress point to your cluster. The second container is the Ingress controller. It uses Ingress resources and updates the proxy to follow rules defined in the resource. And lastly, the third container is the Envoy proxy injected by Istio. Kong will route traffic through the Envoy sidecar proxy to the appropriate service. To send requests into the cluster via our newly deployed Kong Gateway, setup an environment variable with the a URL based on the IP address at which Kong is accessible.
```
$ export PROXY_IP=$(minikube service -n kong kong-proxy --url | head -1)
$ echo $PROXY_IP
$ export PROXY_URL="$(minikube service -n kong kong-proxy --url | head -1)"
$ echo $PROXY_URL
http://192.168.99.100:32728
```
@@ -182,10 +183,10 @@ spec:
ingress.extensions/productpage created
```
And just like that, the Kong Ingress Controller is able to understand the rules you defined in the Ingress resource and routes it to the productpage service! To view the product page service’s GUI, go to [http://](http://{Your)<span style="text-decoration:underline;">$PROXY_IP/productpage.</span> Or to test it in your command line, try:
And just like that, the Kong Ingress Controller is able to understand the rules you defined in the Ingress resource and routes it to the productpage service! To view the product page service’s GUI, go to `$PROXY_URL/productpage` in your browser. Or to test it in your command line, try:
```
$ curl <span style="text-decoration:underline;">$PROXY_IP/productpage</span>
$ curl $PROXY_URL/productpage
```
That is all I have for this walk-through. If you enjoyed the technologies used in this post, please check out their repositories since they are all open source and would love to have more contributors! Here are their links for your convenience:
content/en/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -184,7 +184,7 @@ a Lease object.
timeout for unreachable nodes).
- The kubelet creates and then updates its Lease object every 10 seconds
(the default update interval). Lease updates occur independently from the
`NodeStatus` updates.
`NodeStatus` updates. If the Lease update fails, the kubelet retries with exponential backoff starting at 200 milliseconds and capped at 7 seconds.
#### Reliability
content/en/docs/concepts/configuration/manage-compute-resources-container.md
+1 -7
View File
@@ -68,13 +68,7 @@ resource requests/limits of that type for each Container in the Pod.
## Meaning of CPU
Limits and requests for CPU resources are measured in *cpu* units.
One cpu, in Kubernetes, is equivalent to:
- 1 AWS vCPU
- 1 GCP Core
- 1 Azure vCore
- 1 IBM vCPU
- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading
One cpu, in Kubernetes, is equivalent to **1 vCPU/Core** for cloud providers and **1 hyperthread** on bare-metal Intel processors.
Fractional requests are allowed. A Container with
`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much
content/en/docs/concepts/storage/persistent-volumes.md
+4
View File
@@ -312,6 +312,10 @@ spec:
server: 172.17.0.2
```
{{< note >}}
Helper programs relating to the volume type may be required for consumption of a PersistentVolume within a cluster. In this example, the PersistentVolume is of type NFS and the helper program /sbin/mount.nfs is required to support the mounting of NFS filesystems.
{{< /note >}}
### Capacity
Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`.
content/en/docs/contribute/style/style-guide.md
+47 -47
View File
@@ -14,10 +14,10 @@ This page gives writing style guidelines for the Kubernetes documentation.
These are guidelines, not rules. Use your best judgment, and feel free to
propose changes to this document in a pull request.
For additional information on creating new content for the Kubernetes
documentation, read the [Documentation Content
Guide](/docs/contribute/style/content-guide/) and follow the instructions on
[using page templates](/docs/contribute/style/page-templates/) and [creating a
For additional information on creating new content for the Kubernetes
documentation, read the [Documentation Content
Guide](/docs/contribute/style/content-guide/) and follow the instructions on
[using page templates](/docs/contribute/style/page-templates/) and [creating a
documentation pull request](/docs/contribute/start/#improve-existing-content).
{{% /capture %}}
@@ -58,11 +58,11 @@ leads to an awkward construction.
{{< table caption = "Do and Don't - API objects" >}}
Do | Don't
:--| :-----
The Pod has two containers. | The pod has two containers.
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 ...
The two ContainerPorts ... | The two ContainerPort objects ...
The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ...
{{< /table >}}
@@ -83,11 +83,11 @@ represents.
Do | Don't
:--| :-----
Click **Fork**. | Click "Fork".
Select **Other**. | Select "Other".
Select **Other**. | Select "Other".
{{< /table >}}
### Use italics to define or introduce new terms
{{< table caption = "Do and Don't - Use italics for new terms" >}}
Do | Don't
:--| :-----
@@ -102,7 +102,7 @@ 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.
Open the `/_data/concepts.yaml` file. | Open the /\_data/concepts.yaml file.
{{< /table >}}
### Use the international standard for punctuation inside quotes
@@ -119,18 +119,18 @@ The copy is called a "fork". | The copy is called a "fork."
### Use code style for inline code and commands
For inline code in an HTML document, use the `<code>` tag. In a Markdown
document, use the backtick (`).
document, use the backtick (`` ` ``).
{{< 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**.
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.
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 >}}
@@ -185,7 +185,7 @@ 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.16. | Set the value of `image` to `nginx:1.16`.
Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`.
{{< /table >}}
{{< /table >}}
## Code snippet formatting
@@ -196,7 +196,7 @@ Set the value of the `replicas` field to 2. | Set the value of the `replicas` fi
Do | Don't
:--| :-----
kubectl get pods | $ kubectl get pods
{{< /table >}}
{{< /table >}}
### Separate commands from output
@@ -214,7 +214,7 @@ The output is similar to this:
Code examples and configuration examples that include version information should be consistent with the accompanying text.
If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template] (/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template](/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page.
@@ -251,11 +251,11 @@ 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 >}}
{{< /table >}}
## Shortcodes
Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** {{</* note */>}}, **Caution** {{</* caution */>}}, and **Warning** {{</* warning */>}}.
Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** `{{</* note */>}}`, **Caution** `{{</* caution */>}}`, and **Warning** `{{</* warning */>}}`.
1. Surround the text with an opening and closing shortcode.
@@ -275,7 +275,7 @@ The prefix you choose is the same text for the tag.
### Note
Use {{</* note */>}} to highlight a tip or a piece of information that may be helpful to know.
Use `{{</* note */>}}` to highlight a tip or a piece of information that may be helpful to know.
For example:
@@ -291,7 +291,7 @@ The output is:
You can _still_ use Markdown inside these callouts.
{{< /note >}}
You can use a {{</* note */>}} in a list:
You can use a `{{</* note */>}}` in a list:
```
1. Use the note shortcode in a list
@@ -323,7 +323,7 @@ The output is:
### Caution
Use {{</* caution */>}} to call attention to an important piece of information to avoid pitfalls.
Use `{{</* caution */>}}` to call attention to an important piece of information to avoid pitfalls.
For example:
@@ -341,7 +341,7 @@ The callout style only applies to the line directly above the tag.
### Warning
Use {{</* warning */>}} to indicate danger or a piece of information that is crucial to follow.
Use `{{</* warning */>}}` to indicate danger or a piece of information that is crucial to follow.
For example:
@@ -359,11 +359,11 @@ Beware.
### Katacoda Embedded Live Environment
This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel).
It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete
This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel).
It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete
Minikube and Kubectl installation process locally.
The Embedded Live Environment is configured to run `minikube start` and lets users complete tutorials in the same window
The Embedded Live Environment is configured to run `minikube start` and lets users complete tutorials in the same window
as the documentation.
{{< caution >}}
@@ -376,7 +376,7 @@ For example:
{{</* kat-button */>}}
```
The output is:
The output is:
{{< kat-button >}}
@@ -391,7 +391,7 @@ For example:
1. Preheat oven to 350˚F
1. Prepare the batter, and pour into springform pan.
{{</* note */>}}Grease the pan for best results.{{</* /note */>}}
`{{</* note */>}}Grease the pan for best results.{{</* /note */>}}`
1. Bake for 20-25 minutes or until set.
@@ -429,9 +429,9 @@ 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 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 >}}
{{< /table >}}
### Paragraphs
@@ -439,8 +439,8 @@ Use sentence case for headings. For example, **Extend kubectl with plugins** | U
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 >}}
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
@@ -449,7 +449,7 @@ 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 >}}
{{< /table >}}
### Lists
@@ -457,17 +457,17 @@ Group items in a list that are related to each other and need to appear in a spe
Website navigation links can also be marked up as list items; after all they are nothing but a group of related links.
- End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences.
{{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}}
- Use the number one (1.) for ordered lists.
- Use (+), (* ), or (-) for unordered lists.
- Leave a blank line after each list.
- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).
- Use the number one (`1.`) for ordered lists.
- Use (`+`), (`*`), or (`-`) for unordered lists.
- Leave a blank line after each list.
- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).
- List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab.
### Tables
@@ -486,7 +486,7 @@ This section contains suggested best practices for clear, concise, and consisten
Do | Don't
:--| :-----
This command starts a proxy. | This command will start a proxy.
{{< /table >}}
{{< /table >}}
Exception: Use future or past tense if it is required to convey the correct
@@ -512,7 +512,7 @@ Use simple and direct language. Avoid using unnecessary phrases, such as saying
Do | Don't
:--| :-----
To create a ReplicaSet, ... | In order to create a ReplicaSet, ...
See the configuration file. | Please see the configuration file.
See the configuration file. | Please see the configuration file.
View the Pods. | With this next command, we'll view the Pods.
{{< /table >}}
@@ -522,7 +522,7 @@ View the Pods. | With this next command, we'll view the Pods.
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 ...
In the preceding output, you can see... | In the preceding output, we can see ...
{{< /table >}}
@@ -583,7 +583,7 @@ considered new in a few months.
Do | Don't
:--| :-----
In version 1.4, ... | In the current version, ...
The Federation feature provides ... | The new Federation feature provides ...
The Federation feature provides ... | The new Federation feature provides ...
{{< /table >}}
content/en/docs/home/_index.md
+1 -1
View File
@@ -5,7 +5,7 @@ title: Kubernetes Documentation
noedit: true
cid: docsHome
layout: docsportal_home
class: gridPage
class: gridPage gridPageHome
linkTitle: "Home"
main_menu: true
weight: 10
content/en/docs/reference/access-authn-authz/authentication.md
+1 -1
View File
@@ -33,7 +33,7 @@ stored as `Secrets`, which are mounted into pods allowing in-cluster processes
to talk to the Kubernetes API.
API requests are tied to either a normal user or a service account, or are treated
as anonymous requests. This means every process inside or outside the cluster, from
as [anonymous requests](#anonymous-requests). This means every process inside or outside the cluster, from
a human user typing `kubectl` on a workstation, to `kubelets` on nodes, to members
of the control plane, must authenticate when making requests to the API server,
or be treated as an anonymous user.
content/en/docs/reference/access-authn-authz/rbac.md
+425 -282
View File
File diff suppressed because it is too large Load Diff
content/en/docs/reference/glossary/kube-scheduler.md
+1 -1
View File
@@ -11,7 +11,7 @@ tags:
- architecture
---
Control plane component that watches for newly created
{{< glossary_tooltip term_id="node" >}} with no assigned
{{< glossary_tooltip term_id="pod" text="Pods" >}} with no assigned
{{< glossary_tooltip term_id="node" text="node">}}, and selects a node for them
to run on.
content/en/docs/setup/production-environment/container-runtimes.md
+30 -9
View File
@@ -184,27 +184,48 @@ sysctl --system
```
{{< tabs name="tab-cri-cri-o-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
{{< tab name="Debian" codelang="bash" >}}
# Debian Unstable/Sid
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
# Install prerequisites
apt-get update
apt-get install -y software-properties-common
# Debian Testing
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
add-apt-repository ppa:projectatomic/ppa
apt-get update
# Debian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
# Raspbian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
# Install CRI-O
apt-get install -y cri-o-1.15
sudo apt-get install cri-o-1.17
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}}
# Setup repository
. /etc/os-release
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
sudo apt-get update
# Install CRI-O
sudo apt-get install cri-o-1.17
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
# Install prerequisites
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
# Install CRI-O
yum install --nogpgcheck -y cri-o
{{< /tab >}}
{{< tab name="openSUSE Tumbleweed" codelang="bash" >}}
sudo zypper install cri-o
{{< /tab >}}
{{< /tabs >}}
content/id/docs/concepts/cluster-administration/networking.md
+228
View File
@@ -0,0 +1,228 @@
---
title: Jaringan Kluster
content_template: templates/concept
weight: 50
---
{{% capture overview %}}
Jaringan adalah bagian utama dari Kubernetes, tetapi bisa menjadi sulit
untuk memahami persis bagaimana mengharapkannya bisa bekerja.
Ada 4 masalah yang berbeda untuk diatasi:
1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh
[Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini.
3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
{{% /capture %}}
{{% capture body %}}
Kubernetes adalah tentang berbagi mesin antar aplikasi. Pada dasarnya,
saat berbagi mesin harus memastikan bahwa dua aplikasi tidak mencoba menggunakan
_port_ yang sama. Mengkoordinasikan _port_ di banyak pengembang sangat sulit
dilakukan pada skala yang berbeda dan memaparkan pengguna ke masalah
tingkat kluster yang di luar kendali mereka.
Alokasi _port_ yang dinamis membawa banyak komplikasi ke sistem - setiap aplikasi
harus menganggap _port_ sebagai _flag_, _server_ API harus tahu cara memasukkan
nomor _port_ dinamis ke dalam blok konfigurasi, Service-Service harus tahu cara
menemukan satu sama lain, dll. Sebaliknya daripada berurusan dengan ini,
Kubernetes mengambil pendekatan yang berbeda.
## Model jaringan Kubernetes
Setiap Pod mendapatkan alamat IP sendiri. Ini berarti kamu tidak perlu secara langsung membuat tautan antara Pod dan kamu hampir tidak perlu berurusan dengan memetakan _port_ kontainer ke _port_ pada _host_. Ini menciptakan model yang bersih, kompatibel dengan yang sebelumnya dimana Pod dapat diperlakukan seperti halnya VM atau _host_ fisik dari perspektif alokasi _port_, penamaan, _service discovery_, _load balancing_, konfigurasi aplikasi, dan migrasi.
Kubernetes memberlakukan persyaratan mendasar berikut pada setiap implementasi jaringan (kecuali kebijakan segmentasi jaringan yang disengaja):
* Pod pada suatu Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT
* agen pada suatu simpul (mis. _daemon_ sistem, kubelet) dapat berkomunikasi dengan semua Pod pada Node itu
Catatan: Untuk platform yang mendukung Pod yang berjalan di jaringan _host_ (mis. Linux):
* Pod di jaringan _host_ dari sebuah Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT
Model ini tidak hanya sedikit kompleks secara keseluruhan, tetapi pada prinsipnya kompatibel dengan keinginan Kubernetes untuk memungkinkan _low-friction porting_ dari aplikasi dari VM ke kontainer. Jika pekerjaan kamu sebelumnya dijalankan dalam VM, VM kamu memiliki IP dan dapat berbicara dengan VM lain di proyek yang sama. Ini adalah model dasar yang sama.
Alamat IP Kubernetes ada di lingkup Pod - kontainer dalam Pod berbagi jaringan _namespace_ mereka - termasuk alamat IP mereka. Ini berarti bahwa kontainer dalam Pod semua dapat mencapai _port_ satu sama lain di `_localhost_`. Ini juga berarti bahwa kontainer dalam Pod harus mengoordinasikan penggunaan _port_, tetapi ini tidak berbeda dari proses di VM. Ini disebut model "IP-per-pod".
## Bagaimana menerapkan model jaringan Kubernetes
Ada beberapa cara agar model jaringan ini dapat diimplementasikan. Dokumen ini bukan studi lengkap tentang berbagai metode, tetapi semoga berfungsi sebagai pengantar ke berbagai teknologi dan berfungsi sebagai titik awal.
Opsi jaringan berikut ini disortir berdasarkan abjad - urutan tidak menyiratkan status istimewa apa pun.
### ACI
[Infrastruktur Sentral Aplikasi Cisco](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) menawarkan solusi SDN overlay dan underlay terintegrasi yang mendukung kontainer, mesin virtual, dan _bare metal server_. [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer untuk ACI. Tinjauan umum integrasi disediakan [di sini](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf).
### AOS dari Apstra
[AOS](http://www.apstra.com/products/aos/) adalah sistem Jaringan Berbasis Intent yang menciptakan dan mengelola lingkungan pusat data yang kompleks dari platform terintegrasi yang sederhana. AOS memanfaatkan desain terdistribusi sangat _scalable_ untuk menghilangkan pemadaman jaringan sambil meminimalkan biaya.
Desain Referensi AOS saat ini mendukung _host_ yang terhubung dengan Lapis-3 yang menghilangkan masalah peralihan Lapis-2 yang lama. Host Lapis-3 ini bisa berupa _server_ Linux (Debian, Ubuntu, CentOS) yang membuat hubungan tetangga BGP secara langsung dengan _top of rack switches_ (TORs). AOS mengotomatisasi kedekatan perutean dan kemudian memberikan kontrol yang halus atas _route health injections_ (RHI) yang umum dalam _deployment_ Kubernetes.
AOS memiliki banyak kumpulan endpoint REST API yang memungkinkan Kubernetes dengan cepat mengubah kebijakan jaringan berdasarkan persyaratan aplikasi. Peningkatan lebih lanjut akan mengintegrasikan model Grafik AOS yang digunakan untuk desain jaringan dengan penyediaan beban kerja, memungkinkan sistem manajemen ujung ke ujung untuk layanan cloud pribadi dan publik.
AOS mendukung penggunaan peralatan vendor umum dari produsen termasuk Cisco, Arista, Dell, Mellanox, HPE, dan sejumlah besar sistem white-box dan sistem operasi jaringan terbuka seperti Microsoft SONiC, Dell OPX, dan Cumulus Linux.
Detail tentang cara kerja sistem AOS dapat diakses di sini: http://www.apstra.com/products/how-it-works/
### AWS VPC CNI untuk Kubernetes
[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) menawarkan jaringan AWS _Virtual Private Cloud_ (VPC) terintegrasi untuk kluster Kubernetes. Plugin CNI ini menawarkan _throughput_ dan ketersediaan tinggi, latensi rendah, dan _jitter_ jaringan minimal. Selain itu, pengguna dapat menerapkan jaringan AWS VPC dan praktik keamanan terbaik untuk membangun kluster Kubernetes. Ini termasuk kemampuan untuk menggunakan catatan aliran VPC, kebijakan perutean VPC, dan grup keamanan untuk isolasi lalu lintas jaringan.
Menggunakan _plugin_ CNI ini memungkinkan Pod Kubernetes memiliki alamat IP yang sama di dalam Pod seperti yang mereka lakukan di jaringan VPC. CNI mengalokasikan AWS _Elastic Networking Interfaces_ (ENIs) ke setiap node Kubernetes dan menggunakan rentang IP sekunder dari setiap ENI untuk Pod pada Node. CNI mencakup kontrol untuk pra-alokasi ENI dan alamat IP untuk waktu mulai Pod yang cepat dan memungkinkan kluster besar hingga 2.000 Node.
Selain itu, CNI dapat dijalankan bersama [Calico untuk penegakan kebijakan jaringan](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). Proyek AWS VPC CNI adalah _open source_ dengan [dokumentasi di GitHub](https://github.com/aws/amazon-vpc-cni-k8s).
### Big Cloud Fabric dari Big Switch Networks
[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) adalah arsitektur jaringan asli layanan cloud, yang dirancang untuk menjalankan Kubernetes di lingkungan cloud pribadi / lokal. Dengan menggunakan SDN fisik & _virtual_ terpadu, Big Cloud Fabric menangani masalah yang sering melekat pada jaringan kontainer seperti penyeimbangan muatan, visibilitas, pemecahan masalah, kebijakan keamanan & pemantauan lalu lintas kontainer.
Dengan bantuan arsitektur multi-penyewa Pod virtual pada Big Cloud Fabric, sistem orkestrasi kontainer seperti Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm akan terintegrasi secara alami bersama dengan sistem orkestrasi VM seperti VMware, OpenStack & Nutanix. Pelanggan akan dapat terhubung dengan aman berapa pun jumlah klusternya dan memungkinkan komunikasi antar penyewa di antara mereka jika diperlukan.
Terbaru ini BCF diakui oleh Gartner sebagai visioner dalam [_Magic Quadrant_](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). Salah satu penyebaran BCF Kubernetes di tempat (yang mencakup Kubernetes, DC/OS & VMware yang berjalan di beberapa DC di berbagai wilayah geografis) juga dirujuk [di sini](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
### Cilium
[Cilium](https://github.com/cilium/cilium) adalah perangkat lunak _open source_ untuk menyediakan dan secara transparan mengamankan konektivitas jaringan antar kontainer aplikasi. Cilium mengetahui L7/HTTP dan dapat memberlakukan kebijakan jaringan pada L3-L7 menggunakan model keamanan berbasis identitas yang dipisahkan dari pengalamatan jaringan.
### CNI-Genie dari Huawei
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) adalah _plugin_ CNI yang memungkinkan Kubernetes [secara bersamaan memiliki akses ke berbagai implementasi](https://github.com/Huawei-PaaS /CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) dari [model jaringan Kubernetes] (https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) dalam _runtime_. Ini termasuk setiap implementasi yang berjalan sebagai [_plugin_ CNI](https://github.com/containernetworking/cni#3rd-party-plugins), seperti [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
CNI-Genie juga mendukung [menetapkan beberapa alamat IP ke sebuah Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-address-per-pod), masing-masing dari _plugin_ CNI yang berbeda.
### cni-ipvlan-vpc-k8s
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) berisi satu set _plugin_ CNI dan IPAM untuk menyediakan kemudahan, host-lokal, latensi rendah, _throughput_ tinggi , dan tumpukan jaringan yang sesuai untuk Kubernetes dalam lingkungan Amazon Virtual Private Cloud (VPC) dengan memanfaatkan Amazon Elastic Network Interfaces (ENI) dan mengikat IP yang dikelola AWS ke Pod-Pod menggunakan _driver_ IPvlan _kernel_ Linux dalam mode L2.
Plugin ini dirancang untuk secara langsung mengkonfigurasi dan _deploy_ dalam VPC. Kubelet melakukan _booting_ dan kemudian mengkonfigurasi sendiri dan memperbanyak penggunaan IP mereka sesuai kebutuhan tanpa memerlukan kompleksitas yang sering direkomendasikan untuk mengelola jaringan _overlay_, BGP, menonaktifkan pemeriksaan sumber/tujuan, atau menyesuaikan tabel rute VPC untuk memberikan _subnet_ per _instance_ ke setiap _host_ (yang terbatas hingga 50-100 masukan per VPC). Singkatnya, cni-ipvlan-vpc-k8s secara signifikan mengurangi kompleksitas jaringan yang diperlukan untuk menggunakan Kubernetes yang berskala di dalam AWS.
### Contiv
[Contiv](https://github.com/contiv/netplugin) menyediakan jaringan yang dapat dikonfigurasi (_native_ l3 menggunakan BGP, _overlay_ menggunakan vxlan, classic l2, atau Cisco-SDN / ACI) untuk berbagai kasus penggunaan. [Contiv](http://contiv.io) semuanya open sourced.
### Contrail / Tungsten Fabric
[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), berdasarkan [Tungsten Fabric](https://tungsten.io), adalah platform virtualisasi jaringan dan manajemen kebijakan _multi-cloud_ yang benar-benar terbuka. Contrail dan Tungsten Fabric terintegrasi dengan berbagai sistem orkestrasi seperti Kubernetes, OpenShift, OpenStack dan Mesos, dan menyediakan mode isolasi yang berbeda untuk mesin _virtual_, banyak kontainer / banyak Pod dan beban kerja _bare metal_.
### DANM
[DANM] (https://github.com/nokia/danm) adalah solusi jaringan untuk beban kerja telco yang berjalan di kluster Kubernetes. Dibangun dari komponen-komponen berikut:
* Plugin CNI yang mampu menyediakan antarmuka IPVLAN dengan fitur-fitur canggih
* Modul IPAM built-in dengan kemampuan mengelola dengan jumlah banyak, _cluster-wide_, _discontinous_ jaringan L3 dan menyediakan skema dinamis, statis, atau tidak ada permintaan skema IP
* Metaplugin CNI yang mampu melampirkan beberapa antarmuka jaringan ke kontainer, baik melalui CNI sendiri, atau mendelegasikan pekerjaan ke salah satu solusi CNI populer seperti SRI-OV, atau Flannel secara paralel
* Pengontrol Kubernetes yang mampu mengatur secara terpusat antarmuka VxLAN dan VLAN dari semua _host_ Kubernetes
* Pengontrol Kubernetes lain yang memperluas konsep _service discovery_ berbasis servis untuk bekerja di semua antarmuka jaringan Pod
Dengan _toolset_ ini, DANM dapat memberikan beberapa antarmuka jaringan yang terpisah, kemungkinan untuk menggunakan ujung belakang jaringan yang berbeda dan fitur IPAM canggih untuk Pod.
### Flannel
[Flannel] (https://github.com/coreos/flannel#flannel) adalah jaringan overlay yang sangat sederhana yang memenuhi persyaratan Kubernetes. Banyak orang telah melaporkan kesuksesan dengan Flannel dan Kubernetes.
### Google Compute Engine (GCE)
Untuk skrip konfigurasi kluster Google Compute Engine, [perutean lanjutan](https://cloud.google.com/vpc/docs/routes) digunakan untuk menetapkan setiap VM _subnet_ (standarnya adalah `/24` - 254 IP). Setiap lalu lintas yang terikat untuk _subnet_ itu akan dialihkan langsung ke VM oleh _fabric_ jaringan GCE. Ini adalah tambahan untuk alamat IP "utama" yang ditugaskan untuk VM, yang NAT'ed untuk akses internet keluar. Sebuah linux _bridge_ (disebut `cbr0`) dikonfigurasikan untuk ada pada subnet itu, dan diteruskan ke _flag_ `-bridge` milik docker.
Docker dimulai dengan:
```shell
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
```
Jembatan ini dibuat oleh Kubelet (dikontrol oleh _flag_ `--network-plugin=kubenet`) sesuai dengan `.spec.podCIDR` yang dimiliki oleh Node.
Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan` cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas `Node` itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8).
```shell
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
```
Terakhir IP forwarding diaktifkan di kernel (sehingga kernel akan memproses paket untuk kontainer yang dijembatani):
```shell
sysctl net.ipv4.ip_forward=1
```
Hasil dari semua ini adalah bahwa semua Pod dapat saling menjangkau dan dapat keluar lalu lintas ke internet.
### Jaguar
[Jaguar](https://gitlab.com/sdnlab/jaguar) adalah solusi open source untuk jaringan Kubernetes berdasarkan OpenDaylight. Jaguar menyediakan jaringan overlay menggunakan vxlan dan Jaguar CNIPlugin menyediakan satu alamat IP per Pod.
### Knitter
[Knitter](https://github.com/ZTE/Knitter/) adalah solusi jaringan yang mendukung banyak jaringan di Kubernetes. Solusi ini menyediakan kemampuan manajemen penyewa dan manajemen jaringan. Knitter mencakup satu set solusi jaringan kontainer NFV ujung ke ujung selain beberapa pesawat jaringan, seperti menjaga alamat IP untuk aplikasi, migrasi alamat IP, dll.
### Kube-OVN
[Kube-OVN](https://github.com/alauda/kube-ovn) adalah _fabric_ jaringan kubernetes berbasis OVN untuk _enterprises_. Dengan bantuan OVN/OVS, solusi ini menyediakan beberapa fitur jaringan _overlay_ canggih seperti _subnet_, QoS, alokasi IP statis, _mirroring traffic_, _gateway_, kebijakan jaringan berbasis _openflow_, dan proksi layanan.
### Kube-router
[Kube-router](https://github.com/cloudnativelabs/kube-router) adalah solusi jaringan yang dibuat khusus untuk Kubernetes yang bertujuan untuk memberikan kinerja tinggi dan kesederhanaan operasional. Kube-router menyediakan Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) berbasis proksi layanan, solusi jaringan berbasis penerusan _pod-to-pod_ Linux _kernel_ tanpa _overlay_, dan penegak kebijakan jaringan berbasis _iptables/ipset_.
### L2 networks and linux bridging
Jika Anda memiliki jaringan L2 yang "bodoh", seperti saklar sederhana di _environment_ "bare-metal", kamu harus dapat melakukan sesuatu yang mirip dengan pengaturan GCE di atas. Perhatikan bahwa petunjuk ini hanya dicoba dengan sangat sederhana - sepertinya berhasil, tetapi belum diuji secara menyeluruh. Jika kamu menggunakan teknik ini dan telah menyempurnakan prosesnya, tolong beri tahu kami.
Ikuti bagian "With Linux Bridge devices" dari [tutorial yang sangat bagus ini](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) dari Lars Kellogg-Stedman.
### Multus (plugin Multi-Jaringan)
[Multus](https://github.com/Intel-Corp/multus-cni) adalah plugin Multi CNI untuk mendukung fitur Banyak Jaringan di Kubernetes menggunakan objek jaringan berbasis CRD di Kubernetes.
Multus mendukung semua [plugin referensi](https://github.com/containernetworking/plugins) (mis. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main / macvlan)) yang mengimplementasikan spesifikasi CNI dan plugin pihak ke-3 (mis. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave ), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). Selain itu, Multus mendukung [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS- DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) beban kerja di Kubernetes dengan aplikasi cloud asli dan aplikasi berbasis NFV di Kubernetes.
### NSX-T
[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) adalah virtualisasi jaringan dan platform keamanan. NSX-T dapat menyediakan virtualisasi jaringan untuk lingkungan multi-cloud dan multi-hypervisor dan berfokus pada kerangka kerja dan arsitektur aplikasi yang muncul yang memiliki titik akhir dan tumpukan teknologi yang heterogen. Selain hypervisor vSphere, lingkungan ini termasuk hypervisor lainnya seperti KVM, wadah, dan bare metal.
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) menyediakan integrasi antara NSX-T dan pembuat wadah seperti Kubernetes, serta integrasi antara NSX-T dan platform CaaS / PaaS berbasis-kontainer seperti Pivotal Container Service (PKS) dan OpenShift.
### Nuage Networks VCS (Layanan Cloud Virtual)
[Nuage](http://www.nuagenetworks.net) menyediakan platform SDN (Software-Defined Networking) berbasis kebijakan yang sangat skalabel. Nuage menggunakan Open vSwitch _open source_ untuk data _plane_ bersama dengan SDN Controller yang kaya fitur yang dibangun pada standar terbuka.
Platform Nuage menggunakan _overlay_ untuk menyediakan jaringan berbasis kebijakan yang mulus antara Kubernetes Pod-Pod dan lingkungan non-Kubernetes (VM dan server _bare metal_). Model abstraksi kebijakan Nuage dirancang dengan mempertimbangkan aplikasi dan membuatnya mudah untuk mendeklarasikan kebijakan berbutir halus untuk aplikasi. Mesin analisis _real-time_ platform memungkinkan pemantauan visibilitas dan keamanan untuk aplikasi Kubernetes.
### OpenVSwitch
[OpenVSwitch](https://www.openvswitch.org/) adalah cara yang agak lebih dewasa tetapi juga rumit untuk membangun jaringan _overlay_. Ini didukung oleh beberapa "Toko Besar" untuk jaringan.
### OVN (Open Virtual Networking)
OVN adalah solusi virtualisasi jaringan opensource yang dikembangkan oleh komunitas Open vSwitch. Ini memungkinkan seseorang membuat switch logis, router logis, ACL stateful, load-balancers dll untuk membangun berbagai topologi jaringan virtual. Proyek ini memiliki plugin dan dokumentasi Kubernetes spesifik di [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
### Project Calico
[Project Calico](http://docs.projectcalico.org/) adalah penyedia jaringan wadah sumber terbuka dan mesin kebijakan jaringan.
Calico menyediakan solusi jaringan dan kebijakan kebijakan jaringan yang sangat berskala untuk menghubungkan Pod Kubernetes berdasarkan prinsip jaringan IP yang sama dengan internet, untuk Linux (open source) dan Windows (milik - tersedia dari [Tigera](https://www.tigera.io/essentials/)). Calico dapat digunakan tanpa enkapsulasi atau _overlay_ untuk menyediakan jaringan pusat data skala tinggi yang berkinerja tinggi. Calico juga menyediakan kebijakan keamanan jaringan berbutir halus, berdasarkan niat untuk Pod Kubernetes melalui _firewall_ terdistribusi.
Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solusi jaringan lain seperti Flannel, alias [kanal](https://github.com/tigera/canal), atau jaringan GCE, AWS atau Azure asli.
### Romana
[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
### Weave Net dari Weaveworks
[Weave Net](https://www.weave.works/products/weave-net/) adalah jaringan yang tangguh dan mudah digunakan untuk Kubernetes dan aplikasi yang dihostingnya. Weave Net berjalan sebagai [plug-in CNI](https://www.weave.works/docs/net/latest/cni-plugin/) atau berdiri sendiri. Di kedua versi, itu tidak memerlukan konfigurasi atau kode tambahan untuk dijalankan, dan dalam kedua kasus, jaringan menyediakan satu alamat IP per Pod - seperti standar untuk Kubernetes.
{{% /capture %}}
{{% capture whatsnext %}}
Desain awal model jaringan dan alasannya, dan beberapa rencana masa depan dijelaskan secara lebih rinci dalam [dokumen desain jaringan](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
{{% /capture %}}
content/id/docs/concepts/overview/working-with-objects/labels.md
+225
View File
@@ -0,0 +1,225 @@
---
title: Label dan Selektor
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
_Label_ merupakan pasangan _key/value_ yang melekat pada objek-objek, misalnya pada Pod.
Label digunakan untuk menentukan atribut identitas dari objek agar memiliki arti dan relevan bagi para pengguna, namun tidak secara langsung memiliki makna terhadap sistem inti.
Label dapat digunakan untuk mengatur dan memilih sebagian dari banyak objek. Label-label dapat ditempelkan ke objek-objek pada saat dibuatnya objek-objek tersebut dan kemudian ditambahkan atau diubah kapan saja setelahnya.
Setiap objek dapat memiliki satu set label _key/value_. Setiap _Key_ harus unik untuk objek tersebut.
```json
"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}
```
Label memungkinkan untuk menjalankan kueri dan pengamatan dengan efisien, serta ideal untuk digunakan pada UI dan CLI. Informasi yang tidak digunakan untuk identifikasi sebaiknya menggunakan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/).
{{% /capture %}}
{{% capture body %}}
## Motivasi
Label memungkinkan pengguna untuk memetakan struktur organisasi mereka ke dalam objek-objek sistem yang tidak terikat secara erat, tanpa harus mewajibkan klien untuk menyimpan pemetaan tersebut.
_Service deployments_ dan _batch processing pipelines_ sering menjadi entitas yang berdimensi ganda (contohnya partisi berganda atau _deployment_, jalur rilis berganda, tingkatan berganda, _micro-services_ berganda per tingkatan). Manajemen seringkali membutuhkan operasi lintas tim, yang menyebabkan putusnya enkapsulasi dari representasi hierarki yang ketat, khususnya pada hierarki-hierarki kaku yang justru ditentukan oleh infrastruktur, bukan oleh pengguna.
Contoh label:
* `"release" : "stable"`, `"release" : "canary"`
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
Ini hanya contoh label yang biasa digunakan; kamu bebas mengembangkan caramu sendiri. Perlu diingat bahwa _Key_ dari label harus unik untuk objek tersebut.
## Sintaksis dan set karakter
_Label_ merupakan pasangan _key/value_. _Key-key_ dari Label yang valid memiliki dua segmen: sebuah prefiks dan nama yang opsional, yang dipisahkan oleh garis miring (`/`). Segmen nama wajib diisi dan tidak boleh lebih dari 63, dimulai dan diakhiri dengan karakter alfanumerik (`[a-z0-9A-Z]`) dengan tanda pisah (`-`), garis bawah (`_`), titik (`.`), dan alfanumerik di antaranya. Sedangkan prefiks bersifat opsional. Jika ditentukan, prefiks harus berupa subdomain DNS: rangkaian label DNS yang dipisahkan oleh titik (`.`), dengan total tidak lebih dari 253 karakter, yang diikuti oleh garis miring (`/`).
Jika prefiks dihilangkan, _Key_ dari label diasumsikan privat bagi pengguna. Komponen sistem otomatis (contoh `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, atau otomasi pihak ketiga lainnya) yang akan menambah label ke objek-objek milik pengguna akhir harus menentukan prefiks.
Prefiks `kubernetes.io/` dan `k8s.io/` dikhususkan untuk komponen inti Kubernetes.
Nilai label yang valid tidak boleh lebih dari 63 karakter dan harus kosong atau diawali dan diakhiri dengan karakter alfanumerik (`[a-z0-9A-Z]`) dengan tanda pisah (`-`), garis bawah (`_`), titik (`.`), dan alfanumerik di antaranya.
Contoh di bawah ini merupakan berkas konfigurasi untuk Pod yang memiliki dua label `environment: production` dan `app: nginx` :
```yaml
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
## Selektor label
Tidak seperti [nama dan UID](/id/docs/concepts/overview/working-with-objects/names/), label tidak memberikan keunikan. Secara umum, kami memperkirakan bahwa banyak objek yang akan memiliki label yang sama.
Menggunakan sebuah _label selector_, klien/pengguna dapat mengidentifikasi suatu kumpulan objek. Selektor label merupakan alat/cara pengelompokan utama pada Kubernetes.
Saat ini API mendukung dua jenis selektor: _equality-based_ dan _set-based_.
Sebuah selektor label dapat dibuat dari kondisi berganda yang dipisahkan oleh koma. Pada kasus kondisi berganda, semua kondisi harus dipenuhi sehingga separator koma dapat bertindak sebagai operator logika _AND_ (`&&`).
Makna dari selektor yang kosong atau tidak diisi tergantung dari konteks, dan tipe API yang menggunakan selektor harus mendokumentasikan keabsahan dan arti dari selektor yang kosong tersebut.
{{< note >}}
Untuk beberapa tipe API, seperti ReplicaSet, selektor label untuk dua objek tidak boleh tumpang tindih dengan Namespace, jika tidak maka _controller_ akan melihatnya sebagai instruksi yang menyebabkan konflik dan akan gagal menentukan berapa banyak replika yang seharusnya tersedia.
{{< /note >}}
{{< caution >}}
Untuk kedua kondisi _equality-based_ dan _set-based_ tidak ada logika operator _OR_ (`||`). Pastikan struktur pernyataan filter kamu ikut disesuaikan.
{{< /caution >}}
### Kondisi _Equality-based_
Kondisi _Equality-based_ atau _inequality-based_ memungkinkan untuk melakukan filter dengan menggunakan _key_ dan _value_ dari label. Objek yang cocok harus memenuhi semua batasan label yang telah ditentukan, meskipun mereka dapat memiliki label tambahan lainnya.
Terdapat tiga jenis operator yang didukung yaitu `=`,`==`,`!=`. Dua operator pertama menyatakan kesamaan (keduanya hanyalah sinonim), sementara operator terakhir menyatakan ketidaksamaan. Contoh:
```
environment = production
tier != frontend
```
Kondisi pertama akan memilih semua sumber daya dengan _key_ `environment` dan nilai _key_ `production`.
Kondisi berikutnya akan memilih semua sumber daya dengan _key_ `tier` dan nilai _key_ selain `frontend`, dan semua sumber daya yang tidak memiliki label dengan _key_ `tier`.
Kamu juga dapat memfilter sumber daya dalam `production` selain `frontend` dengan menggunakan operator koma: `environment=production,tier!=frontend`
Salah satu skenario penggunaan label dengan kondisi _equality-based_ yaitu untuk kriteria pemilihan Node untuk Pod-Pod. Sebagai contoh, Pod percontohan di bawah ini akan memilih Node dengan label "`accelerator=nvidia-tesla-p100`".
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-test
spec:
containers:
- name: cuda-test
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100
```
### Kondisi _Set-based_
Kondisi label _Set-based_ memungkinkan memfilter _key_ terhadap suatu kumpulan nilai. Terdapat tiga jenis operator yang didukung, yaitu: `in`,`notin`, dan `exists` (hanya _key_-nya saja). Contoh:
```
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
```
Contoh pertama akan memilih semua sumber daya dengan _key_ `environment` dan nilai `production` atau `qa`.
Contoh kedua akan memilih semua sumber daya dengan _key_ `tier` dan nilai selain `frontend` dan `backend`, serta semua sumber daya yang tidak memiliki label dengan _key_ `tier`.
Contoh ketiga akan memilih semua sumber daya yang memiliki _key_ dari label`partition`; nilainya tidak diperiksa.
Sedangkan contoh keempat akan memilih semua sumber daya yang tidak memiliki label dengan _key_ `partition`; nilainya tidak diperiksa.
Secara serupa, operator koma bertindak sebagai operator _AND_. Sehingga penyaringan sumber daya dengan _key_ `partition` (tidak peduli nilai dari _key_) dan `environment` yang tidak sama dengan `qa` dapat dicapai dengan `partition,environment notin (qa)`.
Selektor label _set-based_ merupakan bentuk umum persamaan karena `environment=production` sama dengan `environment in (production)`; demikian pula `!=` dan `notin`.
Kondisi _Set-based_ dapat digabungkan dengan kondisi _equality-based_. Contoh: `partition in (customerA, customerB),environment!=qa`.
## API
### Penyaringan LIST dan WATCH
Operasi LIST dan WATCH dapat menentukan selektor label untuk memfilter suatu kumpulan objek yang didapat dengan menggunakan parameter kueri. Kedua jenis kondisi diperbolehkan (ditampilkan sebagai berikut, sama seperti saat tampil pada string kueri di URL):
* Kondisi _equality-based_: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* Kondisi _set-based_: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
Kedua jenis selektor label dapat digunakan untuk menampilkan (_list_) dan mengamati (_watch_) sumber daya melalui klien REST. Contohnya, menargetkan `apiserver` dengan `kubectl` dan menggunakan _equality-based_ kamu dapat menuliskan:
```shell
kubectl get pods -l environment=production,tier=frontend
```
atau menggunakan kondisi _set-based_:
```shell
kubectl get pods -l 'environment in (production),tier in (frontend)'
```
Seperti yang telah disebutkan sebelumnya, kondisi _set-based_ lebih ekspresif. Sebagai contoh, mereka dapat digunakan untuk mengimplementasi operator _OR_ pada nilai:
```shell
kubectl get pods -l 'environment in (production, qa)'
```
atau membatasi pencocokan negatif dengan operator _exists_:
```shell
kubectl get pods -l 'environment,environment notin (frontend)'
```
### Mengatur referensi pada objek API
Pada beberapa objek Kubernetes, seperti [`Service`](/docs/user-guide/services) dan [`ReplicationController`](/id/docs/concepts/workloads/controllers/replicationcontroller/), juga menggunakan selektor label untuk menentukan kumpulan dari sumber daya lain, seperti [Pod](/id/docs/concepts/workloads/pods/pod).
#### Service dan ReplicationController
Kumpulan Pod yang ditargetkan oleh sebuah `service` ditentukan dengan selektor label. Demikian pula kumpulan Pod yang harus ditangani oleh `replicationcontroller` juga ditentukan dengan selektor label.
Selektor label untuk kedua objek tersebut ditentukan dalam berkas `json` atau `yaml` menggunakan _maps_, dan hanya mendukung kondisi _equality-based_:
```json
"selector": {
"component" : "redis",
}
```
atau
```yaml
selector:
component: redis
```
selektor ini (baik dalam bentuk `json` atau `yaml`) sama dengan `component=redis` atau `component in (redis)`.
#### Sumber daya yang mendukung kondisi set-based
Sumber daya yang lebih baru, seperti [`Job`](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/), dan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/), juga mendukung kondisi _set-based_.
```yaml
selector:
matchLabels:
component: redis
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: NotIn, values: [dev]}
```
`matchLabels` merupakan pemetaan dari pasangan `{key,value}`. Sebuah `{key,value}` pada pemetaan `matchLabels` adalah sama dengan elemen dari `matchExpressions`, yang nilai `key` nya adalah "key", dengan `operator` "In", dan _array_ `values` hanya berisi "value". `matchExpressions` merupakan daftar kondisi untuk selektor Pod. Operator yang valid termasuk In, NotIn, Exists, dan DoesNotExist. Kumpulan nilai ini tidak boleh kosong pada kasus In dan NotIn. Semua kondisi, baik dari `matchLabels` dan `matchExpressions` di-AND secara sekaligus -- mereka harus memenuhi semua kondisi agar cocok.
#### Memilih kumpulan Node
Salah satu contoh penggunaan pemilihan dengan menggunakan label yaitu untuk membatasi suatu kumpulan Node tertentu yang dapat digunakan oleh Pod.
Lihat dokumentasi pada [pemilihan Node](/id/docs/concepts/configuration/assign-pod-node/) untuk informasi lebih lanjut.
{{% /capture %}}
content/id/docs/concepts/workloads/controllers/replicationcontroller.md
+243
View File
@@ -0,0 +1,243 @@
---
title: ReplicationController
feature:
title: Reparasi otomatis
anchor: Bagaimana Sebuah ReplicationController Bekerja
description: >
Mengulang dan menjalankan kembali kontainer yang gagal, mengganti dan menjadwalkan ulang ketika ada Node yang mati, mematikan kontainer yang tidak memberikan respon terhadap health-check yang telah didefinisikan, dan tidak menunjukkannya ke klien sampai siap untuk digunakan.
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
{{< note >}}
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
{{< /note >}}
Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.
{{% /capture %}}
{{% capture body %}}
## Bagaimana ReplicationController Bekerja
Jika terdapat terlalu banyak Pod, maka ReplicationController akan membatasi dan mematikan Pod-Pod yang berlebih. Jika terdapat terlalu sedikit, maka ReplicationController akan memulai dan menjalankan Pod-Pod baru lainnya. Tidak seperti Pod yang dibuat secara manual, Pod-Pod yang diatur oleh sebuah ReplicationController akan secara otomatis diganti jika mereka gagal, dihapus, ataupun dimatikan.
Sebagai contoh, Pod-Pod yang kamu miliki akan dibuat ulang dalam sebuah Node setelah terjadi proses pemeliharaan seperti pembaruan kernel. Untuk alasan ini, maka kamu sebaiknya memiliki sebuah ReplicationController bahkan ketika aplikasimu hanya membutuhkan satu buah Pod saja. Sebuah ReplicationController memiliki kemiripan dengan sebuah pengawas proses, tetapi alih-alih mengawasi sebuah proses individu pada sebuah Node, ReplicationController banyak Pod yang terdapat pada beberapa Node.
ReplicationController seringkali disingkat sebagai "rc" dalam diskusi, dan sebagai _shortcut_ dalam perintah kubectl.
Sebuah contoh sederhana adalah membuat sebuah objek ReplicationController untuk menjalankan sebuah _instance_ Pod secara berkelanjutan. Contoh pemakaian lainnya adalah untuk menjalankan beberapa replika identik dari sebuah servis yang direplikasi, seperti peladen web.
## Menjalankan Sebuah Contoh ReplicationController
Contoh ReplicationController ini mengonfigurasi tiga salinan dari peladen web nginx.
{{< codenew file="controllers/replication.yaml" >}}
Jalankan contoh di atas dengan mengunduh berkas contoh dan menjalankan perintah ini:
```shell
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
```
```
replicationcontroller/nginx created
```
Periksa status dari ReplicationController menggunakan perintah ini:
```shell
kubectl describe replicationcontrollers/nginx
```
```
Name: nginx
Namespace: default
Selector: app=nginx
Labels: app=nginx
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- ---- ------ -------
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-qrm3m
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-3ntk0
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v
```
Tiga Pod telah dibuat namun belum ada yang berjalan, kemungkinan karena _image_ yang sedang di-_pull_.
Beberapa waktu kemudian, perintah yang sama akan menunjukkan:
```shell
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
```
Untuk melihat semua Pod yang dibuat oleh ReplicationController dalam bentuk yang lebih mudah dibaca mesin, kamu dapat menggunakan perintah seperti ini:
```shell
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods
```
```
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```
Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan yang terdapat pada ReplicationController (yang dapat dilihat pada keluaran `kubectl describe`), dan dalam bentuk yang berbeda dengan yang terdapat pada `replication.yaml`. Opsi `--output=jsonpath` menentukan perintah untuh mendapatkan hanya nama dari setiap Pod yang ada pada daftar hasil.
## Menulis Spesifikasi ReplicationController
Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`.
Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/).
Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
### Templat Pod
`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`.
`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod).
Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker.
### Label pada ReplicationController
ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Biasanya, kamu akan mengaturnya untuk memiliki nilai yang sama dengan `.spec.template.metadata.labels`; jika `.metadata.labels` tidak ditentukan maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`. Namun begitu, kedua label ini diperbolehkan untuk memiliki nilai yang berbeda, dan `.metadata.labels` tidak akan memengaruhi perilaku dari ReplicationController.
### Selektor Pod
_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`.
Selain itu, kamu juga sebaiknya tidak membuat Pod dengan label yang cocok dengan selektor ini, baik secara langsung, dengan menggunakan ReplicationController lain, ataupun menggunakan kontroler lain seperti Job. Jika kamu melakukannya, ReplicationController akan menganggap bahwa ia telah membuat Pod-Pod lainnya. Kubernetes tidak akan menghentikan kamu untuk melakukan aksi ini.
Jika kamu pada akhirnya memiliki beberapa kontroler dengan selektor-selektor yang tumpang tindih, kamu harus mengatur penghapusannya sendiri (lihat [di bawah](#bekerja-dengan-replicationcontroller)).
### Beberapa Replika
Kamu dapat menentukan jumlah Pod yang seharusnya berjalan secara bersamaan dengan mengatur nilai `.spec.replicas` dengan jumlah Pod yang kamu inginkan untuk berjalan secara bersamaan. Jumlah yang berjalan dalam satu satuan waktu dapat lebih tinggi ataupun lebih rendah, seperti jika replika-replika tersebut melewati proses penambahan atau pengurangan, atau jika sebuah Pod melalui proses _graceful shutdown_, dan penggantinya telah dijalankan terlebih dahulu.
Jika kamu tidak menentukan nilai dari `.spec.replicas`, maka akan digunakan nilai bawaan 1.
## Bekerja dengan ReplicationController
### Menghapus Sebuah ReplicationController dan Pod-nya
Untuk menghapus sebuah ReplicationController dan Pod-Pod yang berhubungan dengannya, gunakan perintah [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl akan mengatur ReplicationController ke nol dan menunggunya untuk menghapus setiap Pod sebelum menghapus ReplicationController itu sendiri. Jika perintah kubectl ini terhenti, maka dapat diulang kembali.
Ketika menggunakan REST API atau _library_ klien go, maka kamu perlu melakukan langkah-langkahnya secara eksplisit (mengatur replika-replika ke 0, menunggu penghapusan Pod, dan barulah menghapus ReplicationController).
### Menghapus Hanya ReplicationController
Kamu dapat menghapus ReplicationController tanpa memengaruhi Pod-Pod yang berhubungan dengannya.
Dengan menggunakan kubectl, tentukan opsi `--cascade=false` ke [`kubectl delete`](/docs/reference/generDeated/kubectl/kubectl-commands#delete).
Ketika menggunakan REST API atau _library_ klien go, cukup hapus objek ReplicationController.
Ketika ReplicationController yang asli telah dihapus, kamu dapat membuat ReplicationController yang baru sebagai penggantinya. Selama `.spec.selector` yang lama dan baru memiliki nilai yang sama, maka ReplicationController baru akan mengadopsi Pod-Pod yang lama.
Walaupun begitu, ia tidak akan melakukan usaha apapun untuk membuat Pod-Pod yang telah ada sebelumnya untuk sesuai dengan templat Pod yang baru dan berbeda.
Untuk memperbarui Pod-Pod ke spesifikasi yang baru dengan cara yang terkontrol, gunakan [pembaruan bergulir](#pembaruan-bergulir).
### Mengisolasi Pod dari ReplicationController
Pod-Pod dapat dihapus dari kumpulan target sebuah ReplicationController dengan mengganti nilai dari labelnya. Teknik ini dapat digunakan untuk mencopot Pod-Pod dari servis untuk keperluan pengawakutuan (_debugging_), pemulihan data, dan lainnya. Pod-Pod yang dicopot dengan cara ini dapat digantikan secara otomatis (dengan asumsi bahwa jumlah replika juga tidak berubah).
## Pola penggunaan umum
### Penjadwalan ulang
Seperti yang telah disebutkan sebelumnya, baik kamu memiliki hanya 1 Pod untuk tetap dijalankan, ataupun 1000, ReplicationController akan memastikan tersedianya jumlah Pod yang telat ditentukan, bahkan ketika terjadi kegagalan Node atau terminasi Pod (sebagai contoh karena adanya tindakan dari agen kontrol lain).
### Penskalaan
ReplicationController memudahkan penskalaan jumlah replika, baik meningkatkan ataupun mengurangi, secara manual ataupun dengan agen kontrol penskalaan otomatis, dengan hanya mengubah nilai dari _field_ `replicas`.
### Pembaruan bergulir
ReplicationController didesain untuk memfasilitasi pembaruan bergulir untuk sebuah servis dengan mengganti Pod-Pod satu per satu.
Seperti yang telah dijelaskan di [#1353](http://issue.k8s.io/1353), pendekatan yang direkomendasikan adalah dengan membuat ReplicationController baru dengan 1 replika, skala kontroler yang baru (+1) atau yang lama (-1) satu per satu, dan kemudian hapus kontroler lama setelah menyentuh angka 0 replika. Hal ini memungkinkan pembaruan dilakukan dengan dapat diprediksi terlepas dari adanya kegagalan yang tak terduga.
Idealnya, kontroler pembaruan bergulir akan memperhitungkan kesiapan dari aplikasi, dan memastikan cukupnya jumlah Pod yang secara produktif meladen kapanpun.
Dua ReplicationController diharuskan untuk memiliki setidaknya satu label yang berbeda, seperti _tag_ _image_ dari kontainer utama dari Pod, karena pembaruan bergulir biasanya dilakukan karena adanya pembaruan _image_.
Pembaruan bergulir diimplementasikan pada perkakas klien [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update). Lihat [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) untuk contoh-contoh yang lebih konkrit.
### Operasi rilis majemuk
Selain menjalankan beberapa rilis dari sebuah aplikasi ketika proses pembaruan bergulir sedang berjalan, adalah hal yang awam untuk menjalankan beberapa rilis untuk suatu periode waktu tertentu, atau bahkan secara kontinu, menggunakan operasi rilis majemuk. Operasi-operasi ini akan dibedakan menggunakan label.
Sebagai contoh, sebuah servis dapat menyasar semua Pod dengan `tier in (frontend), environment in (prod)`. Anggap kamu memiliki 10 Pod tiruan yang membangun _tier_ ini tetapi kamu ingin bisa menggunakan 'canary' terhadap versi baru dari komponen ini. Kamu dapat mengatur sebuah ReplicationController dengan nilai `replicas` 9 untuk replika-replikanya, dengan label `tier=frontend, environment=prod, track=stable`, dan ReplicationController lainnya dengan nilai `replicas` 1 untuk canary, dengan label `tier=frontend, environment=prod, track=canary`. Sekarang servis sudah mencakup baik canary maupun Pod-Pod yang bukan canary. Kamu juga dapat mencoba-coba ReplicationController secara terpisah untuk melakukan pengujian, mengamati hasilnya, dan lainnya.
### Menggunakan ReplicationController dengan Service
Beberapa ReplicationController dapat berada di belakang sebuah Service, sedemikian sehingga, sebagai contoh, sebagian _traffic_ dapat ditujukan ke versi lama, dan sebagian lainnya ke versi yang baru.
Sebuah ReplicationController tidak akan berhenti dengan sendirinya, namun ia tidak diekspektasikan untuk berjalan selama Service-Service yang ada. Service dapat terdiri dari berbagai Pod yang dikontrol beberapa ReplicationController, dan terdapat kemungkinan bahwa beberapa ReplicationController untuk dibuat dan dimatikan dalam jangka waktu hidup Service (contohnya adalah untuk melakukan pembaruan Pod-Pod yang menjalankan Service). Baik Service itu sendiri dan kliennya harus tetap dalam keadaan tidak mempunyai pengetahuan terhadap ReplicationController yang memelihara Pod-Pod dari Service tersebut.
## Menulis program untuk Replikasi
Pod-Pod yang dibuat oleh ReplicationController ditujukan untuk dapat sepadan dan memiliki semantik yang identik, walaupun konfigurasi mereka dapat berbeda seiring keberjalanan waktunya. Ini adalah contoh yang cocok untuk peladen _stateless_, namun ReplicationController juga dapat digunakan untuk memelihara ketersediaan dari aplikasi-aplikasi yang _master-elected_, _sharded_, _worker-pool_. Aplikasi-aplikasi seperti itu sebaiknya menggunakan mekanisme penetapan kerja yang dinamis, seperti [antrian kerja RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), berlainan dengan pengubahan statis/satu kali dari konfigurasi setiap Pod, yang dipandang sebagai sebuah _anti-pattern_. Pengubahan apapun yang dilakukan terhadap Pod, seperti _auto-sizing_ vertikal dari sumber daya (misalnya cpu atau memori), sebaiknya dilakukan oleh proses kontroller luring lainnya, dan bukan oleh ReplicationController itu sendiri.
## Tanggung Jawab ReplicationController
ReplicationController hanya memastikan ketersediaan dari sejumlah Pod yang cocok dengan selektor label dan berjalan dengan baik. Saat ini, hanya Pod yang diterminasi yang dijadikan pengecualian dari penghitungan. Kedepannya, [kesiapan](http://issue.k8s.io/620) dan informasi yang ada lainnya dari sistem dapat menjadi pertimbangan, kami dapat meningkatkan kontrol terhadap kebijakan penggantian, dan kami berencana untuk menginformasikan kejadian (_event_) yang dapat digunakan klien eksternal untuk implementasi penggantian yang sesuai dan/atau kebijakan pengurangan.
ReplicationController akan selalu dibatasi terhadap tanggung jawab spesifik ini. Ia tidak akan melakukan _probe_ kesiapan atau keaktifan. Daripada melakukan _auto-scaling_, ia ditujukan untuk dikontrol oleh _auto-scaler_ eksternal (seperti yang didiskusikan pada [#492](http://issue.k8s.io/492)), yang akan mengganti _field_ `replicas`. Kami tidak akan menambahkan kebijakan penjadwalan (contohnya [_spreading_](http://issue.k8s.io/367#issuecomment-48428019)) untuk ReplicationController. Ia juga tidak seharusnya melakukan verifikasi terhadap Pod-Pod yang sedang dikontrol yang cocok dengan spesifikasi templat saat ini, karena hal itu dapat menghambat _auto-sizing_ dan proses otomatis lainnya. Demikian pula batas waktu penyelesaian, pengurutan _dependencies_, ekspansi konfigurasi, dan fitur-fitur lain yang seharusnya berada di komponen lain. Kami juga bahkan berencana untuk mengeluarkan mekanisme pembuatan Pod secara serentak ([#170](http://issue.k8s.io/170)).
ReplicationController ditujukan untuk menjadi primitif komponen yang dapat dibangun untuk berbagai kebutuhan. Kami menargetkan API dengan tingkatan yang lebih tinggi dan/atau perkakas-perkakas untuk dibangun di atasnya dan primitif tambahan lainnya untuk kenyamanan pengguna kedepannya. Operasi-operasi makro yang sudah didukung oleh kubectl (_run_, _scale_, _rolling-update_) adalah contoh _proof-of-concept_ dari konsep ini. Sebagai contohnya, kita dapat menganggap sesuatu seperti [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) yang mengatur beberapa ReplicationController, _auto-scaler_, servis, kebijakan penjadwalan, canary, dan yang lainnya.
## Objek API
ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubernetes. Detil dari objek API dapat ditemukan di: [objek API ReplicationController](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicationcontroller-v1-core).
## Alternatif untuk ReplicationController
### ReplicaSet
[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.
### Deployment (Direkomendasikan)
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
### Pod sederhana
Tidak seperti pada kasus ketika pengguna secara langsung membuat Pod, ReplicationController menggantikan Pod-Pod yang dihapus atau dimatikan untuk alasan apapun, seperti pada kasus kegagalan Node atau pemeliharaan Node yang disruptif, seperti pembaruan kernel. Untuk alasan ini, kami merekomendasikan kamu untuk menggunakan ReplicationController bahkan ketika aplikasimu hanya membutuhkan satu Pod saja. Anggap hal ini mirip dengan pengawas proses, hanya pada kasus ini mengawasi banyak Pod yang terdapat pada berbagai Node dan bukan proses-proses tunggal pada satu Node. ReplicationController mendelegasikan pengulangan kontainer lokal ke agen yang terdapat dalam Node (contohnya Kubelet atau Docker).
### Job
Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai ganti ReplicationController untuk Pod-Pod yang diharapkan diterminasi dengan sendirinya (seperti _batch jobs_).
### DaemonSet
Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
## Informasi lanjutan
Baca [Menjalankan Kontroler Replikasi AP _Stateless_](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
{{% /capture %}}
content/id/examples/controllers/replication.yaml
+19
View File
@@ -0,0 +1,19 @@
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
content/pl/_index.html
+2 -2
View File
@@ -45,12 +45,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Weź udział w KubeCon w Amsterdamie 30.03-2.04.2020</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Weź udział w KubeCon w Amsterdamie (lipiec/sierpień)</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Weź udział w KubeCon w Szanghaju 28-30.07.2020</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Weź udział w KubeCon w Bostonie 17-20.11.2020</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
content/pl/docs/concepts/_index.md
+1 -1
View File
@@ -26,7 +26,7 @@ Gdy tylko zdefiniujesz zamierzony stan, warstwa sterowania Kubernetes (*Kubernet
## Obiekty Kubernetes
Kubernetes składa się z różnych abstrakcyjnych obiektów, które reprezentują stan systemu: wdrożone aplikacje i zadania w kontenerach, powiązane zasoby sieciowe i dyskowe oraz inne informacje o tym, co się dzieje na klasterze. Te abstrakcyjne obiekty są reprezentowane przez API Kubernetes. [Opis Obiektów w Kubernetesie](/docs/concepts/overview/working-with-objects/kubernetes-objects/) zawiera więcej szczegółów na ten temat.
Kubernetes składa się z różnych abstrakcyjnych obiektów, które reprezentują stan systemu: wdrożone aplikacje i zadania w kontenerach, powiązane zasoby sieciowe i dyskowe oraz inne informacje o tym, co się dzieje na klasterze. Te abstrakcyjne obiekty są reprezentowane przez API Kubernetes. [Opis obiektów w Kubernetesie](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) zawiera więcej szczegółów na ten temat.
Do podstawowych obiektów Kubernetes należą:
content/pl/docs/concepts/overview/components.md
+4 -4
View File
@@ -10,7 +10,7 @@ card:
{{% capture overview %}}
W wyniku instalacji Kubernetes otrzymujesz klaster.
{{< glossary_definition term_id="cluster" length="all" prepend="Klaster to">}}
{{< glossary_definition term_id="cluster" length="all" prepend="Klaster Kubernetes to">}}
W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetes.
@@ -20,11 +20,11 @@ Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego r
{{% /capture %}}
{{% capture body %}}
## Master — częsci składowe
## Częsci składowe warstwy sterowania
Komponenty *master* odpowiadają za warstwę sterowania klastra. Podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik).
Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik).
Komponenty *master* mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*.
Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*.
### kube-apiserver
content/pl/docs/concepts/overview/kubernetes-api.md
+10 -9
View File
@@ -48,7 +48,7 @@ W wersjach wcześniejszych niż 1.14, punkty końcowe określone przez ich forma
**Przykłady pobierania specyfikacji OpenAPI**:
Przed 1.10 | Począwszy od Kubernetes 1.10
Przed 1.10 | Kubernetes 1.10 i nowszy
----------- | -----------------------------
GET /swagger.json | GET /openapi/v2 **Accept**: application/json
GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
@@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API.
Przed wersją 1.14, apiserver Kubernetes udostępniał też specyfikację API [Swagger v1.2](http://swagger.io/) poprzez `/swaggerapi`.
Ten punkt końcowy jest fazie wycofywania i zostanie ostatecznie usunięty w wersji Kubernetes 1.14.
Ten punkt końcowy został skierowany do wycofania i ostatecznie usunięty w wersji Kubernetes 1.14.
## Obsługa wersji API
@@ -108,20 +108,21 @@ API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/
i użyć [agregatora](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/),
aby zintegrować je w sposób niezauważalny dla klientów.
## Włączanie grup API
## Włączanie i wyłączanie grup API
Określone zasoby i grupy API są włączone domyślnie. Włączanie i wyłączanie odbywa się poprzez ustawienie `--runtime-config`
w apiserwerze. `--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić
`--runtime-config=batch/v1=false`, aby włączyć batch/v2alpha1, należy ustawić `--runtime-config=batch/v2alpha1`.
Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą apiserwera.
WAŻNE: Włączenie lub wyłączenie grup lub zasobów wymaga restartu apiserver i controller-manager, aby zmiany w `--runtime-config` zostały wprowadzone.
{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu apiserver i controller-manager, aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}}
## Jak włączać dostęp do grup zasobów
## Jak włączać dostęp do grup zasobów extensions/v1beta1
DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs and ReplicaSets są domyślnie włączone.
Pozostałe rozszerzenia mogą być włączane poprzez ustawienie `--runtime-config` w
apiserver. `--runtime-config` przyjmuje wartości rozdzielane przecinkami. Na przykład, aby zablokować deployments oraz ingress, ustaw
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`
DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie włączone.
Przykładowo: aby włączyć deployments i daemonsets, ustaw
`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
{{< note >}}Włączanie i wyłączanie pojedynczych zasobów możliwe jest jedynie w ramach grupy API `extensions/v1beta1` z przyczyn historycznych{{< /note >}}
{{% /capture %}}
content/pl/docs/concepts/overview/what-is-kubernetes.md
+4 -2
View File
@@ -1,5 +1,7 @@
---
title: Kubernetes — co to jest?
description: >
Kubernetes to przenośna, rozszerzalna platforma oprogramowania *open-source* służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach. Umożliwia ich deklaratywną konfigurację i automatyzację. Kubernetes posiada duży i dynamicznie rozwijający się ekosystem. Szeroko dostępne są serwisy, wsparcie i dodatkowe narzędzia.
content_template: templates/concept
weight: 10
card:
@@ -14,7 +16,7 @@ Na tej stronie znajdziesz ogólne informacje o Kubernetesie.
{{% capture body %}}
Kubernetes to przenośna, rozszerzalna platforma oprogramowania *open-source* służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach, która umożliwia deklaratywną konfigurację i automatyzację. Ekosystem Kubernetesa jest duży i dynamicznie się rozwija. Serwisy Kubernetesa, wsparcie i narzędzia są szeroko dostępne.
Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](https://ai.google/research/pubs/pub43438) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
## Trochę historii
@@ -42,7 +44,7 @@ Kontenery zyskały popularność ze względu na swoje zalety, takie jak:
* Rozdzielenie zadań *Dev* i *Ops*: obrazy kontenerów powstają w fazie *build/release*, oddzielając w ten sposób aplikacje od infrastruktury.
* Obserwowalność obejmuje nie tylko informacje i metryki z poziomu systemu operacyjnego, ale także poprawność działania samej aplikacji i inne sygnały.
* Spójność środowiska na etapach rozwoju oprogramowania, testowania i działania w trybie produkcyjnym: działa w ten sam sposób na laptopie i w chmurze.
* Możliwość przenoszenia pomiędzy systemami operacyjnymi i platformami chmurowymi: Ubuntu, RHEL, CoreOS, prywatnymi centrami danych, Google Kubernetes Engine czy gdziekolwiek indziej.
* Możliwość przenoszenia pomiędzy systemami operacyjnymi i platformami chmurowymi: Ubuntu, RHEL, CoreOS, prywatnymi centrami danych, największymi dostawcami usług chmurowych czy gdziekolwiek indziej.
* Zarządzanie, które w centrum uwagi ma aplikacje: Poziom abstrakcji przeniesiony jest z warstwy systemu operacyjnego działającego na maszynie wirtualnej na poziom działania aplikacji, która działa na systemie operacyjnym używając zasobów logicznych.
* Luźno powiązane, rozproszone i elastyczne "swobodne" mikro serwisy: Aplikacje podzielone są na mniejsze, niezależne komponenty, które mogą być dynamicznie uruchamiane i zarządzane - nie jest to monolityczny system działający na jednej, dużej maszynie dedykowanej na wyłączność.
* Izolacja zasobów: wydajność aplikacji możliwa do przewidzenia
content/pl/docs/contribute/_index.md
+24 -51
View File
@@ -13,65 +13,38 @@ lub strony www Kubernetesa! Nieważne, czy dopiero poznajesz projekt, czy jeste
z nami już od dawna, czy uważasz się za programistę, użytkownika, czy po prostu
nie możesz patrzeć na literówki.
Więcej informacji na temat zawartości dokumentacji Kubernetesa i jej stylu,
znajdziesz w
[Opisie stylu dokumentacji](/docs/contribute/style/).
{{% /capture %}}
{{% capture body %}}
## Rodzaje uczestnictwa w procesie tworzenia dokumentacji
## Od czego zacząć?
- _Członek_ (_member_) organizacji Kubernetes, który [podpisał CLA](/docs/contribute/start#sign-the-cla)
i poświęcił swój czas oraz wysiłek na rzecz projektu. Dokument
[Członkostwo w organizacji](https://github.com/kubernetes/community/blob/master/community-membership.md)
zawiera szczegóły z tym związane.
- _Recenzent_ (_reviewer_) SIG Docs to członek organizacji Kubernetes, który zgłosił
swoją chęć weryfikacji propozycji zmian w dokumentacji (PR) i został dodany
do odpowiedniej grupy GitHub i pliku 'OWNERS' w repozytorium GitHub przez
osobę zatwierdzającą SIG Docs.
- _Osoba zatwierdzająca_ (_approver_) SIG Docs to członek organizacji o uznanej reputacji,
który wykazał się długotrwałym zaangażowaniem w prace projektu.
Osoba zatwierdzająca może włączać propozycje zmian do repozytoriów i publikować
treści w imieniu organizacji Kubernetes.
Osoby zatwierdzające mogą również reprezentować SIG Docs na szerszym forum
społeczności Kubernetes.
Niektóre wymagania związane z tą rolą, jak na przykład koordynacja kolejnego wydania,
wymagają poświęcenia znacznej ilości czasu.
Każdy może otworzyć zgłoszenie, które zawiera opis problemu czy oczekiwane usprawnienia dokumentacji lub samemu zaproponować zmianę poprzez *pull request* (PR).
Do realizacji niektórych zadań potrzeba wyższego poziomu zaufania i odpowiednich uprawnień w organizacji Kubernetes.
Zajrzyj do [Participating in SIG Docs](/docs/contribute/participating/) po więcej szczegółów
dotyczących ról i uprawnień.
## Sposoby współpracy przy tworzeniu dokumentacji
Dokumentacja Kubernetesa znajduje się w repozytorium GitHub. Zapraszamy wszystkich
do aktywnych działań na rzecz jej rozwoju, niemniej aby móc sprawnie funkcjonować w społeczności Kubernetes,
wymagana jest pewna biegłość w korzystaniu z git i GitHuba.
Poniższa lista podzielona jest na rzeczy, które może robić każdy, te, które może
robić członek organizacji Kubernetes oraz na takie, które wymagają wyższych uprawnień
i znajomości procesów SIG Docs. W miarę postępującej współpracy, będziesz mógł lepiej
zrozumieć niektóre narzędzia czy decyzje, które zostały wcześniej podjęte
na poziomie organizacyjnym.
Aby zaangażować się w prace nad dokumentacją należy:
Ta lista nie wyczerpuje wszystkich możliwości udziału, ale powinna być pomocna
na początku.
1. Podpisać [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md) CNCF.
2. Zapoznać się z [repozytorium dokumentacji](https://github.com/kubernetes/website) i z [generatorem statycznej strony](https://gohugo.io) www.
3. Zrozumieć podstawowe procesy [ulepszania zawartości](https://kubernetes.io/docs/contribute/start/#improve-existing-content) i [recenzowania propozycji zmian](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests).
## Najlepsze praktyki zgłaszania zmian
- Opis GIT commit powinien być jasny i zrozumiały.
- Należy używać _Github Special Keywords_, które odwołują się do zgłoszenia _(issue)_ i automatycznie je zamykają, kiedy PR zostaje zaakceptowany.
- Kiedy wprowadzasz drobne zmiany do PR, takie jak literówki czy poprawki stylu lub gramatyki, pamiętaj o ich zgrupowaniu _(squash)_, aby uniknąć sytuacji, kiedy mamy dużą liczbę commitów dla stosunkowo niewielkiej zmiany.
- Dołącz dobry opis PR, który tłumaczy zmiany w kodzie, powód dla tych zmian i wszystkie informacje wystarczające, aby recenzent zrozumiał Twój PR.
- Dodatkowa literatura:
- [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
- [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests)
- [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )
- [Każdy](/docs/contribute/start/)
- Otwieranie wszelkiego rodzaju zgłoszeń, względem których mogą zostać podjęte jakieś działania
- [Członek](/docs/contribute/start/)
- Ulepszanie istniejącej dokumentacji
- Zgłaszanie pomysłów na ulepszenia poprzez komunikator [Slack](http://slack.k8s.io/) lub [listę dystrybucyjną SIG docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
- Zwiększanie dostępności dokumentacji
- Zgłaszanie niewiążących uwag do propozycji zmian (PR)
- Pisanie bloga lub studium przypadku
- [Recenzent](/docs/contribute/intermediate/)
- Opisywanie nowych funkcjonalności
- Przydzielanie kategorii i klasyfikowanie zgłoszeń
- Recenzowanie propozycji zmian
- Tworzenie schematów, grafik, osadzonych prezentacji (_screencasts_) i filmów
- Tłumaczenie
- Współtworzenie zawartości innych repozytoriów jako przedstawiciel zespołu dokumentacji
- Opracowywanie osadzonych w oprogramowaniu komunikatów dla użytkownika
- Ulepszanie komentarzy w oprogramowaniu, Godoc
- [Osoba zatwierdzająca](/docs/contribute/advanced/)
- Publikowanie dostarczonych treści poprzez zatwierdzanie propozycji zmian i włączanie ich do repozytorium
- Udział w pracach zespołu przygotowującego nowe wydanie Kubernetesa jako przedstawiciel zespołu dokumentacji
- Proponowanie ulepszeń wytycznych dotyczących stylu
- Proponowanie ulepszeń testowania dokumentacji
- Proponowanie ulepszeń strony Kubernetes lub innych narzędzi
## Inne metody współpracy
content/pl/docs/home/_index.md
+7
View File
@@ -14,6 +14,8 @@ menu:
weight: 20
post: >
<p>Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także <a href="/editdocs/" data-auto-burger-exclude>pomóc w jej tworzeniu</a>!</p>
description: >
Kubernetes to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Gospodarzem tego projektu o otwartym kodzie źródłowym jest Cloud Native Computing Foundation.
overview: >
Kubernetes to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Gospodarzem tego projektu o otwartym kodzie źródłowym jest Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>).
cards:
@@ -37,6 +39,11 @@ cards:
description: "Wyszukaj popularne zadania i dowiedz się, jak sobie z nimi efektywnie poradzić."
button: "Przegląd zadań"
button_path: "/docs/tasks"
- name: training
title: "Szkolenia"
description: "Uzyskaj certyfikat Kubernetes i spraw, aby Twoje projekty cloud native zakończyły się sukcesem!"
button: "Oferta szkoleń"
button_path: "/training"
- name: reference
title: Dokumentacja źródłowa
description: Zapoznaj się z terminologią, składnią poleceń, typami zasobów API i dokumentacją narzędzi instalacyjnych.
content/pl/docs/reference/_index.md
+9 -15
View File
@@ -17,12 +17,7 @@ Tutaj znajdziesz dokumentację źródłową Kubernetes.
## Dokumentacja API
* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Ogólne informacje na temat Kubernetes API.
* Wersje Kubernetes API
* [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
* [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
* [Dokumentacja źródłowa Kubernetes API {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
## Biblioteki klientów API
@@ -37,18 +32,17 @@ biblioteki to:
## Dokumentacja poleceń tekstowych *(CLI)*
* [kubectl](/docs/user-guide/kubectl-overview) - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes.
* [JSONPath](/docs/user-guide/jsonpath/) - Podręcznik składni [wyrażeń JSONPath](http://goessner.net/articles/JsonPath/) dla kubectl.
* [kubeadm](/docs/admin/kubeadm/) - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa.
* [kubefed](/docs/admin/kubefed/) - Narzędzie tekstowe poleceń do zarządzania klastrami w federacji.
* [kubectl](/docs/reference/kubectl/overview/) - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Podręcznik składni [wyrażeń JSONPath](http://goessner.net/articles/JsonPath/) dla kubectl.
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa.
## Dokumentacja konfiguracji
* [kubelet](/docs/admin/kubelet/) - Główny agent działający na każdym węźle. Kubelet pobiera zestaw definicji PodSpecs i gwarantuje, że opisane przez nie kontenery poprawnie działają.
* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API, które sprawdza poprawność i konfiguruje obiekty API, takie jak pody, serwisy czy kontrolery replikacji.
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Proces wykonujący główne pętle sterowania Kubernetes.
* [kube-proxy](/docs/admin/kube-proxy/) - Przekazuje bezpośrednio dane przepływające w transmisji TCP/UDP lub dystrybuuje ruch TCP/UDP zgodnie ze schematem *round-robin* pomiędzy usługi back-endu.
* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler odpowiada za dostępność, wydajność i zasoby.
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - Główny agent działający na każdym węźle. Kubelet pobiera zestaw definicji PodSpecs i gwarantuje, że opisane przez nie kontenery poprawnie działają.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API, które sprawdza poprawność i konfiguruje obiekty API, takie jak pody, serwisy czy kontrolery replikacji.
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Proces wykonujący główne pętle sterowania Kubernetes.
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Przekazuje bezpośrednio dane przepływające w transmisji TCP/UDP lub dystrybuuje ruch TCP/UDP zgodnie ze schematem *round-robin* pomiędzy usługi back-endu.
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler odpowiada za dostępność, wydajność i zasoby.
## Dokumentacja projektowa
content/pl/docs/reference/glossary/cluster.md
+9 -3
View File
@@ -4,14 +4,20 @@ id: cluster
date: 2019-06-15
full_link:
short_description: >
Zestaw maszyn, nazywanych węzłami, na których uruchamiane są aplikacje zarządzane przez Kubernetes. Klaster posiada przynajmniej jeden węzeł roboczy (*node*) i jeden węzeł typu master (*master node*).
Zestaw maszyn roboczych, nazywanych {{< glossary_tooltip text="węzłami" term_id="node" >}}, na których uruchamiane są aplikacje w kontenerach.
Każdy klaster musi posiadać przynajmniej jeden węzeł.
aka:
tags:
- fundamental
- operation
---
Zestaw maszyn, nazywanych węzłami, na których uruchamiane są aplikacje zarządzane przez Kubernetes. Klaster posiada przynajmniej jeden węzeł roboczy (*node*) i jeden węzeł typu master (*master node*).
Zestaw maszyn roboczych, nazywanych węzłami, na których uruchamiane są aplikacje w kontenerach. Każdy klaster musi posiadać przynajmniej jeden węzeł.
<!--more-->
Na węźle (lub węzłach) roboczych rozmieszczane są pody, które są częściami składowymi aplikacji. Węzeł (lub węzły) typu master zarządzają węzłami roboczymi i podami należącymi do klastra. Zwielokrotnione węzły typu master zapewniają większą niezawodność i odporność klastra na awarie.
Na węźle (lub węzłach) roboczych rozmieszczane są {{< glossary_tooltip text="pody" term_id="pod" >}},
które są częściami składowymi aplikacji.
{{< glossary_tooltip text="Warstwa sterowania" term_id="control-plane" >}} zarządza
węzłami roboczymi i podami należącymi do klastra. W środowisku produkcyjnym warstwa sterowania
rozłożona jest zazwyczaj na kilka maszyn, a klaster uruchomiony jest na wielu węzłach zapewniając
większą niezawodność i odporność na awarie.
content/pl/docs/reference/glossary/container-runtime.md
+4 -4
View File
@@ -15,7 +15,7 @@ tags:
<!--more-->
Kubernetes obsługuje różne *container runtimes*: [Docker](http://www.docker.com),
[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
[rktlet](https://github.com/kubernetes-incubator/rktlet) oraz każdą implementację zgodną z
[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
Kubernetes obsługuje różne *container runtimes*: {{< glossary_tooltip term_id="docker">}},
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}
oraz każdą implementację zgodną z [Kubernetes CRI (Container Runtime
Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
content/pl/docs/reference/glossary/kube-controller-manager.md
+1 -1
View File
@@ -11,7 +11,7 @@ tags:
- architecture
- fundamental
---
Składnik *master* odpowiedzialny za uruchamianie {{< glossary_tooltip text="kontrolerów" term_id="controller" >}}.
Składnik warstwy sterowania odpowiedzialny za uruchamianie {{< glossary_tooltip text="kontrolerów" term_id="controller" >}}.
<!--more-->
content/pl/docs/reference/glossary/kube-proxy.md
+8 -4
View File
@@ -11,13 +11,17 @@ tags:
- fundamental
- networking
---
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) to *proxy* sieciowe, które uruchomione jest na każdym węźle klastra
i uczestniczy w tworzeniu {{< glossary_tooltip term_id="service">}}.
kube-proxy to *proxy* sieciowe, które uruchomione jest na każdym
{{< glossary_tooltip text="węźle" term_id="node" >}} klastra
i uczestniczy w tworzeniu
{{< glossary_tooltip text="serwisu" term_id="service">}}.
<!--more-->
kube-proxy utrzymuje reguły sieciowe na węźle. Dzięki tym regułom
sieci na zewnątrz i wewnątrz klastra mogą komunikować się z Podami.
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
utrzymuje reguły sieciowe na węźle. Dzięki tym regułom
sieci na zewnątrz i wewnątrz klastra mogą komunikować się
z podami.
kube-proxy używa warstwy filtrowania pakietów dostarczanych przez system operacyjny, o ile taka jest dostępna.
W przeciwnym przypadku, kube-proxy samo zajmuje sie przekazywaniem ruchu sieciowego.
content/pl/docs/reference/glossary/kube-scheduler.md
+8 -3
View File
@@ -4,14 +4,19 @@ id: kube-scheduler
date: 2018-04-12
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
Składnik *master*, który monitoruje tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione.
Składnik warstwy sterowania, który śledzi tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione.
aka:
tags:
- architecture
---
Składnik *master*, który monitoruje tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione.
Składnik warstwy sterowania, który śledzi tworzenie nowych
{{< glossary_tooltip term_id="pod" text="podów" >}} i przypisuje im {{< glossary_tooltip term_id="node" text="węzły">}},
na których powinny zostać uruchomione.
<!--more-->
Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania indywidualne i zbiorcze odnośnie zasobów, ograniczenia wynikające z polityk sprzętu i oprogramowania, wymagania *affinity* i *anty-affinity*, lokalizacja danych, zależności między zadaniami i wymagania czasowe.
Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania
indywidualne i zbiorcze odnośnie zasobów, ograniczenia wynikające z polityk
sprzętu i oprogramowania, wymagania *affinity* i *anty-affinity*, lokalizacja danych,
zależności między zadaniami i wymagania czasowe.
content/pl/docs/reference/glossary/kubelet.md
+2 -2
View File
@@ -11,8 +11,8 @@ tags:
- fundamental
- core-object
---
Agent, który działa na każdym węźle klastra. Odpowiada za uruchamianie kontenerów w ramach poda.
Agent, który działa na każdym {{< glossary_tooltip text="węźle" term_id="node" >}} klastra. Odpowiada za uruchamianie {{< glossary_tooltip text="kontenerów" term_id="container" >}} w ramach {{< glossary_tooltip text="poda" term_id="pod" >}}.
<!--more-->
<!--more-->
Kubelet korzysta z dostarczanych na różne sposoby PodSpecs i gwarantuje, że kontenery opisane przez te PodSpecs są uruchomione i działają poprawnie. Kubelet nie zarządza kontenerami, które nie zostały utworzone przez Kubernetes.
content/pl/docs/setup/_index.md
+2 -61
View File
@@ -37,76 +37,17 @@ Aby uruchomić klaster Kubernetes do nauki na lokalnym komputerze, skorzystaj z
|Społeczność |Ekosystem |
| ------------ | -------- |
| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| | [Minishift](https://docs.okd.io/latest/minishift/)|
| | [MicroK8s](https://microk8s.io/)|
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
| | [k3s](https://k3s.io)|
| | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)|
## Środowisko produkcyjne {#srodowisko-produkcyjne}
Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora.
Przykładowe poziomy abstrakcji klastra Kubernetesa to: {{< glossary_tooltip text="aplikacje" term_id="applications" >}}, {{< glossary_tooltip text="warstwa danych" term_id="data-plane" >}}, {{< glossary_tooltip text="warstwa sterowania" term_id="control-plane" >}}, {{< glossary_tooltip text="infrastruktura klastra" term_id="cluster-infrastructure" >}} i {{< glossary_tooltip text="operacje na klastrze" term_id="cluster-operations" >}}.
Poniższy schemat pokazuje poszczególne poziomy abstrakcji klastra Kubernetes oraz informacje, kto jest za nie odpowiedzialny (sam użytkownik czy zewnętrzny operator).
Rozwiązania dla środowisk produkcyjnych![Rozwiązania dla środowisk produkcyjnych](/images/docs/KubernetesSolutions.svg)
{{< table caption="Tabela z dostawcami i rozwiązaniami dla środowisk produkcyjnych." >}}
Poniższa tabela zawiera przegląd dostawców środowisk produkcyjnych i rozwiązań, które oferują.
|Dostawca | Zarządzana | Chmura "pod klucz" | Prywatne centrum danych | Własne (w chmurze) | Własne (VM lokalne)| Własne (Bare Metal) |
| --------- | ------ | ------ | ------ | ------ | ------ | ----- |
| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | &#x2714; | &#x2714; | | |
| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | &#x2714; | | | |
| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | |
| [AppsCode](https://appscode.com/products/pharmer/) | &#x2714; | | | | |
| [APPUiO](https://appuio.ch/)  | &#x2714; | &#x2714; | &#x2714; | | | |
| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | &#x2714; | | &#x2714; | &#x2714; | &#x2714; |
| [CenturyLink Cloud](https://www.ctl.io/) | | &#x2714; | | | |
| [Cisco Container Platform](https://cisco.com/go/containers) | | | &#x2714; | | |
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | &#x2714; |&#x2714; |
| [CloudStack](https://cloudstack.apache.org/) | | | | | &#x2714;|
| [Canonical](https://ubuntu.com/kubernetes) | &#x2714; | &#x2714; | &#x2714; | &#x2714; |&#x2714; | &#x2714;
| [Containership](https://containership.io) | &#x2714; |&#x2714; | | | |
| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | &#x2714;
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | &#x2714; | | | | |
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |&#x2714; | &#x2714; | | | &#x2714;
| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | &#x2714; | &#x2714;
| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | &#x2714;
| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
| [Giant Swarm](https://www.giantswarm.io/) | &#x2714; | &#x2714; | &#x2714; | |
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
| [Kontena Pharos](https://www.kontena.io/pharos/) | |&#x2714;| &#x2714; | | |
| [KubeOne](https://kubeone.io/) | | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | |
| [KubeSail](https://kubesail.com/) | &#x2714; | | | | |
| [Kubespray](https://kubespray.io/#/) | | | |&#x2714; | &#x2714; | &#x2714; |
| [Kublr](https://kublr.com/) |&#x2714; | &#x2714; |&#x2714; |&#x2714; |&#x2714; |&#x2714; |
| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | |
| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | &#x2714; | | |
| [Nirmata](https://www.nirmata.com/) | | &#x2714; | &#x2714; | | |
| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) |
| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | |
| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) i [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | &#x2714; | &#x2714; | | | |
| [oVirt](https://www.ovirt.org/) | | | | | &#x2714; |
| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | |
| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | &#x2714; | &#x2714; | &#x2714;
| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/)
| [StackPoint](https://stackpoint.io/)  | &#x2714; | &#x2714; | | | |
| [Supergiant](https://supergiant.io/) | |&#x2714; | | | |
| [SUSE](https://www.suse.com/) | | &#x2714; | | | |
| [SysEleven](https://www.syseleven.io/) | &#x2714; | | | | |
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | &#x2714; | &#x2714; | | | &#x2714; |
| [VEXXHOST](https://vexxhost.com/) | &#x2714; | &#x2714; | | | |
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
| [Z.A.R.V.I.S.](https://zarvis.ai/) | &#x2714; | | | | | |
Aby zapoznać się z listą dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes), odwiedź stronę "[Partnerzy](https://kubernetes.io/partners/#conformance)".
{{% /capture %}}
content/pl/docs/tasks/_index.md
-4
View File
@@ -57,10 +57,6 @@ Konfigurowanie aplikacji w taki sposób, aby korzystała i ufała łańcuchowi c
Standardowe metody zarządzania klasterem.
## Administracja federacją
Konfigurowanie federacji klastrów.
## Zarządzanie aplikacjami ze stanem (_Stateful_)
Popularne zadania związane z zarządzaniem aplikacjami stanowymi _(Stateful)_, w tym: skalowanie, usuwanie i rozwiązywanie problemów dotyczących _StatefulSets_.
content/pl/docs/tutorials/_index.md
-2
View File
@@ -22,8 +22,6 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
* [Podstawy Kubernetes](/docs/tutorials/kubernetes-basics/) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości.
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/docs/tutorials/hello-minikube/)
content/pl/docs/tutorials/hello-minikube.md
+15 -16
View File
@@ -8,7 +8,7 @@ menu:
weight: 10
post: >
<p>Jesteś gotowy ubrudzić ręce? Zbuduj własny klaster kubernetes z działającą na nim aplikacją "Hello World" w Node.js.</p>
card:
card:
name: tutorials
weight: 10
---
@@ -49,7 +49,7 @@ Więcej informacji na temat polecenia `docker build` znajdziesz w [dokumentacji
## Stwórz klaster Minikube
1. Kliknij w **Launch Terminal**
1. Kliknij w **Launch Terminal**
{{< kat-button >}}
@@ -117,7 +117,7 @@ wykorzystując podany obraz Dockera.
```shell
kubectl config view
```
{{< note >}}Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}}
## Stwórz Serwis
@@ -167,7 +167,7 @@ musisz najpierw wystawić Pod jako [*Serwis*](/docs/concepts/services-networking
## Włącz dodatki
Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
Minikube ma zestaw wbudowanych {{< glossary_tooltip text="dodatków" term_id="addons" >}}, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
1. Lista aktualnie obsługiwanych dodatków:
@@ -184,7 +184,6 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz
efk: disabled
freshpod: disabled
gvisor: disabled
heapster: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
@@ -198,16 +197,16 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz
storage-provisioner-gluster: disabled
```
2. Włącz dodatek, na przykład `heapster`:
2. Włącz dodatek, na przykład `metrics-server`:
```shell
minikube addons enable heapster
minikube addons enable metrics-server
```
Wynik powinien wyglądać podobnie do:
```
heapster was successfully enabled
metrics-server was successfully enabled
```
3. Sprawdź Pod i Serwis, który właśnie stworzyłeś:
@@ -222,7 +221,7 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/heapster-9jttx 1/1 Running 0 26s
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
@@ -233,23 +232,23 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/heapster ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
4. Wyłącz dodatek `heapster`:
4. Wyłącz dodatek `metrics-server`:
```shell
minikube addons disable heapster
minikube addons disable metrics-server
```
Wynik powinien wyglądać podobnie do:
```
heapster was successfully disabled
heapster was successfully metrics-server
```
## Porządkujemy po sobie
@@ -278,7 +277,7 @@ minikube delete
{{% capture whatsnext %}}
* Dowiedz się więcej o [obiektach typu Deployment](/docs/concepts/workloads/controllers/deployment/).
* Dowiedz się więcej o [instalowaniu aplikacji](/docs/user-guide/deploying-applications/).
* Dowiedz się więcej o [instalowaniu aplikacji](/docs/tasks/run-application/run-stateless-application-deployment/).
* Dowiedz się więcej o [obiektach typu Serwis](/docs/concepts/services-networking/service/).
{{% /capture %}}
content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+2 -2
View File
@@ -77,14 +77,14 @@ weight: 10
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>Węzły typu master zarządzają klastrem, pozostałe węzły są wykorzystywane do uruchamiania na nich aplikacji. </i></p>
<p><i>Węzły typu master zarządzają klastrem i węzłami wykorzystywanymi do uruchamiania aplikacji. </i></p>
</div>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p>Kiedy instalujesz aplikację na Kubernetes, polecasz masterowi uruchomienie kontenera z aplikacją. Master zleca uruchomienie kontenera na węzłach klastra. <b>Węzły komunikują się z masterem przy użyciu Kubernetes API</b>, wystawianego przez mastera. Użytkownicy końcowi mogą korzystać bezpośrednio z Kubernetes API do komunikacji z klastrem.</p>
<p>Kiedy instalujesz aplikację na Kubernetes, polecasz masterowi uruchomienie kontenera z aplikacją. Master zleca uruchomienie kontenera na węzłach klastra. <b>Węzły komunikują się z masterem przy użyciu <a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a></b>, wystawianego przez mastera. Użytkownicy końcowi mogą korzystać bezpośrednio z Kubernetes API do komunikacji z klastrem.</p>
<p>Klaster Kubernetes może być zainstalowany zarówno na fizycznych, jak i na maszynach wirtualnych. Aby wypróbować Kubernetes, można też wykorzystać Minikube. Minikube to "lekka" implementacja Kubernetes, która tworzy VM na maszynie lokalnej i instaluje prosty klaster składający się tylko z jednego węzła. Minikube jest dostępne na systemy Linux, macOS i Windows. Narzędzie linii poleceń Minikube obsługuje podstawowe operacje na klastrze, takie jak start, stop, informacje o stanie i usunięcie klastra. Na potrzeby tego samouczka wykorzystamy jednak terminal online z zainstalowanym już wcześniej Minikube.</p>
content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+9
View File
@@ -17,7 +17,16 @@ weight: 20
<main class="content katacoda-content">
<div class="row">
<div class="col-md-12">
<p>
Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. <a href="/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Dowiedz się więcej na temat Podów</a>.
</p>
</div>
</div>
<br>
<div class="katacoda">
<div class="katacoda__alert">
Do pracy z terminalem użyj wersji na desktop/tablet
content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html
-5
View File
@@ -81,11 +81,6 @@ weight: 10
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>Możemy połączyć tworzenie Deploymentu i Serwisu stosując opcję<br><code>--expose</code> w kubectl.</i></p>
</div>
</div>
</div>
<br>
content/pl/examples/minikube/Dockerfile
+1 -1
View File
@@ -1,4 +1,4 @@
FROM node:6.14.2
EXPOSE 8080
COPY server.js .
CMD node server.js
CMD [ "node", "server.js" ]
content/ru/docs/concepts/_index.md
+4 -4
View File
@@ -17,7 +17,7 @@ weight: 40
Чтобы работать с Kubernetes, вы используете *объекты API Kubernetes* для описания *желаемого состояния вашего кластера*: какие приложения или другие рабочие нагрузки вы хотите запустить, какие образы контейнеров они используют, количество реплик, какие сетевые и дисковые ресурсы вы хотите использовать и сделать доступными и многое другое. Вы устанавливаете желаемое состояние, создавая объекты с помощью API Kubernetes, обычно через интерфейс командной строки `kubectl`. Вы также можете напрямую использовать API Kubernetes для взаимодействия с кластером и установки или изменения желаемого состояния.
После того, как вы установили желаемое состояние, *Панель управления Kubernetes* заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Плоскость управления Kubernetes состоит из набора процессов, запущенных в вашем кластере:
После того, как вы установили желаемое состояние, *Плоскость управления Kubernetes* заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Плоскость управления Kubernetes состоит из набора процессов, запущенных в вашем кластере:
* **Мастер Kubernetes** — это коллекция из трех процессов, которые выполняются на одном узле в вашем кластере, который обозначен как главный узел. Это процессы: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) и [kube-scheduler](/docs/admin/kube-scheduler/).
* Каждый отдельный неосновной узел в вашем кластере выполняет два процесса:
@@ -43,11 +43,11 @@ Kubernetes также содержит абстракции более высо
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
## Панель управления Kubernetes
## Плоскость управления Kubernetes
Различные части панели управления Kubernetes, такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Панель управления поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления панели управления будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали.
Различные части панели управления Kubernetes, такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Плоскость управления поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления панели управления будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали.
Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Панель управления Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию.
Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Плоскость управления Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию.
### Мастер Kubernetes
content/ru/docs/concepts/overview/components.md
+1 -1
View File
@@ -23,7 +23,7 @@ card:
{{% capture body %}}
## Панель управления компонентами
## Плоскость управления компонентами
Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик).
content/ru/docs/contribute/style/style-guide.md
+1 -1
View File
@@ -74,7 +74,7 @@ PodList — это список Pod. | Pod List — это список подо
Можно | Нельзя
:--| :-----
_Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ...
Эти компоненты формируют _панель управления_. | Эти компоненты формируют **панель управления**.
Эти компоненты формируют _плоскость управления_. | Эти компоненты формируют **плоскость управления**.
{{< /table >}}
### Оформляйте как код имена файлов, директории и пути
content/ru/docs/reference/glossary/cluster.md
+1 -1
View File
@@ -14,4 +14,4 @@ tags:
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
<!--more-->
В рабочих узлах размещены поды, являющиеся компонентами приложения. Панель управления управляет рабочими узлами и подами в кластере. В промышленных средах панель управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
В рабочих узлах размещены поды, являющиеся компонентами приложения. Плоскость управления управляет рабочими узлами и подами в кластере. В промышленных средах плоскость управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
content/ru/docs/reference/glossary/node.md
+1 -1
View File
@@ -14,4 +14,4 @@ tags:
<!--more-->
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется панелью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется плоскостью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.
content/ru/docs/setup/learning-environment/minikube.md
+1 -1
View File
@@ -386,7 +386,7 @@ kubectl config use-context minikube
### Панель управления
Чтобы получить доступ к [панели управления Kubernetes](/docs/tasks/access-application-cluster/web-ui-dashboard/), запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес:
Чтобы получить доступ к [веб-панели управления Kubernetes](/docs/tasks/access-application-cluster/web-ui-dashboard/), запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес:
```shell
minikube dashboard
content/ru/docs/tutorials/hello-minikube.md
+10 -10
View File
@@ -8,7 +8,7 @@ menu:
weight: 10
post: >
<p>Готовы испачкать руки? Создайте простой кластер Kubernetes с запуском "Hello World" на Node.js</p>
card:
card:
name: tutorials
weight: 10
---
@@ -17,7 +17,7 @@ card:
Это руководство покажет вам, как запустить простое Hello World Node.js приложение
на Kubernetes используя [Minikube](/docs/getting-started-guides/minikube) и Katacoda.
Katacoda предоставляет бесплатную, встроенную в браузер Kubernetes среду.
Katacoda предоставляет бесплатную, встроенную в браузер Kubernetes среду.
{{< note >}}
Вы также можете следовать этому руководству, если вы установили [Minikube locally](/docs/tasks/tools/install-minikube/).
@@ -49,13 +49,13 @@ Katacoda предоставляет бесплатную, встроенную
## Создание кластера Minikube
1. Нажмите **Запуск Терминала**
1. Нажмите **Запуск Терминала**
{{< kat-button >}}
{{< note >}}Если у вас локально установлен Minikube, выполните `minikube start`.{{< /note >}}
2. Откройте панель Kubernetes в браузере:
2. Откройте веб-панель Kubernetes в браузере:
```shell
minikube dashboard
@@ -111,7 +111,7 @@ Katacoda предоставляет бесплатную, встроенную
```shell
kubectl config view
```
{{< note >}}Больше информации о командах `kubectl` можно найти по ссылке [обзор kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}}
## Создание сервиса
@@ -123,7 +123,7 @@ Katacoda предоставляет бесплатную, встроенную
```shell
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
```
Флаг `--type=LoadBalancer` показывает, что сервис должен быть виден вне кластера.
2. Посмотреть только что созданный сервис:
@@ -150,7 +150,7 @@ Katacoda предоставляет бесплатную, встроенную
4. Только для окружения Katacoda: Нажмите на знак "Плюс", затем нажмите **Select port to view on Host 1**.
5. Только для окружения Katacoda: Введите `30369` (порт указан рядом с `8080` в выводе сервиса), затем нажмите ???.
5. Только для окружения Katacoda: Введите `30369` (порт указан рядом с `8080` в выводе сервиса), затем нажмите ???.
Откроется окно браузера, в котором запущено ваше приложение и будет отображено сообщение "Hello World".
@@ -186,13 +186,13 @@ Katacoda предоставляет бесплатную, встроенную
storage-provisioner: enabled
storage-provisioner-gluster: disabled
```
2. Включить дополнение, например, `metrics-server`:
```shell
minikube addons enable metrics-server
```
Вывод:
```shell
@@ -233,7 +233,7 @@ Katacoda предоставляет бесплатную, встроенную
```shell
minikube addons disable metrics-server
```
Вывод:
```shell
content/zh/docs/concepts/services-networking/service.md
+3 -2
View File
@@ -169,7 +169,7 @@ also named “my-service”.
上述配置创建一个名称为 "my-service" 的 `Service` 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 `Pod` 上。
Kubernetes 为该服务分配一个 IP 地址（有时称为 "集群IP" ），该 IP 地址由服务代理使用。
(请参见下面的 [虚拟 IP 和服务代理](#virtual-ips-and-service-proxies)).
(请参见下面的 [VIP 和 Service 代理](#virtual-ips-and-service-proxies)).
服务选择器的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为 “my-service” 的Endpoint对象。
{{< note >}}
@@ -336,7 +336,7 @@ responsible for implementing a form of virtual IP for `Services` of type other
than [`ExternalName`](#externalname).
-->
## VIP 和 Service 代理
## VIP 和 Service 代理 {#virtual-ips-and-service-proxies}
在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 [`ExternalName`](#externalname) 的形式。
@@ -828,6 +828,7 @@ You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expos
Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。
`Type` 的取值以及行为如下：
* `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。
* [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。`NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。
* [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。
content/zh/docs/reference/glossary/applications.md
+1
View File
@@ -23,4 +23,5 @@ tags:
- fundamental
---
-->
各种容器化应用运行所在的层。
content/zh/docs/reference/glossary/control-plane.md
+2 -1
View File
@@ -25,7 +25,8 @@ tags:
- fundamental
---
-->
<!--
The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.
-->
容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。
容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。
content/zh/docs/reference/glossary/pod-lifecycle.md
+21 -19
View File
@@ -1,3 +1,17 @@
---
title: Pod 生命周期
id: pod-lifecycle
date: 2019-02-17
full-link: /docs/concepts/workloads/pods/pod-lifecycle/
related:
- pod
- container
tags:
- fundamental
short_description: >
关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
---
<!--
---
title: Pod Lifecycle
@@ -11,29 +25,17 @@ tags:
- fundamental
short_description: >
A high-level summary of what phase the Pod is in within its lifecyle.
---
A high-level summary of what phase the Pod is in within its lifecyle.
<!--more-->
-->
---
title: Pod 生命周期
id: pod-lifecycle
date: 2019-02-17
full-link: /docs/concepts/workloads/pods/pod-lifecycle/
related:
- pod
- container
tags:
- fundamental
short_description: >
关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
---
<!--
A high-level summary of what phase the Pod is in within its lifecyle.
-->
关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
<!--more-->
<!--more-->
<!--
The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is a high level summary of where a Pod is in its lifecyle. A Pod’s `status` field is a [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) object, which has a `phase` field that displays one of the following phases: Running, Pending, Succeeded, Failed, Unknown, Completed, or CrashLoopBackOff.
-->
content/zh/docs/reference/glossary/service.md
+1 -1
View File
@@ -4,7 +4,7 @@ id: service
date: 2018-04-12
full_link: /docs/concepts/services-networking/service/
short_description: >
A way to expose an application running on a set of Pods as a network service.
将运行在一组 {{< glossary_tooltip text="Pods" term_id="pod" >}} 上的应用程序公开为网络服务的抽象方法。
aka:
tags:
content/zh/docs/reference/glossary/storage-class.md
+21 -17
View File
@@ -1,20 +1,3 @@
<!--
---
title: Storage Class
id: storageclass
date: 2018-04-12
full_link: /docs/concepts/storage/storage-classes
short_description: >
A StorageClass provides a way for administrators to describe different available storage types.
aka:
tags:
- core-object
- storage
---
A StorageClass provides a way for administrators to describe different available storage types.
-->
---
title: 存储类别
id: storageclass
@@ -29,9 +12,30 @@ tags:
- storage
---
<!--
---
title: Storage Class
id: storageclass
date: 2018-04-12
full_link: /docs/concepts/storage/storage-classes
short_description: >
A StorageClass provides a way for administrators to describe different available storage types.
aka:
tags:
- core-object
- storage
---
-->
<!--
A StorageClass provides a way for administrators to describe different available storage types.
-->
StorageClass 是管理员用来描述不同的可用存储类型的一种方法。
<!--more-->
<!--
StorageClasses can map to quality-of-service levels, backup policies, or to arbitrary policies determined by cluster administrators. Each StorageClass contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a {{< glossary_tooltip text="Persistent Volume" term_id="persistent-volume" >}} belonging to the class needs to be dynamically provisioned. Users can request a particular class using the name of a StorageClass object.
-->
content/zh/docs/reference/glossary/upstream.md
+1 -1
View File
@@ -4,7 +4,7 @@ id: upstream
date: 2018-04-12
full_link:
short_description: >
May refer to: core Kubernetes or the source repo from which a repo was forked.
可以参考：核心 Kubernetes 仓库或作为当前仓库派生来源的来源仓库。
aka:
tags:
content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
+61 -7
View File
@@ -3,8 +3,21 @@ title: 为容器设置环境变量
content_template: templates/task
---
<!--
---
title: Define Environment Variables for a Container
content_template: templates/task
weight: 20
---
-->
{{% capture overview %}}
<!--
This page shows how to define environment variables for a container
in a Kubernetes Pod.
-->
本页将展示如何为 kubernetes Pod 下的容器设置环境变量。
{{% /capture %}}
@@ -19,46 +32,81 @@ content_template: templates/task
{{% capture steps %}}
<!--
## Define an environment variable for a container
-->
## 为容器设置一个环境变量
<!--
When you create a Pod, you can set environment variables for the containers
that run in the Pod. To set environment variables, include the `env` or
`envFrom` field in the configuration file.
-->
创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 `env` 或者 `envFrom` 字段来设置环境变量。
<!--
In this exercise, you create a Pod that runs one container. The configuration
file for the Pod defines an environment variable with name `DEMO_GREETING` and
value `"Hello from the environment"`. Here is the configuration file for the
Pod:
-->
本示例中，将创建一个只包含单个容器的 Pod。Pod 的配置文件中设置环境变量的名称为 `DEMO_GREETING`，
其值为 `"Hello from the environment"`。下面是 Pod 的配置文件内容：
{{< codenew file="pods/inject/envars.yaml" >}}
<!--
1. Create a Pod based on the YAML configuration file:
-->
1. 基于 YAML 文件创建一个 Pod：
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
```
<!--
1. List the running Pods:
-->
1. 获取一下当前正在运行的 Pods 信息：
```shell
kubectl get pods -l purpose=demonstrate-envars
```
<!--
The output is similar to this:
-->
查询结果应为：
```shell
NAME READY STATUS RESTARTS AGE
envar-demo 1/1 Running 0 9s
```
<!--
1. Get a shell to the container running in your Pod:
-->
1. 进入该 Pod 下的容器并打开一个命令终端：
```shell
kubectl exec -it envar-demo -- /bin/bash
```
<!--
1. In your shell, run the `printenv` command to list the environment variables.
-->
1. 在命令终端中通过执行 `printenv` 打印出环境变量。
```shell
root@envar-demo:/# printenv
```
<!--
The output is similar to this:
-->
打印结果应为：
```shell
@@ -69,7 +117,10 @@ content_template: templates/task
DEMO_GREETING=Hello from the environment
DEMO_FAREWELL=Such a sweet sorrow
```
<!--
1. To exit the shell, enter `exit`.
-->
1. 通过键入 `exit` 退出命令终端。
<!--
@@ -120,11 +171,14 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
{{% capture whatsnext %}}
<!--
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
-->
* 有关环境变量的更多信息，请参阅[这里](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)。
* 有关如何通过环境变量来使用 Secret，请参阅[这里](/docs/user-guide/secrets/#using-secrets-as-environment-variables)。
* 关于 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) 资源的信息。
{{% /capture %}}
content/zh/docs/tasks/job/parallel-processing-expansion.md
+341 -302
View File
@@ -1,302 +1,341 @@
---
title: 使用扩展进行并行处理
content_template: templates/concept
weight: 20
---
<!--
---
title: Parallel Processing using Expansions
content_template: templates/concept
weight: 20
---
-->
{{% capture overview %}}
<!--
In this example, we will run multiple Kubernetes Jobs created from
a common template. You may want to be familiar with the basic,
non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) first.
-->
在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes 作业。您可能希望熟悉
[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本、非并行使用。
{{% /capture %}}
{{% capture body %}}
<!--
## Basic Template Expansion
-->
## 基本模板扩展
<!--
First, download the following template of a job to a file called `job-tmpl.yaml`
-->
首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中
{{< codenew file="application/job/job-tmpl.yaml" >}}
<!--
Unlike a *pod template*, our *job template* is not a Kubernetes API type. It is just
a yaml representation of a Job object that has some placeholders that need to be filled
in before it can be used. The `$ITEM` syntax is not meaningful to Kubernetes.
-->
与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是作业对象的 yaml 表示，
YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。
<!--
In this example, the only processing the container does is to `echo` a string and sleep for a bit.
In a real use case, the processing would be some substantial computation, such as rendering a frame
of a movie, or processing a range of rows in a database. The `$ITEM` parameter would specify for
example, the frame number or the row range.
-->
在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并休眠一段时间。
在真实的用例中，处理将是一些重要的计算，例如呈现电影的帧，或者处理数据库中的一系列行。例如，`$ITEM` 参数将指定帧号或行范围。
<!--
This Job and its Pod template have a label: `jobgroup=jobexample`. There is nothing special
to the system about this label.
This label makes it convenient to operate on all the jobs in this group at once.
We also put the same label on the pod template so that we can check on all Pods of these Jobs
with a single command.
After the job is created, the system will add more labels that distinguish one Job's pods
from another Job's pods.
Note that the label key `jobgroup` is not special to Kubernetes. You can pick your own label scheme.
-->
这个作业及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。
这个标签使得我们可以方便地同时操作组中的所有作业。
我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些作业的所有 pod。
创建作业之后，系统将添加更多的标签来区分一个作业的 pod 和另一个作业的 pod。
注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。
<!--
Next, expand the template into multiple files, one for each item to be processed.
-->
下一步，将模板展开到多个文件中，每个文件对应要处理的项。
```shell
# Expand files into a temporary directory
$ mkdir ./jobs
$ for i in apple banana cherry
do
cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
done
```
<!--
Check if it worked:
-->
检查是否工作正常：
```shell
$ ls jobs/
job-apple.yaml
job-banana.yaml
job-cherry.yaml
```
<!--
Here, we used `sed` to replace the string `$ITEM` with the loop variable.
You could use any type of template language (jinja2, erb) or write a program
to generate the Job objects.
-->
在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。
您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成作业对象。
<!--
Next, create all the jobs with one kubectl command:
-->
接下来，使用 kubectl 命令创建所有作业：
```shell
$ kubectl create -f ./jobs
job "process-item-apple" created
job "process-item-banana" created
job "process-item-cherry" created
```
<!--
Now, check on the jobs:
-->
现在，检查这些作业：
```shell
$ kubectl get jobs -l jobgroup=jobexample
NAME DESIRED SUCCESSFUL AGE
process-item-apple 1 1 31s
process-item-banana 1 1 31s
process-item-cherry 1 1 31s
```
<!--
Here we use the `-l` option to select all jobs that are part of this
group of jobs. (There might be other unrelated jobs in the system that we
do not care to see.)
-->
在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。)
<!--
We can check on the pods as well using the same label selector:
-->
我们可以检查 pod 以及使用同样地标签选择器：
```shell
$ kubectl get pods -l jobgroup=jobexample
NAME READY STATUS RESTARTS AGE
process-item-apple-kixwv 0/1 Completed 0 4m
process-item-banana-wrsf7 0/1 Completed 0 4m
process-item-cherry-dnfu9 0/1 Completed 0 4m
```
<!--
There is not a single command to check on the output of all jobs at once,
but looping over all the pods is pretty easy:
-->
没有一个命令可以一次检查所有作业的输出，但是循环遍历所有 pod 非常简单：
```shell
$ for p in $(kubectl get pods -l jobgroup=jobexample -o name)
do
kubectl logs $p
done
Processing item apple
Processing item banana
Processing item cherry
```
<!--
## Multiple Template Parameters
-->
## 多个模板参数
<!--
In the first example, each instance of the template had one parameter, and that parameter was also
used as a label. However label keys are limited in [what characters they can
contain](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
-->
在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。
但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。
<!--
This slightly more complex example uses the jinja2 template language to generate our objects.
We will use a one-line python script to convert the template to a file.
-->
这个稍微复杂一点的示例使用 jinja2 板语言来生成我们的对象。
我们将使用一行 python 脚本将模板转换为文件。
<!--
First, copy and paste the following template of a Job object, into a file called `job.yaml.jinja2`:
-->
首先，粘贴作业对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中：
```liquid
{%- set params = [{ "name": "apple", "url": "http://www.orangepippin.com/apples", },
{ "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", },
{ "name": "raspberry", "url": "https://www.raspberrypi.org/" }]
%}
{%- for p in params %}
{%- set name = p["name"] %}
{%- set url = p["url"] %}
apiVersion: batch/v1
kind: Job
metadata:
name: jobexample-{{ name }}
labels:
jobgroup: jobexample
spec:
template:
metadata:
name: jobexample
labels:
jobgroup: jobexample
spec:
containers:
- name: c
image: busybox
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
restartPolicy: Never
---
{%- endfor %}
```
<!--
The above template defines parameters for each job object using a list of
python dicts (lines 1-4). Then a for loop emits one job yaml object
for each set of parameters (remaining lines).
We take advantage of the fact that multiple yaml documents can be concatenated
with the `---` separator (second to last line).
.) We can pipe the output directly to kubectl to
create the objects.
-->
上面的模板使用 python dicts 列表（第1-4行）定义每个作业对象的参数。
然后 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。
我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。
我们可以将输出直接传递给 kubectl 来创建对象。
<!--
You will need the jinja2 package if you do not already have it: `pip install --user jinja2`.
Now, use this one-line python program to expand the template:
-->
如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。
现在，使用这个一行 python 程序来展开模板:
```shell
alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
```
<!--
The output can be saved to a file, like this:
-->
输出可以保存到一个文件，像这样：
```shell
cat job.yaml.jinja2 | render_template > jobs.yaml
```
<!--
Or sent directly to kubectl, like this:
-->
或直接发送到 kubectl，如下所示：
```shell
cat job.yaml.jinja2 | render_template | kubectl create -f -
```
<!--
## Alternatives
-->
## 替代方案
<!--
If you have a large number of job objects, you may find that:
-->
如果您有大量作业对象，您可能会发现：
<!--
- Even using labels, managing so many Job objects is cumbersome.
- You exceed resource quota when creating all the Jobs at once,
and do not want to wait to create them incrementally.
- Very large numbers of jobs created at once overload the
Kubernetes apiserver, controller, or scheduler.
-->
- 即使使用标签，管理这么多作业对象也很麻烦。
- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建作业并等待其完成。
- 同时创建的大量作业会使 Kubernetes apiserver、控制器或调度程序过载。
<!--
In this case, you can consider one of the
other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
-->
在这种情况下，您可以考虑
其他[工作模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。
{{% /capture %}}
---
title: 使用扩展进行并行处理
content_template: templates/concept
min-kubernetes-server-version: v1.8
weight: 20
---
<!--
---
title: Parallel Processing using Expansions
content_template: templates/concept
min-kubernetes-server-version: v1.8
weight: 20
---
-->
{{% capture overview %}}
<!--
In this example, we will run multiple Kubernetes Jobs created from
a common template. You may want to be familiar with the basic,
non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) first.
-->
在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes Job。您可能需要先熟悉 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本概念、非并行以及如何使用它。
{{% /capture %}}
{{% capture body %}}
<!--
## Basic Template Expansion
-->
## 基本模板扩展
<!--
First, download the following template of a job to a file called `job-tmpl.yaml`
-->
首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。
{{< codenew file="application/job/job-tmpl.yaml" >}}
<!--
Unlike a *pod template*, our *job template* is not a Kubernetes API type. It is just
a yaml representation of a Job object that has some placeholders that need to be filled
in before it can be used. The `$ITEM` syntax is not meaningful to Kubernetes.
-->
与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是 Job 对象的 yaml 表示，
YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。
<!--
In this example, the only processing the container does is to `echo` a string and sleep for a bit.
In a real use case, the processing would be some substantial computation, such as rendering a frame
of a movie, or processing a range of rows in a database. The `$ITEM` parameter would specify for
example, the frame number or the row range.
-->
在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并睡眠一段时间。
在真实的用例中，处理将是一些重要的计算，例如渲染电影的一帧，或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。
<!--
This Job and its Pod template have a label: `jobgroup=jobexample`. There is nothing special
to the system about this label. This label
makes it convenient to operate on all the jobs in this group at once.
We also put the same label on the pod template so that we can check on all Pods of these Jobs
with a single command.
After the job is created, the system will add more labels that distinguish one Job's pods
from another Job's pods.
Note that the label key `jobgroup` is not special to Kubernetes. You can pick your own label scheme.
-->
这个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。
这个标签使得我们可以方便地同时操作组中的所有作业。
我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些 Job 的所有 pod。
创建作业之后，系统将添加更多的标签来区分一个 Job 的 pod 和另一个 Job 的 pod。
注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。
<!--
Next, expand the template into multiple files, one for each item to be processed.
-->
下一步，将模板展开到多个文件中，每个文件对应要处理的项。
```shell
# 下载 job-templ.yaml
curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
# 创建临时目录，并且在目录中创建 job yaml 文件
mkdir ./jobs
for i in apple banana cherry
do
cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
done
```
<!--
Check if it worked:
-->
检查是否工作正常：
```shell
ls jobs/
```
<!--
The output is similar to this:
-->
输出类似以下内容：
```
job-apple.yaml
job-banana.yaml
job-cherry.yaml
```
<!--
Here, we used `sed` to replace the string `$ITEM` with the loop variable.
You could use any type of template language (jinja2, erb) or write a program
to generate the Job objects.
-->
在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。
您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成 Job 对象。
<!--
Next, create all the jobs with one kubectl command:
-->
接下来，使用 kubectl 命令创建所有作业：
```shell
kubectl create -f ./jobs
```
<!--
The output is similar to this:
-->
输出类似以下内容：
```
job.batch/process-item-apple created
job.batch/process-item-banana created
job.batch/process-item-cherry created
```
<!--
Now, check on the jobs:
-->
现在，检查这些作业：
```shell
kubectl get jobs -l jobgroup=jobexample
```
<!--
The output is similar to this:
-->
输出类似以下内容：
```
NAME COMPLETIONS DURATION AGE
process-item-apple 1/1 14s 20s
process-item-banana 1/1 12s 20s
process-item-cherry 1/1 12s 20s
```
<!--
Here we use the `-l` option to select all jobs that are part of this
group of jobs. (There might be other unrelated jobs in the system that we
do not care to see.)
-->
在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。)
<!--
We can check on the pods as well using the same label selector:
-->
使用同样的标签选择器，我们还可以检查 pods：
```shell
kubectl get pods -l jobgroup=jobexample
```
<!--
The output is similar to this:
-->
输出类似以下内容：
```
NAME READY STATUS RESTARTS AGE
process-item-apple-kixwv 0/1 Completed 0 4m
process-item-banana-wrsf7 0/1 Completed 0 4m
process-item-cherry-dnfu9 0/1 Completed 0 4m
```
<!--
We can use this single command to check on the output of all jobs at once:
-->
我们可以使用以下操作命令一次性地检查所有作业的输出：
```shell
kubectl logs -f -l jobgroup=jobexample
```
<!--
The output is:
-->
输出内容为：
```
Processing item apple
Processing item banana
Processing item cherry
```
<!--
## Multiple Template Parameters
-->
## 多个模板参数
<!--
In the first example, each instance of the template had one parameter, and that parameter was also
used as a label. However label keys are limited in [what characters they can
contain](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
-->
在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。
但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。
<!--
This slightly more complex example uses the jinja2 template language to generate our objects.
We will use a one-line python script to convert the template to a file.
-->
这个稍微复杂一点的示例使用 jinja2 模板语言来生成我们的对象。
我们将使用一行 python 脚本将模板转换为文件。
<!--
First, copy and paste the following template of a Job object, into a file called `job.yaml.jinja2`:
-->
首先，粘贴 Job 对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中：
```liquid
{%- set params = [{ "name": "apple", "url": "https://www.orangepippin.com/varieties/apples", },
{ "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", },
{ "name": "raspberry", "url": "https://www.raspberrypi.org/" }]
%}
{%- for p in params %}
{%- set name = p["name"] %}
{%- set url = p["url"] %}
apiVersion: batch/v1
kind: Job
metadata:
name: jobexample-{{ name }}
labels:
jobgroup: jobexample
spec:
template:
metadata:
name: jobexample
labels:
jobgroup: jobexample
spec:
containers:
- name: c
image: busybox
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
restartPolicy: Never
---
{%- endfor %}
```
<!--
The above template defines parameters for each job object using a list of
python dicts (lines 1-4). Then a for loop emits one job yaml object
for each set of parameters (remaining lines).
We take advantage of the fact that multiple yaml documents can be concatenated
with the `---` separator (second to last line).
.) We can pipe the output directly to kubectl to
create the objects.
-->
上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。
然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。
我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。
我们可以将输出直接传递给 kubectl 来创建对象。
<!--
You will need the jinja2 package if you do not already have it: `pip install --user jinja2`.
Now, use this one-line python program to expand the template:
-->
如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。
现在，使用这个一行 python 程序来展开模板:
```shell
alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
```
<!--
The output can be saved to a file, like this:
-->
输出可以保存到一个文件，像这样：
```shell
cat job.yaml.jinja2 | render_template > jobs.yaml
```
<!--
Or sent directly to kubectl, like this:
-->
或直接发送到 kubectl，如下所示：
```shell
cat job.yaml.jinja2 | render_template | kubectl apply -f -
```
<!--
## Alternatives
-->
## 替代方案
<!--
If you have a large number of job objects, you may find that:
-->
如果您有大量作业对象，您可能会发现：
<!--
- Even using labels, managing so many Job objects is cumbersome.
- You exceed resource quota when creating all the Jobs at once,
and do not want to wait to create them incrementally.
- Very large numbers of jobs created at once overload the
Kubernetes apiserver, controller, or scheduler.
-->
- 即使使用标签，管理这么多 Job 对象也很麻烦。
- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建 Job 并等待其完成。
- 同时创建大量作业会使 Kubernetes apiserver、控制器或者调度器负压过大。
<!--
In this case, you can consider one of the
other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
-->
在这种情况下，您可以考虑其他的[作业模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。
{{% /capture %}}
content/zh/docs/tutorials/hello-minikube.md
+164 -230
View File
@@ -30,12 +30,13 @@ card:
-->
{{% capture overview %}}
<!--
This tutorial shows you how to run a simple Hello World Node.js app
on Kubernetes using [Minikube](/docs/getting-started-guides/minikube) and Katacoda.
on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda.
Katacoda provides a free, in-browser Kubernetes environment.
-->
本教程向您展示如何使用 [Minikube](/docs/getting-started-guides/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。
本教程向您展示如何使用 [Minikube](/docs/setup/learning-environment/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。
{{< note >}}
<!--
@@ -48,6 +49,7 @@ You can also follow this tutorial if you've installed [Minikube locally](/docs/t
{{% /capture %}}
{{% capture objectives %}}
<!--
* Deploy a hello world application to Minikube.
* Run the app.
@@ -60,6 +62,7 @@ You can also follow this tutorial if you've installed [Minikube locally](/docs/t
{{% /capture %}}
{{% capture prerequisites %}}
<!--
This tutorial provides a container image built from the following files:
-->
@@ -68,6 +71,7 @@ This tutorial provides a container image built from the following files:
{{< codenew language="js" file="minikube/server.js" >}}
{{< codenew language="conf" file="minikube/Dockerfile" >}}
<!--
For more information on the `docker build` command, read the [Docker documentation](https://docs.docker.com/engine/reference/commandline/build/).
-->
@@ -81,39 +85,36 @@ For more information on the `docker build` command, read the [Docker documentati
## Create a Minikube cluster
1. Click **Launch Terminal**
-->
## 创建 Minikube 集群
1. 点击 **启动终端**
{{< kat-button >}}
{{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}}
<!--
2. Open the Kubernetes dashboard in a browser:
```shell
minikube dashboard
```
3. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click **Select port to view on Host 1**.
4. Katacoda environment only: Type `30000`, and then click **Display Port**.
-->
## 创建 Minikube 集群
1. 点击 **启动终端**
{{< kat-button >}}
{{< note >}}如果您本地安装了 Minikube, 运行 `minikube start`.{{< /note >}}
2. 在浏览器中打开 Kubernetes dashboard：
```shell
minikube dashboard
```
<!--
3. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click **Select port to view on Host 1**.
4. Katacoda environment only: Type `30000`, and then click **Display Port**.
-->
3. 仅限 Katacoda 环境：在终端窗口的顶部，单击加号，然后单击 **选择要在主机 1 上查看的端口**。
4. 仅限 Katacoda 环境：输入“30000”，然后单击 **显示端口**。
<!--
## Create a Deployment
A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
@@ -122,99 +123,88 @@ tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
Pod and restarts the Pod's Container if it terminates. Deployments are the
recommended way to manage the creation and scaling of Pods.
1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
Pod runs a Container based on the provided Docker image.
```shell
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
```
2. View the Deployment:
```shell
kubectl get deployments
```
Output:
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
hello-node 1 1 1 1 1m
```
3. View the Pod:
```shell
kubectl get pods
```
Output:
```shell
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
```
4. View cluster events:
```shell
kubectl get events
```
5. View the `kubectl` configuration:
```shell
kubectl config view
```
{{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
-->
## 创建 Deployment
Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。
<!--
1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
Pod runs a Container based on the provided Docker image.
-->
1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker 镜像运行 Container。
```shell
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
```
<!--
2. View the Deployment:
-->
2. 查看 Deployment：
```shell
kubectl get deployments
```
输出:
<!--
The output is similar to:
-->
输出结果类似于这样：
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
hello-node 1 1 1 1 1m
```
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
```
<!--
3. View the Pod:
-->
3. 查看 Pod：
```shell
kubectl get pods
```
输出:
```shell
<!--
The output is similar to:
-->
输出结果类似于这样：
```
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
```
<!--
4. View cluster events:
-->
4. 查看集群事件：
```shell
kubectl get events
```
<!--
5. View the `kubectl` configuration:
-->
5. 查看 `kubectl` 配置：
```shell
kubectl config view
```
<!--
{{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
-->
{{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/docs/user-guide/kubectl-overview/)。{{< /note >}}
<!--
@@ -224,51 +214,16 @@ By default, the Pod is only accessible by its internal IP address within the
Kubernetes cluster. To make the `hello-node` Container accessible from outside the
Kubernetes virtual network, you have to expose the Pod as a
Kubernetes [*Service*](/docs/concepts/services-networking/service/).
1. Expose the Pod to the public internet using the `kubectl expose` command:
```shell
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
```
The `--type=LoadBalancer` flag indicates that you want to expose your Service
outside of the cluster.
2. View the Service you just created:
```shell
kubectl get services
```
Output:
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
```
On cloud providers that support load balancers,
an external IP address would be provisioned to access the Service. On Minikube,
the `LoadBalancer` type makes the Service accessible through the `minikube service`
command.
3. Run the following command:
```shell
minikube service hello-node
```
4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**.
5. Katacoda environment only: Type `30369` (see port opposite to `8080` in services output), and then click
This opens up a browser window that serves your app and shows the "Hello World" message.
-->
## 创建 Service
默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。要使得 `hello-node` 容器可以从 Kubernetes 虚拟网络的外部访问，您必须将 Pod 暴露为 Kubernetes [*Service*](/docs/concepts/services-networking/service/)。
<!--
1. Expose the Pod to the public internet using the `kubectl expose` command:
-->
1. 使用 `kubectl expose` 命令将 Pod 暴露给公网：
```shell
@@ -278,117 +233,69 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
The `--type=LoadBalancer` flag indicates that you want to expose your Service
outside of the cluster.
<!--
2. View the Service you just created:
-->
2. 查看您刚刚创建的服务:
```shell
kubectl get services
```
输出:
<!--
The output is similar to:
-->
```shell
输出结果类似于这样:
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
```
<!--
On cloud providers that support load balancers,
an external IP address would be provisioned to access the Service. On Minikube,
the `LoadBalancer` type makes the Service accessible through the `minikube service`
command.
-->
在支持负载均衡器的云服务提供商上，将提供一个外部 IP 来访问该服务。在 Minikube 上，`LoadBalancer` 使得服务可以通过命令 `minikube service` 访问。
<!--
3. Run the following command:
-->
3. 运行下面的命令：
```shell
minikube service hello-node
```
<!--
4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**.
-->
4. 仅限 Katacoda 环境：单击加号，然后单击 **选择要在主机 1 上查看的端口**。
5. 仅限 Katacoda 环境：输入 `30369`（请参阅服务输出中与 `8080` 相对的端口），然后单击
<!--
5. Katacoda environment only: Note the 5 digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`.
This opens up a browser window that serves your app and shows the "Hello World" message.
-->
5. 仅限 Katacoda 环境：请注意在 service 输出中与 `8080` 对应的长度为 5 位的端口号。此端口号是随机生成的，可能与您不同。在端口号文本框中输入您自己的端口号，然后单击显示端口。如果是上面那个例子，就需要输入 `30369`。
这将打开一个浏览器窗口，为您的应用程序提供服务并显示 “Hello World” 消息。
<!--
## Enable addons
Minikube has a set of built-in addons that can be enabled, disabled and opened in the local Kubernetes environment.
Minikube has a set of built-in {{< glossary_tooltip text="addons" term_id="addons" >}} that can be enabled, disabled and opened in the local Kubernetes environment.
1. List the currently supported addons:
```shell
minikube addons list
```
Output:
```shell
addon-manager: enabled
coredns: disabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
heapster: disabled
ingress: disabled
kube-dns: enabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
```
2. Enable an addon, for example, `heapster`:
```shell
minikube addons enable heapster
```
Output:
```shell
heapster was successfully enabled
```
3. View the Pod and Service you just created:
```shell
kubectl get pod,svc -n kube-system
```
Output:
```shell
NAME READY STATUS RESTARTS AGE
pod/heapster-9jttx 1/1 Running 0 26s
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m
pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/heapster ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/kubernetes-dashboard NodePort 10.109.29.1 <none> 80:30000/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
4. Disable `heapster`:
```shell
minikube addons disable heapster
```
Output:
```shell
heapster was successfully disabled
```
-->
## 启用插件
Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用、禁用和打开。
Minikube 有一组内置的 {{< glossary_tooltip text="插件" term_id="addons" >}}，可以在本地 Kubernetes 环境中启用、禁用和打开。
1. 列出当前支持的插件：
@@ -396,37 +303,55 @@ Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用
minikube addons list
```
输出:
<!--
The output is similar to:
-->
```shell
输出结果类似于这样：
```
addon-manager: enabled
coredns: disabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
heapster: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
kube-dns: enabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
```
2. 启用插件，例如 `heapster`：
<!--
2. Enable an addon, for example, `metrics-server`:
-->
2. 启用插件，例如 `metrics-server`：
```shell
minikube addons enable heapster
minikube addons enable metrics-server
```
输出:
<!--
The output is similar to:
-->
输出结果类似于这样：
```shell
heapster was successfully enabled
```
metrics-server was successfully enabled
```
<!--
3. View the Pod and Service you just created:
-->
3. 查看刚才创建的 Pod 和 Service：
@@ -434,59 +359,60 @@ Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用
kubectl get pod,svc -n kube-system
```
输出:
<!--
The output is similar to:
-->
```shell
输出结果类似于这样：
```
NAME READY STATUS RESTARTS AGE
pod/heapster-9jttx 1/1 Running 0 26s
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m
pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/heapster ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/kubernetes-dashboard NodePort 10.109.29.1 <none> 80:30000/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
4. 禁用 `heapster`：
<!--
4. Disable `metrics-server`:
-->
4. 禁用 `metrics-server`：
```shell
minikube addons disable heapster
minikube addons disable metrics-server
```
输出:
<!--
The output is similar to:
-->
```shell
heapster was successfully disabled
输出结果类似于这样：
```
metrics-server was successfully disabled
```
<!--
## Clean up
Now you can clean up the resources you created in your cluster:
```shell
kubectl delete service hello-node
kubectl delete deployment hello-node
```
Optionally, stop the Minikube virtual machine (VM):
```shell
minikube stop
```
Optionally, delete the Minikube VM:
```shell
minikube delete
```
-->
## 清理
现在可以清理您在集群中创建的资源：
@@ -496,13 +422,21 @@ kubectl delete service hello-node
kubectl delete deployment hello-node
```
可以停止 Minikube VM：
<!--
Optionally, stop the Minikube virtual machine (VM):
-->
可选的，停止 Minikube 虚拟机（VM）：
```shell
minikube stop
```
或者，删除 Minikube VM：
<!--
Optionally, delete the Minikube VM:
-->
可选的，删除 Minikube 虚拟机（VM）：
```shell
minikube delete
@@ -514,11 +448,11 @@ minikube delete
<!--
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
* Learn more about [Deploying applications](/docs/user-guide/deploying-applications/).
* Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/).
* Learn more about [Service objects](/docs/concepts/services-networking/service/).
-->
* 进一步了解 [Deployment 对象](/docs/concepts/workloads/controllers/deployment/)。
* 学习更多关于 [部署应用](/docs/user-guide/deploying-applications/)。
* 学习更多关于 [部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
* 学习更多关于 [Service 对象](/docs/concepts/services-networking/service/)。
{{% /capture %}}
content/zh/docs/tutorials/kubernetes-basics/_index.html
+5
View File
@@ -1,6 +1,11 @@
---
title: 学习 Kubernetes 基础知识
linkTitle: 学习 Kubernetes 基础知识
weight: 10
card:
name: tutorials
weight: 20
title: 基础知识介绍
---
<!DOCTYPE html>
content/zh/examples/admin/cloud/ccm-example.yaml
+69 -69
View File
@@ -1,69 +1,69 @@
# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster.
# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
# Note that this Daemonset will not work straight out of the box for your cloud, this is
# meant to be a guideline.
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: cloud-controller-manager
namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: system:cloud-controller-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: cloud-controller-manager
namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
k8s-app: cloud-controller-manager
name: cloud-controller-manager
namespace: kube-system
spec:
selector:
matchLabels:
k8s-app: cloud-controller-manager
template:
metadata:
labels:
k8s-app: cloud-controller-manager
spec:
serviceAccountName: cloud-controller-manager
containers:
- name: cloud-controller-manager
# for in-tree providers we use k8s.gcr.io/cloud-controller-manager
# this can be replaced with any other image for out-of-tree providers
image: k8s.gcr.io/cloud-controller-manager:v1.8.0
command:
- /usr/local/bin/cloud-controller-manager
- --cloud-provider=<YOUR_CLOUD_PROVIDER> # Add your own cloud provider here!
- --leader-elect=true
- --use-service-account-credentials
# these flags will vary for every cloud provider
- --allocate-node-cidrs=true
- --configure-cloud-routes=true
- --cluster-cidr=172.17.0.0/16
tolerations:
# this is required so CCM can bootstrap itself
- key: node.cloudprovider.kubernetes.io/uninitialized
value: "true"
effect: NoSchedule
# this is to have the daemonset runnable on master nodes
# the taint may vary depending on your cluster setup
- key: node-role.kubernetes.io/master
effect: NoSchedule
# this is to restrict CCM to only run on master nodes
# the node selector may vary depending on your cluster setup
nodeSelector:
node-role.kubernetes.io/master: ""
# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster.
# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
# Note that this Daemonset will not work straight out of the box for your cloud, this is
# meant to be a guideline.
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: cloud-controller-manager
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:cloud-controller-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: cloud-controller-manager
namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
k8s-app: cloud-controller-manager
name: cloud-controller-manager
namespace: kube-system
spec:
selector:
matchLabels:
k8s-app: cloud-controller-manager
template:
metadata:
labels:
k8s-app: cloud-controller-manager
spec:
serviceAccountName: cloud-controller-manager
containers:
- name: cloud-controller-manager
# for in-tree providers we use k8s.gcr.io/cloud-controller-manager
# this can be replaced with any other image for out-of-tree providers
image: k8s.gcr.io/cloud-controller-manager:v1.8.0
command:
- /usr/local/bin/cloud-controller-manager
- --cloud-provider=[YOUR_CLOUD_PROVIDER] # Add your own cloud provider here!
- --leader-elect=true
- --use-service-account-credentials
# these flags will vary for every cloud provider
- --allocate-node-cidrs=true
- --configure-cloud-routes=true
- --cluster-cidr=172.17.0.0/16
tolerations:
# this is required so CCM can bootstrap itself
- key: node.cloudprovider.kubernetes.io/uninitialized
value: "true"
effect: NoSchedule
# this is to have the daemonset runnable on master nodes
# the taint may vary depending on your cluster setup
- key: node-role.kubernetes.io/master
effect: NoSchedule
# this is to restrict CCM to only run on master nodes
# the node selector may vary depending on your cluster setup
nodeSelector:
node-role.kubernetes.io/master: ""
content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml
+33 -33
View File
@@ -1,33 +1,33 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: dns-autoscaler
namespace: kube-system
labels:
k8s-app: dns-autoscaler
spec:
selector:
matchLabels:
k8s-app: dns-autoscaler
template:
metadata:
labels:
k8s-app: dns-autoscaler
spec:
containers:
- name: autoscaler
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
resources:
requests:
cpu: "20m"
memory: "10Mi"
command:
- /cluster-proportional-autoscaler
- --namespace=kube-system
- --configmap=dns-autoscaler
- --target=<SCALE_TARGET>
# When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
# If using small nodes, "nodesPerReplica" should dominate.
- --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
- --logtostderr=true
- --v=2
apiVersion: apps/v1
kind: Deployment
metadata:
name: dns-autoscaler
namespace: kube-system
labels:
k8s-app: dns-autoscaler
spec:
selector:
matchLabels:
k8s-app: dns-autoscaler
template:
metadata:
labels:
k8s-app: dns-autoscaler
spec:
containers:
- name: autoscaler
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.6.0
resources:
requests:
cpu: 20m
memory: 10Mi
command:
- /cluster-proportional-autoscaler
- --namespace=kube-system
- --configmap=dns-autoscaler
- --target=<SCALE_TARGET>
# When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
# If using small nodes, "nodesPerReplica" should dominate.
- --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
- --logtostderr=true
- --v=2
content/zh/examples/admin/dns/dnsutils.yaml
+14
View File
@@ -0,0 +1,14 @@
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
namespace: default
spec:
containers:
- name: dnsutils
image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
restartPolicy: Always
content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml
+2 -2
View File
@@ -1,10 +1,10 @@
apiVersion: v1
kind: Pod
metadata:
name: constraints-cpu-demo-4
name: constraints-cpu-demo-3
spec:
containers:
- name: constraints-cpu-demo-4-ctr
- name: constraints-cpu-demo-3-ctr
image: nginx
resources:
limits:
content/zh/examples/admin/resource/quota-objects-pvc-2.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-quota-demo-2
spec:
content/zh/examples/admin/resource/quota-objects-pvc.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-quota-demo
spec:
content/zh/examples/admin/sched/my-scheduler.yaml
+67 -67
View File
@@ -1,67 +1,67 @@
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-scheduler
namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: my-scheduler-as-kube-scheduler
subjects:
- kind: ServiceAccount
name: my-scheduler
namespace: kube-system
roleRef:
kind: ClusterRole
name: kube-scheduler
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
component: scheduler
tier: control-plane
name: my-scheduler
namespace: kube-system
spec:
selector:
matchLabels:
component: scheduler
tier: control-plane
replicas: 1
template:
metadata:
labels:
component: scheduler
tier: control-plane
version: second
spec:
serviceAccountName: my-scheduler
containers:
- command:
- /usr/local/bin/kube-scheduler
- --address=0.0.0.0
- --leader-elect=false
- --scheduler-name=my-scheduler
image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
livenessProbe:
httpGet:
path: /healthz
port: 10251
initialDelaySeconds: 15
name: kube-second-scheduler
readinessProbe:
httpGet:
path: /healthz
port: 10251
resources:
requests:
cpu: '0.1'
securityContext:
privileged: false
volumeMounts: []
hostNetwork: false
hostPID: false
volumes: []
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-scheduler
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: my-scheduler-as-kube-scheduler
subjects:
- kind: ServiceAccount
name: my-scheduler
namespace: kube-system
roleRef:
kind: ClusterRole
name: system:kube-scheduler
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
component: scheduler
tier: control-plane
name: my-scheduler
namespace: kube-system
spec:
selector:
matchLabels:
component: scheduler
tier: control-plane
replicas: 1
template:
metadata:
labels:
component: scheduler
tier: control-plane
version: second
spec:
serviceAccountName: my-scheduler
containers:
- command:
- /usr/local/bin/kube-scheduler
- --address=0.0.0.0
- --leader-elect=false
- --scheduler-name=my-scheduler
image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
livenessProbe:
httpGet:
path: /healthz
port: 10251
initialDelaySeconds: 15
name: kube-second-scheduler
readinessProbe:
httpGet:
path: /healthz
port: 10251
resources:
requests:
cpu: '0.1'
securityContext:
privileged: false
volumeMounts: []
hostNetwork: false
hostPID: false
volumes: []
content/zh/examples/application/deployment-scale.yaml
+1 -1
View File
@@ -14,6 +14,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.8
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/application/deployment-update.yaml
+1 -1
View File
@@ -14,6 +14,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8
image: nginx:1.16.1 # Update the version of nginx from 1.14.2 to 1.16.1
ports:
- containerPort: 80
content/zh/examples/application/deployment.yaml
+1 -1
View File
@@ -14,6 +14,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.7.9
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/application/guestbook/redis-slave-deployment.yaml
+1 -1
View File
@@ -20,7 +20,7 @@ spec:
spec:
containers:
- name: slave
image: gcr.io/google_samples/gb-redisslave:v1
image: gcr.io/google_samples/gb-redisslave:v3
resources:
requests:
cpu: 100m
content/zh/examples/application/mysql/mysql-pv.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-volume
labels:
content/zh/examples/application/mysql/mysql-statefulset.yaml
+12 -13
View File
@@ -106,16 +106,16 @@ spec:
cd /var/lib/mysql
# Determine binlog position of cloned data, if any.
if [[ -f xtrabackup_slave_info ]]; then
if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
# XtraBackup already generated a partial "CHANGE MASTER TO" query
# because we're cloning from an existing slave.
mv xtrabackup_slave_info change_master_to.sql.in
# because we're cloning from an existing slave. (Need to remove the tailing semicolon!)
cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
# Ignore xtrabackup_binlog_info in this case (it's useless).
rm -f xtrabackup_binlog_info
rm -f xtrabackup_slave_info xtrabackup_binlog_info
elif [[ -f xtrabackup_binlog_info ]]; then
# We're cloning directly from master. Parse binlog position.
[[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
rm xtrabackup_binlog_info
rm -f xtrabackup_binlog_info xtrabackup_slave_info
echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
fi
@@ -126,16 +126,15 @@ spec:
until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
echo "Initializing replication from clone position"
mysql -h 127.0.0.1 \
-e "$(<change_master_to.sql.in), \
MASTER_HOST='mysql-0.mysql', \
MASTER_USER='root', \
MASTER_PASSWORD='', \
MASTER_CONNECT_RETRY=10; \
START SLAVE;" || exit 1
# In case of container restart, attempt this at-most-once.
mv change_master_to.sql.in change_master_to.sql.orig
mysql -h 127.0.0.1 <<EOF
$(<change_master_to.sql.orig),
MASTER_HOST='mysql-0.mysql',
MASTER_USER='root',
MASTER_PASSWORD='',
MASTER_CONNECT_RETRY=10;
START SLAVE;
EOF
fi
# Start a server to send backups when requested by peers.
content/zh/examples/application/nginx-app.yaml
+1 -1
View File
@@ -29,6 +29,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.7.9
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/application/nginx/nginx-deployment.yaml
+1 -1
View File
@@ -14,6 +14,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.7.9
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/application/shell-demo.yaml
+2
View File
@@ -12,3 +12,5 @@ spec:
volumeMounts:
- name: shared-data
mountPath: /usr/share/nginx/html
hostNetwork: true
dnsPolicy: Default
content/zh/examples/application/simple_deployment.yaml
+1 -1
View File
@@ -14,6 +14,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.7.9
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/application/update_deployment.yaml
+1 -1
View File
@@ -13,6 +13,6 @@ spec:
spec:
containers:
- name: nginx
image: nginx:1.11.9 # update the image
image: nginx:1.16.1 # update the image
ports:
- containerPort: 80
content/zh/examples/application/zookeeper/zookeeper.yaml
+1 -1
View File
@@ -49,7 +49,7 @@ spec:
replicas: 3
updateStrategy:
type: RollingUpdate
podManagementPolicy: Parallel
podManagementPolicy: OrderedReady
template:
metadata:
labels:
content/zh/examples/audit/audit-policy.yaml
+2 -2
View File
@@ -1,4 +1,4 @@
apiVersion: audit.k8s.io/v1beta1 # This is required.
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
@@ -65,4 +65,4 @@ rules:
# Long-running requests like watches that fall under this rule will not
# generate an audit event in RequestReceived.
omitStages:
- "RequestReceived"
- "RequestReceived"
content/zh/examples/controllers/daemonset.yaml
+44 -42
View File
@@ -1,42 +1,44 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
content/zh/examples/controllers/frontend.yaml
+21 -38
View File
@@ -1,38 +1,21 @@
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
# If your cluster config does not include a dns service, then to
# instead access environment variables to find service host
# info, comment out the 'value: dns' line above, and uncomment the
# line below.
# value: env
ports:
- containerPort: 80
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
content/zh/examples/controllers/nginx-deployment.yaml
+21 -21
View File
@@ -1,21 +1,21 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/controllers/replication-nginx-1.7.9.yaml → content/zh/examples/controllers/replication-nginx-1.14.2.yaml
+16 -16
View File
@@ -1,16 +1,16 @@
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx
spec:
replicas: 5
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx
spec:
replicas: 5
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/controllers/replication-nginx-1.9.2.yaml → content/zh/examples/controllers/replication-nginx-1.16.1.yaml
+21 -21
View File
@@ -1,21 +1,21 @@
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx-v4
spec:
replicas: 5
selector:
app: nginx
deployment: v4
template:
metadata:
labels:
app: nginx
deployment: v4
spec:
containers:
- name: nginx
image: nginx:1.9.2
args: ["nginx", "-T"]
ports:
- containerPort: 80
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx-v4
spec:
replicas: 5
selector:
app: nginx
deployment: v4
template:
metadata:
labels:
app: nginx
deployment: v4
spec:
containers:
- name: nginx
image: nginx:1.16.1
args: ["nginx", "-T"]
ports:
- containerPort: 80
content/zh/examples/debug/fluentd-gcp-configmap.yaml
+379 -379
View File
@@ -1,379 +1,379 @@
kind: ConfigMap
apiVersion: v1
data:
containers.input.conf: |-
# This configuration file for Fluentd is used
# to watch changes to Docker log files that live in the
# directory /var/lib/docker/containers/ and are symbolically
# linked to from the /var/log/containers directory using names that capture the
# pod name and container name. These logs are then submitted to
# Google Cloud Logging which assumes the installation of the cloud-logging plug-in.
#
# Example
# =======
# A line in the Docker log file might look like this JSON:
#
# {"log":"2014/09/25 21:15:03 Got request with path wombat\\n",
# "stream":"stderr",
# "time":"2014-09-25T21:15:03.499185026Z"}
#
# The record reformer is used to write the tag to focus on the pod name
# and the Kubernetes container name. For example a Docker container's logs
# might be in the directory:
# /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b
# and in the file:
# 997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log
# where 997599971ee6... is the Docker ID of the running container.
# The Kubernetes kubelet makes a symbolic link to this file on the host machine
# in the /var/log/containers directory which includes the pod name and the Kubernetes
# container name:
# synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log
# ->
# /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log
# The /var/log directory on the host is mapped to the /var/log directory in the container
# running this instance of Fluentd and we end up collecting the file:
# /var/log/containers/synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log
# This results in the tag:
# var.log.containers.synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log
# The record reformer is used is discard the var.log.containers prefix and
# the Docker container ID suffix and "kubernetes." is pre-pended giving the tag:
# kubernetes.synthetic-logger-0.25lps-pod_default-synth-lgr
# Tag is then parsed by google_cloud plugin and translated to the metadata,
# visible in the log viewer
# Example:
# {"log":"[info:2016-02-16T16:04:05.930-08:00] Some log text here\n","stream":"stdout","time":"2016-02-17T00:04:05.931087621Z"}
<source>
type tail
format json
time_key time
path /var/log/containers/*.log
pos_file /var/log/gcp-containers.log.pos
time_format %Y-%m-%dT%H:%M:%S.%N%Z
tag reform.*
read_from_head true
</source>
<filter reform.**>
type parser
format /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<log>.*)/
reserve_data true
suppress_parse_error_log true
key_name log
</filter>
<match reform.**>
type record_reformer
enable_ruby true
tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')}
</match>
# Detect exceptions in the log output and forward them as one log entry.
<match raw.kubernetes.**>
@type copy
<store>
@type prometheus
<metric>
type counter
name logging_line_count
desc Total number of lines generated by application containers
<labels>
tag ${tag}
</labels>
</metric>
</store>
<store>
@type detect_exceptions
remove_tag_prefix raw
message log
stream stream
multiline_flush_interval 5
max_bytes 500000
max_lines 1000
</store>
</match>
system.input.conf: |-
# Example:
# Dec 21 23:17:22 gke-foo-1-1-4b5cbd14-node-4eoj startupscript: Finished running startup script /var/run/google.startup.script
<source>
type tail
format syslog
path /var/log/startupscript.log
pos_file /var/log/gcp-startupscript.log.pos
tag startupscript
</source>
# Examples:
# time="2016-02-04T06:51:03.053580605Z" level=info msg="GET /containers/json"
# time="2016-02-04T07:53:57.505612354Z" level=error msg="HTTP Error" err="No such image: -f" statusCode=404
<source>
type tail
format /^time="(?<time>[^)]*)" level=(?<severity>[^ ]*) msg="(?<message>[^"]*)"( err="(?<error>[^"]*)")?( statusCode=($<status_code>\d+))?/
path /var/log/docker.log
pos_file /var/log/gcp-docker.log.pos
tag docker
</source>
# Example:
# 2016/02/04 06:52:38 filePurge: successfully removed file /var/etcd/data/member/wal/00000000000006d0-00000000010a23d1.wal
<source>
type tail
# Not parsing this, because it doesn't have anything particularly useful to
# parse out of it (like severities).
format none
path /var/log/etcd.log
pos_file /var/log/gcp-etcd.log.pos
tag etcd
</source>
# Multi-line parsing is required for all the kube logs because very large log
# statements, such as those that include entire object bodies, get split into
# multiple lines by glog.
# Example:
# I0204 07:32:30.020537 3368 server.go:1048] POST /stats/container/: (13.972191ms) 200 [[Go-http-client/1.1] 10.244.1.3:40537]
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kubelet.log
pos_file /var/log/gcp-kubelet.log.pos
tag kubelet
</source>
# Example:
# I1118 21:26:53.975789 6 proxier.go:1096] Port "nodePort for kube-system/default-http-backend:http" (:31429/tcp) was open before and is still needed
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-proxy.log
pos_file /var/log/gcp-kube-proxy.log.pos
tag kube-proxy
</source>
# Example:
# I0204 07:00:19.604280 5 handlers.go:131] GET /api/v1/nodes: (1.624207ms) 200 [[kube-controller-manager/v1.1.3 (linux/amd64) kubernetes/6a81b50] 127.0.0.1:38266]
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-apiserver.log
pos_file /var/log/gcp-kube-apiserver.log.pos
tag kube-apiserver
</source>
# Example:
# 2017-02-09T00:15:57.992775796Z AUDIT: id="90c73c7c-97d6-4b65-9461-f94606ff825f" ip="104.132.1.72" method="GET" user="kubecfg" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
# 2017-02-09T00:15:57.993528822Z AUDIT: id="90c73c7c-97d6-4b65-9461-f94606ff825f" response="200"
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\S+\s+AUDIT:/
# Fields must be explicitly captured by name to be parsed into the record.
# Fields may not always be present, and order may change, so this just looks
# for a list of key="\"quoted\" value" pairs separated by spaces.
# Unknown fields are ignored.
# Note: We can't separate query/response lines as format1/format2 because
# they don't always come one after the other for a given query.
# TODO: Maybe add a JSON output mode to audit log so we can get rid of this?
format1 /^(?<time>\S+) AUDIT:(?: (?:id="(?<id>(?:[^"\\]|\\.)*)"|ip="(?<ip>(?:[^"\\]|\\.)*)"|method="(?<method>(?:[^"\\]|\\.)*)"|user="(?<user>(?:[^"\\]|\\.)*)"|groups="(?<groups>(?:[^"\\]|\\.)*)"|as="(?<as>(?:[^"\\]|\\.)*)"|asgroups="(?<asgroups>(?:[^"\\]|\\.)*)"|namespace="(?<namespace>(?:[^"\\]|\\.)*)"|uri="(?<uri>(?:[^"\\]|\\.)*)"|response="(?<response>(?:[^"\\]|\\.)*)"|\w+="(?:[^"\\]|\\.)*"))*/
time_format %FT%T.%L%Z
path /var/log/kube-apiserver-audit.log
pos_file /var/log/gcp-kube-apiserver-audit.log.pos
tag kube-apiserver-audit
</source>
# Example:
# I0204 06:55:31.872680 5 servicecontroller.go:277] LB already exists and doesn't need update for service kube-system/kubernetes-dashboard
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-controller-manager.log
pos_file /var/log/gcp-kube-controller-manager.log.pos
tag kube-controller-manager
</source>
# Example:
# W0204 06:49:18.239674 7 reflector.go:245] pkg/scheduler/factory/factory.go:193: watch of *api.Service ended with: 401: The event in requested index is outdated and cleared (the requested history has been cleared [2578313/2577886]) [2579312]
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-scheduler.log
pos_file /var/log/gcp-kube-scheduler.log.pos
tag kube-scheduler
</source>
# Example:
# I1104 10:36:20.242766 5 rescheduler.go:73] Running Rescheduler
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/rescheduler.log
pos_file /var/log/gcp-rescheduler.log.pos
tag rescheduler
</source>
# Example:
# I0603 15:31:05.793605 6 cluster_manager.go:230] Reading config from path /etc/gce.conf
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/glbc.log
pos_file /var/log/gcp-glbc.log.pos
tag glbc
</source>
# Example:
# I0603 15:31:05.793605 6 cluster_manager.go:230] Reading config from path /etc/gce.conf
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/cluster-autoscaler.log
pos_file /var/log/gcp-cluster-autoscaler.log.pos
tag cluster-autoscaler
</source>
# Logs from systemd-journal for interesting services.
<source>
type systemd
filters [{ "_SYSTEMD_UNIT": "docker.service" }]
pos_file /var/log/gcp-journald-docker.pos
read_from_head true
tag docker
</source>
<source>
type systemd
filters [{ "_SYSTEMD_UNIT": "kubelet.service" }]
pos_file /var/log/gcp-journald-kubelet.pos
read_from_head true
tag kubelet
</source>
monitoring.conf: |-
# Prometheus monitoring
<source>
@type prometheus
port 80
</source>
<source>
@type prometheus_monitor
</source>
output.conf: |-
# We use 2 output stanzas - one to handle the container logs and one to handle
# the node daemon logs, the latter of which explicitly sends its logs to the
# compute.googleapis.com service rather than container.googleapis.com to keep
# them separate since most users don't care about the node logs.
<match kubernetes.**>
@type copy
<store>
@type google_cloud
# Set the buffer type to file to improve the reliability and reduce the memory consumption
buffer_type file
buffer_path /var/log/fluentd-buffers/kubernetes.containers.buffer
# Set queue_full action to block because we want to pause gracefully
# in case of the off-the-limits load instead of throwing an exception
buffer_queue_full_action block
# Set the chunk limit conservatively to avoid exceeding the GCL limit
# of 10MiB per write request.
buffer_chunk_limit 2M
# Cap the combined memory usage of this buffer and the one below to
# 2MiB/chunk * (6 + 2) chunks = 16 MiB
buffer_queue_limit 6
# Never wait more than 5 seconds before flushing logs in the non-error case.
flush_interval 5s
# Never wait longer than 30 seconds between retries.
max_retry_wait 30
# Disable the limit on the number of retries (retry forever).
disable_retry_limit
# Use multiple threads for processing.
num_threads 2
</store>
<store>
@type prometheus
<metric>
type counter
name logging_entry_count
desc Total number of log entries generated by either an application container or a system component
<labels>
tag ${tag}
component container
</labels>
</metric>
</store>
</match>
# Keep a smaller buffer here since these logs are less important than the user's
# container logs.
<match **>
@type copy
<store>
@type google_cloud
detect_subservice false
buffer_type file
buffer_path /var/log/fluentd-buffers/kubernetes.system.buffer
buffer_queue_full_action block
buffer_chunk_limit 2M
buffer_queue_limit 2
flush_interval 5s
max_retry_wait 30
disable_retry_limit
num_threads 2
</store>
<store>
@type prometheus
<metric>
type counter
name logging_entry_count
desc Total number of log entries generated by either an application container or a system component
<labels>
tag ${tag}
component system
</labels>
</metric>
</store>
</match>
metadata:
name: fluentd-gcp-config
labels:
addonmanager.kubernetes.io/mode: Reconcile
apiVersion: v1
kind: ConfigMap
data:
containers.input.conf: |-
# This configuration file for Fluentd is used
# to watch changes to Docker log files that live in the
# directory /var/lib/docker/containers/ and are symbolically
# linked to from the /var/log/containers directory using names that capture the
# pod name and container name. These logs are then submitted to
# Google Cloud Logging which assumes the installation of the cloud-logging plug-in.
#
# Example
# =======
# A line in the Docker log file might look like this JSON:
#
# {"log":"2014/09/25 21:15:03 Got request with path wombat\\n",
# "stream":"stderr",
# "time":"2014-09-25T21:15:03.499185026Z"}
#
# The record reformer is used to write the tag to focus on the pod name
# and the Kubernetes container name. For example a Docker container's logs
# might be in the directory:
# /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b
# and in the file:
# 997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log
# where 997599971ee6... is the Docker ID of the running container.
# The Kubernetes kubelet makes a symbolic link to this file on the host machine
# in the /var/log/containers directory which includes the pod name and the Kubernetes
# container name:
# synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log
# ->
# /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log
# The /var/log directory on the host is mapped to the /var/log directory in the container
# running this instance of Fluentd and we end up collecting the file:
# /var/log/containers/synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log
# This results in the tag:
# var.log.containers.synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log
# The record reformer is used is discard the var.log.containers prefix and
# the Docker container ID suffix and "kubernetes." is pre-pended giving the tag:
# kubernetes.synthetic-logger-0.25lps-pod_default-synth-lgr
# Tag is then parsed by google_cloud plugin and translated to the metadata,
# visible in the log viewer
# Example:
# {"log":"[info:2016-02-16T16:04:05.930-08:00] Some log text here\n","stream":"stdout","time":"2016-02-17T00:04:05.931087621Z"}
<source>
type tail
format json
time_key time
path /var/log/containers/*.log
pos_file /var/log/gcp-containers.log.pos
time_format %Y-%m-%dT%H:%M:%S.%N%Z
tag reform.*
read_from_head true
</source>
<filter reform.**>
type parser
format /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<log>.*)/
reserve_data true
suppress_parse_error_log true
key_name log
</filter>
<match reform.**>
type record_reformer
enable_ruby true
tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')}
</match>
# Detect exceptions in the log output and forward them as one log entry.
<match raw.kubernetes.**>
@type copy
<store>
@type prometheus
<metric>
type counter
name logging_line_count
desc Total number of lines generated by application containers
<labels>
tag ${tag}
</labels>
</metric>
</store>
<store>
@type detect_exceptions
remove_tag_prefix raw
message log
stream stream
multiline_flush_interval 5
max_bytes 500000
max_lines 1000
</store>
</match>
system.input.conf: |-
# Example:
# Dec 21 23:17:22 gke-foo-1-1-4b5cbd14-node-4eoj startupscript: Finished running startup script /var/run/google.startup.script
<source>
type tail
format syslog
path /var/log/startupscript.log
pos_file /var/log/gcp-startupscript.log.pos
tag startupscript
</source>
# Examples:
# time="2016-02-04T06:51:03.053580605Z" level=info msg="GET /containers/json"
# time="2016-02-04T07:53:57.505612354Z" level=error msg="HTTP Error" err="No such image: -f" statusCode=404
<source>
type tail
format /^time="(?<time>[^)]*)" level=(?<severity>[^ ]*) msg="(?<message>[^"]*)"( err="(?<error>[^"]*)")?( statusCode=($<status_code>\d+))?/
path /var/log/docker.log
pos_file /var/log/gcp-docker.log.pos
tag docker
</source>
# Example:
# 2016/02/04 06:52:38 filePurge: successfully removed file /var/etcd/data/member/wal/00000000000006d0-00000000010a23d1.wal
<source>
type tail
# Not parsing this, because it doesn't have anything particularly useful to
# parse out of it (like severities).
format none
path /var/log/etcd.log
pos_file /var/log/gcp-etcd.log.pos
tag etcd
</source>
# Multi-line parsing is required for all the kube logs because very large log
# statements, such as those that include entire object bodies, get split into
# multiple lines by glog.
# Example:
# I0204 07:32:30.020537 3368 server.go:1048] POST /stats/container/: (13.972191ms) 200 [[Go-http-client/1.1] 10.244.1.3:40537]
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kubelet.log
pos_file /var/log/gcp-kubelet.log.pos
tag kubelet
</source>
# Example:
# I1118 21:26:53.975789 6 proxier.go:1096] Port "nodePort for kube-system/default-http-backend:http" (:31429/tcp) was open before and is still needed
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-proxy.log
pos_file /var/log/gcp-kube-proxy.log.pos
tag kube-proxy
</source>
# Example:
# I0204 07:00:19.604280 5 handlers.go:131] GET /api/v1/nodes: (1.624207ms) 200 [[kube-controller-manager/v1.1.3 (linux/amd64) kubernetes/6a81b50] 127.0.0.1:38266]
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-apiserver.log
pos_file /var/log/gcp-kube-apiserver.log.pos
tag kube-apiserver
</source>
# Example:
# 2017-02-09T00:15:57.992775796Z AUDIT: id="90c73c7c-97d6-4b65-9461-f94606ff825f" ip="104.132.1.72" method="GET" user="kubecfg" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
# 2017-02-09T00:15:57.993528822Z AUDIT: id="90c73c7c-97d6-4b65-9461-f94606ff825f" response="200"
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\S+\s+AUDIT:/
# Fields must be explicitly captured by name to be parsed into the record.
# Fields may not always be present, and order may change, so this just looks
# for a list of key="\"quoted\" value" pairs separated by spaces.
# Unknown fields are ignored.
# Note: We can't separate query/response lines as format1/format2 because
# they don't always come one after the other for a given query.
# TODO: Maybe add a JSON output mode to audit log so we can get rid of this?
format1 /^(?<time>\S+) AUDIT:(?: (?:id="(?<id>(?:[^"\\]|\\.)*)"|ip="(?<ip>(?:[^"\\]|\\.)*)"|method="(?<method>(?:[^"\\]|\\.)*)"|user="(?<user>(?:[^"\\]|\\.)*)"|groups="(?<groups>(?:[^"\\]|\\.)*)"|as="(?<as>(?:[^"\\]|\\.)*)"|asgroups="(?<asgroups>(?:[^"\\]|\\.)*)"|namespace="(?<namespace>(?:[^"\\]|\\.)*)"|uri="(?<uri>(?:[^"\\]|\\.)*)"|response="(?<response>(?:[^"\\]|\\.)*)"|\w+="(?:[^"\\]|\\.)*"))*/
time_format %FT%T.%L%Z
path /var/log/kube-apiserver-audit.log
pos_file /var/log/gcp-kube-apiserver-audit.log.pos
tag kube-apiserver-audit
</source>
# Example:
# I0204 06:55:31.872680 5 servicecontroller.go:277] LB already exists and doesn't need update for service kube-system/kubernetes-dashboard
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-controller-manager.log
pos_file /var/log/gcp-kube-controller-manager.log.pos
tag kube-controller-manager
</source>
# Example:
# W0204 06:49:18.239674 7 reflector.go:245] pkg/scheduler/factory/factory.go:193: watch of *api.Service ended with: 401: The event in requested index is outdated and cleared (the requested history has been cleared [2578313/2577886]) [2579312]
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/kube-scheduler.log
pos_file /var/log/gcp-kube-scheduler.log.pos
tag kube-scheduler
</source>
# Example:
# I1104 10:36:20.242766 5 rescheduler.go:73] Running Rescheduler
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/rescheduler.log
pos_file /var/log/gcp-rescheduler.log.pos
tag rescheduler
</source>
# Example:
# I0603 15:31:05.793605 6 cluster_manager.go:230] Reading config from path /etc/gce.conf
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/glbc.log
pos_file /var/log/gcp-glbc.log.pos
tag glbc
</source>
# Example:
# I0603 15:31:05.793605 6 cluster_manager.go:230] Reading config from path /etc/gce.conf
<source>
type tail
format multiline
multiline_flush_interval 5s
format_firstline /^\w\d{4}/
format1 /^(?<severity>\w)(?<time>\d{4} [^\s]*)\s+(?<pid>\d+)\s+(?<source>[^ \]]+)\] (?<message>.*)/
time_format %m%d %H:%M:%S.%N
path /var/log/cluster-autoscaler.log
pos_file /var/log/gcp-cluster-autoscaler.log.pos
tag cluster-autoscaler
</source>
# Logs from systemd-journal for interesting services.
<source>
type systemd
filters [{ "_SYSTEMD_UNIT": "docker.service" }]
pos_file /var/log/gcp-journald-docker.pos
read_from_head true
tag docker
</source>
<source>
type systemd
filters [{ "_SYSTEMD_UNIT": "kubelet.service" }]
pos_file /var/log/gcp-journald-kubelet.pos
read_from_head true
tag kubelet
</source>
monitoring.conf: |-
# Prometheus monitoring
<source>
@type prometheus
port 80
</source>
<source>
@type prometheus_monitor
</source>
output.conf: |-
# We use 2 output stanzas - one to handle the container logs and one to handle
# the node daemon logs, the latter of which explicitly sends its logs to the
# compute.googleapis.com service rather than container.googleapis.com to keep
# them separate since most users don't care about the node logs.
<match kubernetes.**>
@type copy
<store>
@type google_cloud
# Set the buffer type to file to improve the reliability and reduce the memory consumption
buffer_type file
buffer_path /var/log/fluentd-buffers/kubernetes.containers.buffer
# Set queue_full action to block because we want to pause gracefully
# in case of the off-the-limits load instead of throwing an exception
buffer_queue_full_action block
# Set the chunk limit conservatively to avoid exceeding the GCL limit
# of 10MiB per write request.
buffer_chunk_limit 2M
# Cap the combined memory usage of this buffer and the one below to
# 2MiB/chunk * (6 + 2) chunks = 16 MiB
buffer_queue_limit 6
# Never wait more than 5 seconds before flushing logs in the non-error case.
flush_interval 5s
# Never wait longer than 30 seconds between retries.
max_retry_wait 30
# Disable the limit on the number of retries (retry forever).
disable_retry_limit
# Use multiple threads for processing.
num_threads 2
</store>
<store>
@type prometheus
<metric>
type counter
name logging_entry_count
desc Total number of log entries generated by either an application container or a system component
<labels>
tag ${tag}
component container
</labels>
</metric>
</store>
</match>
# Keep a smaller buffer here since these logs are less important than the user's
# container logs.
<match **>
@type copy
<store>
@type google_cloud
detect_subservice false
buffer_type file
buffer_path /var/log/fluentd-buffers/kubernetes.system.buffer
buffer_queue_full_action block
buffer_chunk_limit 2M
buffer_queue_limit 2
flush_interval 5s
max_retry_wait 30
disable_retry_limit
num_threads 2
</store>
<store>
@type prometheus
<metric>
type counter
name logging_entry_count
desc Total number of log entries generated by either an application container or a system component
<labels>
tag ${tag}
component system
</labels>
</metric>
</store>
</match>
metadata:
name: fluentd-gcp-config
labels:
addonmanager.kubernetes.io/mode: Reconcile
content/zh/examples/podpreset/allow-db-merged.yaml
+31 -37
View File
@@ -1,37 +1,31 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
- mountPath: /etc/app/config.json
readOnly: true
name: secret-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumes:
- name: cache-volume
emptyDir: {}
- name: secret-volume
secret:
secretName: config-details
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumes:
- name: cache-volume
emptyDir: {}
content/zh/examples/podpreset/allow-db.yaml
+24 -30
View File
@@ -1,30 +1,24 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumeMounts:
- mountPath: /cache
name: cache-volume
- mountPath: /etc/app/config.json
readOnly: true
name: secret-volume
volumes:
- name: cache-volume
emptyDir: {}
- name: secret-volume
secret:
secretName: config-details
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
content/zh/examples/pods/config/redis-pod.yaml
+4 -1
View File
@@ -5,7 +5,10 @@ metadata:
spec:
containers:
- name: redis
image: kubernetes/redis:v1
image: redis:5.0.4
command:
- redis-server
- "/redis-master/redis.conf"
env:
- name: MASTER
value: "true"
content/zh/examples/pods/inject/dapi-volume-resources.yaml
-1
View File
@@ -30,7 +30,6 @@ spec:
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
readOnly: false
volumes:
- name: podinfo
downwardAPI:
content/zh/examples/pods/inject/dapi-volume.yaml
-1
View File
@@ -25,7 +25,6 @@ spec:
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
readOnly: false
volumes:
- name: podinfo
downwardAPI:
content/zh/examples/pods/inject/secret-pod.yaml
+3 -3
View File
@@ -7,9 +7,9 @@ spec:
- name: test-container
image: nginx
volumeMounts:
# name must match the volume name below
- name: secret-volume
mountPath: /etc/secret-volume
# name must match the volume name below
- name: secret-volume
mountPath: /etc/secret-volume
# The secret data is exposed to Containers in the Pod through a Volume.
volumes:
- name: secret-volume
content/zh/examples/pods/inject/secret.yaml
+2 -2
View File
@@ -3,5 +3,5 @@ kind: Secret
metadata:
name: test-secret
data:
username: bXktYXBwCg==
password: Mzk1MjgkdmRnN0piCg==
username: bXktYXBw
password: Mzk1MjgkdmRnN0pi
content/zh/examples/pods/pod-projected-svc-token.yaml
+2 -2
View File
@@ -1,5 +1,5 @@
kind: Pod
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
@@ -9,7 +9,7 @@ spec:
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: vault-token
serviceAccountName: acct
serviceAccountName: build-robot
volumes:
- name: vault-token
projected:
content/zh/examples/pods/probe/http-liveness.yaml
+1 -1
View File
@@ -15,7 +15,7 @@ spec:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
content/zh/examples/pods/security/security-context.yaml
+3 -1
View File
@@ -5,13 +5,15 @@ metadata:
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
content/zh/examples/pods/simple-pod.yaml
+1 -1
View File
@@ -5,6 +5,6 @@ metadata:
spec:
containers:
- name: nginx
image: nginx:1.7.9
image: nginx:1.14.2
ports:
- containerPort: 80
content/zh/examples/pods/storage/pv-claim.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
content/zh/examples/pods/storage/pv-pod.yaml
+2 -2
View File
@@ -1,12 +1,12 @@
kind: Pod
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
content/zh/examples/pods/storage/pv-volume.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
content/zh/examples/policy/restricted-psp.yaml
+48 -48
View File
@@ -1,48 +1,48 @@
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we can provide it for defense in depth.
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that persistentVolumes set up by the cluster admin are safe to use.
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we can provide it for defense in depth.
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that persistentVolumes set up by the cluster admin are safe to use.
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
content/zh/examples/service/access/hello-service.yaml
+12 -12
View File
@@ -1,12 +1,12 @@
kind: Service
apiVersion: v1
metadata:
name: hello
spec:
selector:
app: hello
tier: backend
ports:
- protocol: TCP
port: 80
targetPort: http
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
selector:
app: hello
tier: backend
ports:
- protocol: TCP
port: 80
targetPort: http
content/zh/examples/service/networking/ingress.yaml
+9 -9
View File
@@ -1,9 +1,9 @@
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test-ingress
spec:
backend:
serviceName: testsvc
servicePort: 80
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: test-ingress
spec:
backend:
serviceName: testsvc
servicePort: 80

Some files were not shown because too many files have changed in this diff Show More