diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 43f27a88b2..9bc9a38f16 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -64,6 +64,7 @@ aliases: - makoscafee - onlydole - rajakavitha1 + - rajeshdeshpande02 - sftim - steveperry-53 - tengqm diff --git a/assets/sass/_base.sass b/assets/sass/_base.sass index 2315ae5e94..c59d20c346 100644 --- a/assets/sass/_base.sass +++ b/assets/sass/_base.sass @@ -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 diff --git a/content/de/docs/home/_index.md b/content/de/docs/home/_index.md index e8d87597a6..128cd67c2e 100644 --- a/content/de/docs/home/_index.md +++ b/content/de/docs/home/_index.md @@ -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 diff --git a/content/en/blog/_posts/Kong-Ingress-Controller-and-Service-Mesh.md b/content/en/blog/_posts/Kong-Ingress-Controller-and-Service-Mesh.md index 9e9a4a5dd4..2023f2e1da 100644 --- a/content/en/blog/_posts/Kong-Ingress-Controller-and-Service-Mesh.md +++ b/content/en/blog/_posts/Kong-Ingress-Controller-and-Service-Mesh.md @@ -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 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 ".*" @@ -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)$PROXY_IP/productpage. 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 $PROXY_IP/productpage +$ 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: diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 338e9a2408..97188ee9ad 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -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 diff --git a/content/en/docs/concepts/configuration/manage-compute-resources-container.md b/content/en/docs/concepts/configuration/manage-compute-resources-container.md index 576a008ba9..43dec5331c 100644 --- a/content/en/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/en/docs/concepts/configuration/manage-compute-resources-container.md @@ -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 diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index a4451f2867..77551398b6 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -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`. diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 12a6c66839..26722e607f 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -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 `` 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** {{}}, **Caution** {{}}, and **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** `{{}}`, **Caution** `{{}}`, and **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 {{}} to highlight a tip or a piece of information that may be helpful to know. +Use `{{}}` 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 {{}} in a list: +You can use a `{{}}` in a list: ``` 1. Use the note shortcode in a list @@ -323,7 +323,7 @@ The output is: ### Caution -Use {{}} to call attention to an important piece of information to avoid pitfalls. +Use `{{}}` 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 {{}} to indicate danger or a piece of information that is crucial to follow. +Use `{{}}` 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: {{}} ``` -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. - {{}}Grease the pan for best results.{{}} + `{{}}Grease the pan for best results.{{}}` 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 Check required ports for more details. | Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See here 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: `Visit our tutorial!`, 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 >}} diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index 692f10dbef..dcaf693039 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -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 diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 0089c08a91..cd941bcadb 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -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. diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 3e18ae283e..b4e2f5ed6e 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -10,35 +10,61 @@ weight: 70 --- {{% capture overview %}} -Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. +Role-based access control (RBAC) is a method of regulating access to computer or +network resources based on the roles of individual users within your organization. {{% /capture %}} {{% capture body %}} -`RBAC` uses the `rbac.authorization.k8s.io` {{< glossary_tooltip text="API Group" term_id="api-group" >}} -to drive authorization decisions, allowing admins to dynamically configure policies -through the Kubernetes API. +RBAC authorization uses the `rbac.authorization.k8s.io` +{{< glossary_tooltip text="API group" term_id="api-group" >}} to drive authorization +decisions, allowing you to dynamically configure policies through the Kubernetes API. -As of 1.8, RBAC mode is stable and backed by the rbac.authorization.k8s.io/v1 API. +To enable RBAC, start the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +with the `--authorization-mode` flag set to a comma-separated list that includes `RBAC`; +for example: +```shell +kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options +``` -To enable RBAC, start the apiserver with `--authorization-mode=RBAC`. +## API objects {#api-overview} -## API Overview +The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_, +_RoleBinding_ and _ClusterRoleBinding_. You can +[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), +or amend them, using tools such as `kubectl,` just like any other Kubernetes object. -The RBAC API declares four top-level types which will be covered in this -section. Users can interact with these resources as they would with any other -API resource (via `kubectl`, API calls, etc.). For instance, -`kubectl apply -f (resource).yml` can be used with any of these examples, -though readers who wish to follow along should review the section on -bootstrapping first. +{{< caution >}} +These objects, by design, impose access restrictions. If you are making changes +to a cluster as you learn, see +[privilege escalation prevention and bootstrapping](#privilege-escalation-prevention-and-bootstrapping) +to understand how those restrictions can prevent you making some changes. +{{< /caution >}} ### Role and ClusterRole -In the RBAC API, a role contains rules that represent a set of permissions. +An RBAC _Role_ or _ClusterRole_ contains rules that represent a set of permissions. Permissions are purely additive (there are no "deny" rules). -A role can be defined within a namespace with a `Role`, or cluster-wide with a `ClusterRole`. -A `Role` can only be used to grant access to resources within a single namespace. -Here's an example `Role` in the "default" namespace that can be used to grant read access to pods: +A Role always sets permissions within a particular {{< glossary_tooltip text="namespace" term_id="namespace" >}}; +when you create a Role, you have to specify the namespace it belongs in. + +ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role +and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; +it can't be both. + +ClusterRoles have several uses. You can use a ClusterRole to: + +1. define permissions on namespaced resources and be granted within individual namespace(s) +1. define permissions on namespaced resources and be granted across all namespaces +1. define permissions on cluster-scoped resources + +If you want to define a role within a namespace, use a Role; if you want to define +a role cluster-wide, use a ClusterRole. + +#### Role example + +Here's an example Role in the "default" namespace that can be used to grant read access to +{{< glossary_tooltip text="pods" term_id="pod" >}}: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -52,14 +78,19 @@ rules: verbs: ["get", "watch", "list"] ``` -A `ClusterRole` can be used to grant the same permissions as a `Role`, -but because they are cluster-scoped, they can also be used to grant access to: +#### ClusterRole example -* cluster-scoped resources (like nodes) -* non-resource endpoints (like "/healthz") -* namespaced resources (like pods) across all namespaces (needed to run `kubectl get pods --all-namespaces`, for example) +A ClusterRole can be used to grant the same permissions as a Role. +Because ClusterRoles are cluster-scoped, you can also use them to grant access to: -The following `ClusterRole` can be used to grant read access to secrets in any particular namespace, +* cluster-scoped resources (like {{< glossary_tooltip text="nodes" term_id="node" >}}) +* non-resource endpoints (like `/healthz`) +* namespaced resources (like Pods), across all namespaces + For example: you can use a ClusterRole to allow a particular user to run + `kubectl get pods --all-namespaces`. + +Here is an example of a ClusterRole that can be used to grant read access to +{{< glossary_tooltip text="secrets" term_id="secret" >}} in any particular namespace, or across all namespaces (depending on how it is [bound](#rolebinding-and-clusterrolebinding)): ```yaml @@ -70,6 +101,9 @@ metadata: name: secret-reader rules: - apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Secret + # objects is "secrets" resources: ["secrets"] verbs: ["get", "watch", "list"] ``` @@ -80,51 +114,65 @@ The name of a Role or a ClusterRole object must be a valid ### RoleBinding and ClusterRoleBinding A role binding grants the permissions defined in a role to a user or set of users. -It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. -Permissions can be granted within a namespace with a `RoleBinding`, or cluster-wide with a `ClusterRoleBinding`. +It holds a list of *subjects* (users, groups, or service accounts), and a reference to the +role being granted. +A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding +grants that access cluster-wide. -A `RoleBinding` may reference a `Role` in the same namespace. -The name of a `RoleBinding` object must be a valid +A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding +can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding. +If you want to bind a ClusterRole to all the namespaces in your cluster, you use a +ClusterRoleBinding. + +The name of a RoleBinding or ClusterRoleBinding object must be a valid [path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names). -The following `RoleBinding` grants the "pod-reader" role to the user "jane" within the "default" namespace. -This allows "jane" to read pods in the "default" namespace. +#### RoleBinding examples {#rolebinding-example} -`roleRef` is how you will actually create the binding. The `kind` will be either `Role` or `ClusterRole`, and the `name` will reference the name of the specific `Role` or `ClusterRole` you want. In the example below, this RoleBinding is using `roleRef` to bind the user "jane" to the `Role` created above named `pod-reader`. +Here is an example of a RoleBinding that grants the "pod-reader" Role to the user "jane" +within the "default" namespace. +This allows "jane" to read pods in the "default" namespace. ```yaml apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "jane" to read pods in the "default" namespace. +# You need to already have a Role named "pod-reader" in that namespace. kind: RoleBinding metadata: name: read-pods namespace: default subjects: +# You can specify more than one "subject" - kind: User - name: jane # Name is case sensitive + name: jane # "name" is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: + # "roleRef" specifies the binding to a Role / ClusterRole kind: Role #this must be Role or ClusterRole name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.io ``` -A `RoleBinding` may also reference a `ClusterRole` to grant the permissions to namespaced -resources defined in the `ClusterRole` within the `RoleBinding`'s namespace. -This allows administrators to define a set of common roles for the entire cluster, -then reuse them within multiple namespaces. +A RoleBinding can also reference a ClusterRole to grant the permissions defined in that +ClusterRole to resources inside the RoleBinding's namespace. This kind of reference +lets you define a set of common roles across your cluster, then reuse them within +multiple namespaces. -For instance, even though the following `RoleBinding` refers to a `ClusterRole`, -"dave" (the subject, case sensitive) will only be able to read secrets in the "development" -namespace (the namespace of the `RoleBinding`). +For instance, even though the following RoleBinding refers to a ClusterRole, +"dave" (the subject, case sensitive) will only be able to read Secrets in the "development" +namespace, because the RoleBinding's namespace (in its metadata) is "development". ```yaml apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "dave" to read secrets in the "development" namespace. +# You need to already have a ClusterRole named "secret-reader". kind: RoleBinding metadata: name: read-secrets - namespace: development # This only grants permissions within the "development" namespace. + # + # The namespace of the RoleBinding determines where the permissions are granted. + # This only grants permissions within the "development" namespace. + namespace: development subjects: - kind: User name: dave # Name is case sensitive @@ -135,10 +183,10 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all namespaces. - The name of a `ClusterRoleBinding` object must be a valid -[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names). -The following `ClusterRoleBinding` allows any user in the group "manager" to read +#### ClusterRoleBinding example + +To grant permissions across a whole cluster, you can use a ClusterRoleBinding. +The following ClusterRoleBinding allows any user in the group "manager" to read secrets in any namespace. ```yaml @@ -157,37 +205,43 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -You cannot modify which `Role` or `ClusterRole` a binding object refers to. -Attempts to change the `roleRef` field of a binding object will result in a validation error. -To change the `roleRef` field on an existing binding object, the binding object must be deleted and recreated. -There are two primary reasons for this restriction: +After you create a binding, you cannot change the Role or ClusterRole that it refers to. +If you try to change a binding's `roleRef`, you get a validation error. If you do want +to change the `roleRef` for a binding, you need to remove the binding object and create +a replacement. -1. A binding to a different role is a fundamentally different binding. +There are two reasons for this restriction: + +1. Making `roleRef` immutable allows granting someone `update` permission on an existing binding +object, so that they can manage the list of subjects, without being able to change +the role that is granted to those subjects. +1. A binding to a different role is a fundamentally different binding. Requiring a binding to be deleted/recreated in order to change the `roleRef` ensures the full list of subjects in the binding is intended to be granted -the new role (as opposed to enabling accidentally modifying just the roleRef -without verifying all of the existing subjects should be given the new role's permissions). -2. Making `roleRef` immutable allows giving `update` permission on an existing binding object -to a user, which lets them manage the list of subjects, without being able to change the -role that is granted to those subjects. +the new role (as opposed to enabling accidentally modifying just the roleRef +without verifying all of the existing subjects should be given the new role's +permissions). The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects, -and handles deleting and recreating binding objects if required to change the role they refer to. +and handles deleting and recreating binding objects if required to change the role they refer to. See [command usage and examples](#kubectl-auth-reconcile) for more information. -### Referring to Resources +### Referring to resources -Most resources are represented by a string representation of their name, such as "pods", just as it -appears in the URL for the relevant API endpoint. However, some Kubernetes APIs involve a -"subresource", such as the logs for a pod. The URL for the pods logs endpoint is: +In the Kubernetes API, most resources are represented and accessed using a string representation of +their object name, such as `pods` for a Pod. RBAC refers to resources using exactly the same +name that appears in the URL for the relevant API endpoint. +Some Kubernetes APIs involve a +_subresource_, such as the logs for a Pod. A request for a Pod's logs looks like: ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -In this case, "pods" is the namespaced resource, and "log" is a subresource of pods. To represent -this in an RBAC role, use a slash to delimit the resource and subresource. To allow a subject -to read both pods and pod logs, you would write: +In this case, `pods` is the namespaced resource for Pod resources, and `log` is a +subresource of `pods`. To represent this in an RBAC role, use a slash (`/`) to +delimit the resource and subresource. To allow a subject to read `pods` and +also access the `log` subresource for each of those Pods, you write: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -201,9 +255,11 @@ rules: verbs: ["get", "list"] ``` -Resources can also be referred to by name for certain requests through the `resourceNames` list. -When specified, requests can be restricted to individual instances of a resource. To restrict a -subject to only "get" and "update" a single configmap, you would write: +You can also refer to resources by name for certain requests through the `resourceNames` list. +When specified, requests can be restricted to individual instances of a resource. +Here is an example that restricts its subject to only `get` or `update` a +{{< glossary_tooltip term_id="ConfigMap" >}} named `my-configmap`: + ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -213,19 +269,30 @@ metadata: name: configmap-updater rules: - apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing ConfigMap + # objects is "configmaps" resources: ["configmaps"] resourceNames: ["my-configmap"] verbs: ["update", "get"] ``` -Note that `create` requests cannot be restricted by resourceName, as the object name is not known at -authorization time. The other exception is `deletecollection`. +{{< note >}} +You cannot restrict `create` or `deletecollection` requests by resourceName. For `create`, this +limitation is because the object name is not known at authorization time. +{{< /note >}} + ### Aggregated ClusterRoles -As of 1.9, ClusterRoles can be created by combining other ClusterRoles using an `aggregationRule`. The -permissions of aggregated ClusterRoles are controller-managed, and filled in by unioning the rules of any -ClusterRole that matches the provided label selector. An example aggregated ClusterRole: +You can _aggregate_ several ClusterRoles into one combined ClusterRole. +A controller, running as part of the cluster control plane, watches for ClusterRole +objects with an `aggregationRule` set. The `aggregationRule` defines a label +{{< glossary_tooltip text="selector" term_id="selector" >}} that the controller +uses to match other ClusterRole objects that should be combined into the `rules` +field of this one. + +Here is an example aggregated ClusterRole: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -236,12 +303,13 @@ aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-monitoring: "true" -rules: [] # Rules are automatically filled in by the controller manager. +rules: [] # The control plane automatically fills in the rules ``` -Creating a ClusterRole that matches the label selector will add rules to the aggregated ClusterRole. In this case -rules can be added to the "monitoring" ClusterRole by creating another ClusterRole that has the label -`rbac.example.com/aggregate-to-monitoring: true`. +If you create a new ClusterRole that matches the label selector of an existing aggregated ClusterRole, +that change triggers adding the new rules into the aggregated ClusterRole. +Here is an example that adds rules to the "monitoring" ClusterRole, by creating another +ClusterRole labeled `rbac.example.com/aggregate-to-monitoring: true`. ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -250,19 +318,22 @@ metadata: name: monitoring-endpoints labels: rbac.example.com/aggregate-to-monitoring: "true" -# These rules will be added to the "monitoring" role. +# When you create the "monitoring-endpoints" ClusterRole, +# the rules below will be added to the "monitoring" ClusterRole. rules: - apiGroups: [""] resources: ["services", "endpoints", "pods"] verbs: ["get", "list", "watch"] ``` -The default user-facing roles (described below) use ClusterRole aggregation. This lets admins include rules -for custom resources, such as those served by CustomResourceDefinitions or Aggregated API servers, on the -default roles. +The [default user-facing roles](#default-roles-and-rolebindings) use ClusterRole aggregation. This lets you, +as a cluster administrator, include rules for custom resources, such as those served by +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} +or aggregated API servers, to extend the default roles. -For example, the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource -"CronTabs" and the "view" role perform read-only actions on the resource. +For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource +named CronTab, whereas the "view" role can perform just read actions on CronTab resources. +You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server. ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -291,60 +362,87 @@ rules: verbs: ["get", "list", "watch"] ``` -#### Role Examples +#### Role examples -Only the `rules` section is shown in the following examples. +The following examples are excerpts from Role or ClusterRole objects, showing only +the `rules` section. -Allow reading the resource "pods" in the core {{< glossary_tooltip text="API Group" term_id="api-group" >}}: +Allow reading `"pods"` resources in the core +{{< glossary_tooltip text="API Group" term_id="api-group" >}}: ```yaml rules: - apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Pod + # objects is "pods" resources: ["pods"] verbs: ["get", "list", "watch"] ``` -Allow reading/writing "deployments" in both the "extensions" and "apps" API groups: +Allow reading/writing Deployments (at the HTTP level: objects with `"deployments"` +in the resource part of their URL) in both the `"extensions"` and `"apps"` API groups: ```yaml rules: - apiGroups: ["extensions", "apps"] + # + # at the HTTP level, the name of the resource for accessing Deployment + # objects is "deployments" resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -Allow reading "pods" and reading/writing "jobs": +Allow reading Pods in the core API group, as well as reading or writing Job +resources in the `"batch"` or `"extensions"` API groups: ```yaml rules: - apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Pod + # objects is "pods" resources: ["pods"] verbs: ["get", "list", "watch"] - apiGroups: ["batch", "extensions"] + # + # at the HTTP level, the name of the resource for accessing Job + # objects is "jobs" resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -Allow reading a `ConfigMap` named "my-config" (must be bound with a `RoleBinding` to limit to a single `ConfigMap` in a single namespace): +Allow reading a ConfigMap named "my-config" (must be bound with a +RoleBinding to limit to a single ConfigMap in a single namespace): ```yaml rules: - apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing ConfigMap + # objects is "configmaps" resources: ["configmaps"] resourceNames: ["my-config"] verbs: ["get"] ``` -Allow reading the resource "nodes" in the core group (because a `Node` is cluster-scoped, this must be in a `ClusterRole` bound with a `ClusterRoleBinding` to be effective): +Allow reading the resource `"nodes"` in the core group (because a +Node is cluster-scoped, this must be in a ClusterRole bound with a +ClusterRoleBinding to be effective): ```yaml rules: - apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Node + # objects is "nodes" resources: ["nodes"] verbs: ["get", "list", "watch"] ``` -Allow "GET" and "POST" requests to the non-resource endpoint "/healthz" and all subpaths (must be in a `ClusterRole` bound with a `ClusterRoleBinding` to be effective): +Allow GET and POST requests to the non-resource endpoint `/healthz` and +all subpaths (must be in a ClusterRole bound with a ClusterRoleBinding +to be effective): ```yaml rules: @@ -352,32 +450,44 @@ rules: verbs: ["get", "post"] ``` -### Referring to Subjects +### Referring to subjects -A `RoleBinding` or `ClusterRoleBinding` binds a role to *subjects*. -Subjects can be groups, users or service accounts. +A RoleBinding or ClusterRoleBinding binds a role to subjects. +Subjects can be groups, users or +{{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}. -Users are represented by strings. These can be plain usernames, like -"alice", email-style names, like "bob@example.com", or numeric IDs -represented as a string. It is up to the Kubernetes admin to configure -the [authentication modules](/docs/reference/access-authn-authz/authentication/) to produce -usernames in the desired format. The RBAC authorization system does -not require any particular format. However, the prefix `system:` is -reserved for Kubernetes system use, and so the admin should ensure -usernames do not contain this prefix by accident. +Kubernetes represents usernames as strings. +These can be: plain names, such as "alice"; email-style names, like "bob@example.com"; +or numeric user IDs represented as a string. It is up to you as a cluster administrator +to configure the [authentication modules](/docs/reference/access-authn-authz/authentication/) +so that authentication produces usernames in the format you want. -Group information in Kubernetes is currently provided by the Authenticator -modules. Groups, like users, are represented as strings, and that string -has no format requirements, other than that the prefix `system:` is reserved. +{{< caution >}} +The prefix `system:` is reserved for Kubernetes system use, so you should ensure +that you don't have users or groups with names that start with `system:` by +accident. +Other than this special prefix, the RBAC authorization system does not require any format +for usernames. +{{< /caution >}} -[Service Accounts](/docs/tasks/configure-pod-container/configure-service-account/) have usernames with the `system:serviceaccount:` prefix and belong -to groups with the `system:serviceaccounts:` prefix. +In Kubernetes, Authenticator modules provide group information. +Groups, like users, are represented as strings, and that string has no format requirements, +other than that the prefix `system:` is reserved. -#### Role Binding Examples +[ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) have names prefixed +with `system:serviceaccount:`, and belong to groups that have names prefixed with `system:serviceaccounts:`. -Only the `subjects` section of a `RoleBinding` is shown in the following examples. +{{< note >}} +- `system:serviceaccount:` (singular) is the prefix for service account usernames. +- `system:serviceaccounts:` (plural) is the prefix for service account groups. +{{< /note >}} -For a user named "alice@example.com": +#### RoleBinding examples {#role-binding-examples} + +The following examples are `RoleBinding` excerpts that only +show the `subjects` section. + +For a user named `alice@example.com`: ```yaml subjects: @@ -386,7 +496,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For a group named "frontend-admins": +For a group named `frontend-admins`: ```yaml subjects: @@ -395,7 +505,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For the default service account in the kube-system namespace: +For the default service account in the "kube-system" namespace: ```yaml subjects: @@ -413,7 +523,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all service accounts everywhere: +For all service accounts in any namespace: ```yaml subjects: @@ -422,7 +532,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all authenticated users (version 1.5+): +For all authenticated users: ```yaml subjects: @@ -431,7 +541,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all unauthenticated users (version 1.5+): +For all unauthenticated users: ```yaml subjects: @@ -440,7 +550,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all users (version 1.5+): +For all users: ```yaml subjects: @@ -452,42 +562,51 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -## Default Roles and Role Bindings +## Default roles and role bindings -API servers create a set of default `ClusterRole` and `ClusterRoleBinding` objects. -Many of these are `system:` prefixed, which indicates that the resource is "owned" by the infrastructure. -Modifications to these resources can result in non-functional clusters. One example is the `system:node` ClusterRole. -This role defines permissions for kubelets. If the role is modified, it can prevent kubelets from working. +API servers create a set of default ClusterRole and ClusterRoleBinding objects. +Many of these are `system:` prefixed, which indicates that the resource is directly +managed by the cluster control plane. +All of the default ClusterRoles and ClusterRoleBindings are labeled with `kubernetes.io/bootstrapping=rbac-defaults`. -All of the default cluster roles and rolebindings are labeled with `kubernetes.io/bootstrapping=rbac-defaults`. +{{< caution >}} +Take care when modifying ClusterRoles and ClusterRoleBindings with names +that have a `system:` prefix. +Modifications to these resources can result in non-functional clusters. +{{< /caution >}} ### Auto-reconciliation At each start-up, the API server updates default cluster roles with any missing permissions, and updates default cluster role bindings with any missing subjects. -This allows the cluster to repair accidental modifications, -and to keep roles and rolebindings up-to-date as permissions and subjects change in new releases. +This allows the cluster to repair accidental modifications, and helps to keep roles and role bindings +up-to-date as permissions and subjects change in new Kubernetes releases. -To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` +To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` annotation on a default cluster role or rolebinding to `false`. Be aware that missing default permissions and subjects can result in non-functional clusters. -Auto-reconciliation is enabled in Kubernetes version 1.6+ when the RBAC authorizer is active. +Auto-reconciliation is enabled by default if the RBAC authorizer is active. -### Discovery Roles +### API discovery roles {#discovery-roles} -Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access add `--anonymous-auth=false` to the API server configuration. +Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration. To view the configuration of these roles via `kubectl` run: -``` +```shell kubectl get clusterroles system:discovery -o yaml ``` -NOTE: editing the role is not recommended as changes will be overwritten on API server restart via auto-reconciliation (see above). +{{< note >}} +If you edit that ClusterRole, your changes will be overwritten on API server restart +via [auto-reconciliation](#auto-reconciliation). To avoid that overwriting, +either do not manually edit the role, or disable auto-reconciliation. +{{< /note >}} - + + @@ -496,30 +615,30 @@ NOTE: editing the role is not recommended as changes will be overwritten on API - + - + - +
Kubernetes RBAC API discovery roles
Default ClusterRole Default ClusterRoleBinding
system:basic-user system:authenticated groupAllows a user read-only access to basic information about themselves. Prior to 1.14, this role was also bound to `system:unauthenticated` by default.Allows a user read-only access to basic information about themselves. Prior to v1.14, this role was also bound to system:unauthenticated by default.
system:discovery system:authenticated groupAllows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to 1.14, this role was also bound to `system:unauthenticated` by default.Allows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to v1.14, this role was also bound to system:unauthenticated by default.
system:public-info-viewer system:authenticated and system:unauthenticated groupsAllows read-only access to non-sensitive information about the cluster. Introduced in 1.14.Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
-### User-facing Roles +### User-facing roles -Some of the default roles are not `system:` prefixed. These are intended to be user-facing roles. -They include super-user roles (`cluster-admin`), -roles intended to be granted cluster-wide using ClusterRoleBindings (`cluster-status`), -and roles intended to be granted within particular namespaces using RoleBindings (`admin`, `edit`, `view`). +Some of the default ClusterRoles are not `system:` prefixed. These are intended to be user-facing roles. +They include super-user roles (`cluster-admin`), roles intended to be granted cluster-wide +using ClusterRoleBindings, and roles intended to be granted within particular +namespaces using RoleBindings (`admin`, `edit`, `view`). -As of 1.9, user-facing roles use [ClusterRole Aggregation](#aggregated-clusterroles) to allow admins to include -rules for custom resources on these roles. To add rules to the "admin", "edit", or "view" role, create a -ClusterRole with one or more of the following labels: +User-facing ClusterRoles use [ClusterRole aggregation](#aggregated-clusterroles) to allow admins to include +rules for custom resources on these ClusterRoles. To add rules to the `admin`, `edit`, or `view` roles, create +a ClusterRole with one or more of the following labels: ```yaml metadata: @@ -541,32 +660,40 @@ metadata: system:masters group Allows super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. -When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself. +When used in a RoleBinding, it gives full control over every resource in the role binding's namespace, including the namespace itself. admin None Allows admin access, intended to be granted within a namespace using a RoleBinding. If used in a RoleBinding, allows read/write access to most resources in a namespace, -including the ability to create roles and rolebindings within the namespace. -It does not allow write access to resource quota or to the namespace itself. +including the ability to create roles and role bindings within the namespace. +This role does not allow write access to resource quota or to the namespace itself. edit None Allows read/write access to most objects in a namespace. -It does not allow viewing or modifying roles or rolebindings. + +This role does not allow viewing or modifying roles or role bindings. +However, this role allows accessing Secrets and running Pods as any ServiceAccount in +the namespace, so it can be used to gain the API access levels of any ServiceAccount in +the namespace. view None Allows read-only access to see most objects in a namespace. -It does not allow viewing roles or rolebindings. -It does not allow viewing secrets, since those are escalating. +It does not allow viewing roles or role bindings. + +This role does not allow viewing Secrets, since reading +the contents of Secrets enables access to ServiceAccount credentials +in the namespace, which would allow API access as any ServiceAccount +in the namespace (a form of privilege escalation). -### Core Component Roles +### Core component roles @@ -578,7 +705,7 @@ It does not allow viewing secrets, since those are escalating. - + @@ -588,28 +715,27 @@ It does not allow viewing secrets, since those are escalating. - + - - + - +
system:kube-scheduler system:kube-scheduler userAllows access to the resources required by the kube-scheduler component.Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.
system:volume-scheduler
system:kube-controller-manager system:kube-controller-manager userAllows access to the resources required by the kube-controller-manager component. -The permissions required by individual control loops are contained in the controller roles.Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. +The permissions required by individual controllers are detailed in the controller roles.
system:nodeNone in 1.8+Allows access to resources required by the kubelet component, including read access to all secrets, and write access to all pod status objects. +NoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. -As of 1.7, use of the Node authorizer and NodeRestriction admission plugin is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them. -Prior to 1.7, this role was automatically bound to the `system:nodes` group. -In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled. -In 1.8+, no binding is automatically created. +You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. + +The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8.
system:node-proxier system:kube-proxy userAllows access to the resources required by the kube-proxy component.Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
-### Other Component Roles +### Other component roles @@ -627,7 +753,7 @@ This is commonly used by add-on API servers for unified authentication and autho - + @@ -648,7 +774,7 @@ This is commonly used by add-on API servers for unified authentication and autho +kubelet TLS bootstrapping. @@ -662,73 +788,80 @@ This is commonly used by add-on API servers for unified authentication and autho
system:heapster NoneRole for the Heapster component.Role for the Heapster component (deprecated).
system:kube-aggregatorsystem:node-bootstrapper None Allows access to the resources required to perform -Kubelet TLS bootstrapping.
system:node-problem-detector
-### Controller Roles +### Roles for built-in controllers {#controller-roles} -The [Kubernetes controller manager](/docs/admin/kube-controller-manager/) runs core control loops. -When invoked with `--use-service-account-credentials`, each control loop is started using a separate service account. -Corresponding roles exist for each control loop, prefixed with `system:controller:`. -If the controller manager is not started with `--use-service-account-credentials`, -it runs all control loops using its own credential, which must be granted all the relevant roles. +The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs +{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes +control plane. +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller +using a separate service account. +Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops +using its own credential, which must be granted all the relevant roles. These roles include: -* system:controller:attachdetach-controller -* system:controller:certificate-controller -* system:controller:clusterrole-aggregation-controller -* system:controller:cronjob-controller -* system:controller:daemon-set-controller -* system:controller:deployment-controller -* system:controller:disruption-controller -* system:controller:endpoint-controller -* system:controller:expand-controller -* system:controller:generic-garbage-collector -* system:controller:horizontal-pod-autoscaler -* system:controller:job-controller -* system:controller:namespace-controller -* system:controller:node-controller -* system:controller:persistent-volume-binder -* system:controller:pod-garbage-collector -* system:controller:pv-protection-controller -* system:controller:pvc-protection-controller -* system:controller:replicaset-controller -* system:controller:replication-controller -* system:controller:resourcequota-controller -* system:controller:root-ca-cert-publisher -* system:controller:route-controller -* system:controller:service-account-controller -* system:controller:service-controller -* system:controller:statefulset-controller -* system:controller:ttl-controller +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` -## Privilege Escalation Prevention and Bootstrapping +## Privilege escalation prevention and bootstrapping The RBAC API prevents users from escalating privileges by editing roles or role bindings. Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. -A user can only create/update a role if at least one of the following things is true: +### Restrictions on role creation or update -1. They already have all the permissions contained in the role, at the same scope as the object being modified -(cluster-wide for a `ClusterRole`, within the same namespace or cluster-wide for a `Role`) -2. They are given explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer) +You can only create/update a role if at least one of the following things is true: -For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRole` +1. You already have all the permissions contained in the role, at the same scope as the object being modified +(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). +2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. + +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole containing that permission. To allow a user to create/update roles: -1. Grant them a role that allows them to create/update `Role` or `ClusterRole` objects, as desired. -2. Grant them permission to include specific permissions in the roles the create/update: - * implicitly, by giving them those permissions (if they attempt to create or modify a `Role` or `ClusterRole` with permissions they themselves have not been granted, the API request will be forbidden) - * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer) +1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. +2. Grant them permission to include specific permissions in the roles they create/update: + * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) + * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group -A user can only create/update a role binding if they already have all the permissions contained in the referenced role -(at the same scope as the role binding) *or* if they've been given explicit permission to perform the `bind` verb on the referenced role. -For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRoleBinding` +### Restrictions on role binding creation or update + +You can only create/update a role binding if you already have all the permissions contained in the referenced role +(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding to a role that grants that permission. To allow a user to create/update role bindings: -1. Grant them a role that allows them to create/update `RoleBinding` or `ClusterRoleBinding` objects, as desired. +1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. 2. Grant them permissions needed to bind a particular role: * implicitly, by giving them the permissions contained in the role. - * explicitly, by giving them permission to perform the `bind` verb on the particular role (or cluster role). + * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). -For example, this cluster role and role binding would allow "user-1" to grant other users the `admin`, `edit`, and `view` roles in the "user-1-namespace" namespace: +For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -762,126 +895,126 @@ subjects: When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. To bootstrap initial roles and role bindings: -* Use a credential with the `system:masters` group, which is bound to the `cluster-admin` super-user role by the default bindings. +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. * If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. -## Command-line Utilities +## Command-line utilities ### `kubectl create role` -Creates a `Role` object defining permissions within a single namespace. Examples: +Creates a Role object defining permissions within a single namespace. Examples: -* Create a `Role` named "pod-reader" that allows user to perform "get", "watch" and "list" on pods: +* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: - ``` + ```shell kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods ``` -* Create a `Role` named "pod-reader" with resourceNames specified: +* Create a Role named "pod-reader" with resourceNames specified: - ``` + ```shell kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a `Role` named "foo" with apiGroups specified: +* Create a Role named "foo" with apiGroups specified: - ``` + ```shell kubectl create role foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a `Role` named "foo" with subresource permissions: +* Create a Role named "foo" with subresource permissions: - ``` + ```shell kubectl create role foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a `Role` named "my-component-lease-holder" with permissions to get/update a resource with a specific name: +* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: - ``` + ```shell kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component ``` ### `kubectl create clusterrole` -Creates a `ClusterRole` object. Examples: +Creates a ClusterRole. Examples: -* Create a `ClusterRole` named "pod-reader" that allows user to perform "get", "watch" and "list" on pods: +* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: - ``` + ```shell kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods ``` -* Create a `ClusterRole` named "pod-reader" with resourceNames specified: +* Create a ClusterRole named "pod-reader" with resourceNames specified: - ``` + ```shell kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a `ClusterRole` named "foo" with apiGroups specified: +* Create a ClusterRole named "foo" with apiGroups specified: - ``` + ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a `ClusterRole` named "foo" with subresource permissions: +* Create a ClusterRole named "foo" with subresource permissions: - ``` + ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a `ClusterRole` name "foo" with nonResourceURL specified: +* Create a ClusterRole named "foo" with nonResourceURL specified: - ``` + ```shell kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* ``` -* Create a `ClusterRole` name "monitoring" with aggregationRule specified: +* Create a ClusterRole named "monitoring" with an aggregationRule specified: - ``` + ```shell kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" ``` ### `kubectl create rolebinding` -Grants a `Role` or `ClusterRole` within a specific namespace. Examples: +Grants a Role or ClusterRole within a specific namespace. Examples: -* Within the namespace "acme", grant the permissions in the `admin` `ClusterRole` to a user named "bob": +* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": - ``` + ```shell kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the `view` `ClusterRole` to the service account in the namespace "acme" named "myapp" : +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": - ``` + ```shell kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the `view` `ClusterRole` to a service account in the namespace "myappnamespace" named "myapp": +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": - ``` + ```shell kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme ``` ### `kubectl create clusterrolebinding` -Grants a `ClusterRole` across the entire cluster, including all namespaces. Examples: +Grants a ClusterRole across the entire cluster (all namespaces). Examples: -* Across the entire cluster, grant the permissions in the `cluster-admin` `ClusterRole` to a user named "root": +* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": - ``` + ```shell kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root ``` -* Across the entire cluster, grant the permissions in the `system:node-proxier ` `ClusterRole` to a user named "system:kube-proxy": +* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": - ``` + ```shell kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy ``` -* Across the entire cluster, grant the permissions in the `view` `ClusterRole` to a service account named "myapp" in the namespace "acme": +* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": - ``` + ```shell kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp ``` @@ -901,33 +1034,32 @@ Examples: * Test applying a manifest file of RBAC objects, displaying changes that would be made: - ``` + ```shell kubectl auth reconcile -f my-rbac-rules.yaml --dry-run ``` * Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): - ``` + ```shell kubectl auth reconcile -f my-rbac-rules.yaml ``` * Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): - ``` + ```shell kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions ``` -See the CLI help for detailed usage. - -## Service Account Permissions +## ServiceAccount permissions {#service-account-permissions} Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace (beyond discovery permissions given to all authenticated users). -This allows you to grant particular roles to particular service accounts as needed. +This allows you to grant particular roles to particular ServiceAccounts as needed. Fine-grained role bindings provide greater security, but require more effort to administrate. -Broader grants can give unnecessary (and potentially escalating) API access to service accounts, but are easier to administrate. +Broader grants can give unnecessary (and potentially escalating) API access to +ServiceAccounts, but are easier to administrate. In order from most secure to least secure, the approaches are: @@ -949,9 +1081,10 @@ In order from most secure to least secure, the approaches are: If an application does not specify a `serviceAccountName`, it uses the "default" service account. - {{< note >}}Permissions given to the "default" service - account are available to any pod in the namespace that does not - specify a `serviceAccountName`.{{< /note >}} + {{< note >}} + Permissions given to the "default" service account are available to any pod + in the namespace that does not specify a `serviceAccountName`. + {{< /note >}} For example, grant read-only permission within "my-namespace" to the "default" service account: @@ -962,12 +1095,15 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` - Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the `kube-system` namespace. - To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace. + Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the + "default" service account in the `kube-system` namespace. + To allow those add-ons to run with super-user access, grant cluster-admin + permissions to the "default" service account in the `kube-system` namespace. - {{< note >}}Enabling this means the `kube-system` - namespace contains secrets that grant super-user access to the - API.{{< /note >}} + {{< caution >}} + Enabling this means the `kube-system` namespace contains Secrets + that grant super-user access to your cluster's API. + {{< /caution >}} ```shell kubectl create clusterrolebinding add-on-cluster-admin \ @@ -1006,9 +1142,9 @@ In order from most secure to least secure, the approaches are: If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. {{< warning >}} - This allows any user with read access - to secrets or the ability to create a pod to access super-user - credentials. + This allows any application full access to your cluster, and also grants + any user with read access to Secrets (or the ability to create any pod) + full access to your cluster. {{< /warning >}} ```shell @@ -1017,10 +1153,11 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` -## Upgrading from 1.5 +## Upgrading from ABAC -Prior to Kubernetes 1.6, many deployments used very permissive ABAC policies, -including granting full API access to all service accounts. +Clusters that originally ran older Kubernetes versions often used +permissive ABAC policies, including granting full API access to all +service accounts. Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace @@ -1029,28 +1166,31 @@ and controllers, but grant *no permissions* to service accounts outside the `kub While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. Here are two approaches for managing this transition: -### Parallel Authorizers +### Parallel authorizers Run both the RBAC and ABAC authorizers, and specify a policy file that contains -[the legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): +the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): ``` ---authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -The RBAC authorizer will attempt to authorize requests first. If it denies an API request, -the ABAC authorizer is then run. This means that any request allowed by *either* the RBAC -or ABAC policies is allowed. +To explain that first command line option in detail: if earlier authorizers, such as Node, +deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC +also denies that API request, the ABAC authorizer is then run. This means that any request +allowed by *either* the RBAC or ABAC policies is allowed. -When the apiserver is run with a log level of 5 or higher for the RBAC component (`--vmodule=rbac*=5` or `--v=5`), -you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`). +When the kube-apiserver is run with a log level of 5 or higher for the RBAC component +(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log +(prefixed with `RBAC DENY:`). You can use that information to determine which roles need to be granted to which users, groups, or service accounts. -Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages -in the server logs, you can remove the ABAC authorizer. -## Permissive RBAC Permissions +Once you have [granted roles to service accounts](#service-account-permissions) and workloads +are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. -You can replicate a permissive policy using RBAC role bindings. +### Permissive RBAC permissions + +You can replicate a permissive ABAC policy using RBAC role bindings. {{< warning >}} The following policy allows **ALL** service accounts to act as cluster administrators. @@ -1058,7 +1198,7 @@ Any application running in a container receives service account credentials auto and could perform any action against the API, including viewing secrets and modifying permissions. This is not a recommended policy. -``` +```shell kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ @@ -1067,4 +1207,7 @@ kubectl create clusterrolebinding permissive-binding \ ``` {{< /warning >}} +After you have transitioned to use RBAC, you should adjust the access controls +for your cluster to ensure that these meet your information security needs. + {{% /capture %}} diff --git a/content/en/docs/reference/glossary/kube-scheduler.md b/content/en/docs/reference/glossary/kube-scheduler.md index e3babcab3f..a1a91a1527 100755 --- a/content/en/docs/reference/glossary/kube-scheduler.md +++ b/content/en/docs/reference/glossary/kube-scheduler.md @@ -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. diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 493e2ae5ef..f51ada8f6d 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -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 >}} diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md new file mode 100644 index 0000000000..23fd828fa7 --- /dev/null +++ b/content/id/docs/concepts/cluster-administration/networking.md @@ -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 %}} diff --git a/content/id/docs/concepts/overview/working-with-objects/labels.md b/content/id/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..0b6060e2fd --- /dev/null +++ b/content/id/docs/concepts/overview/working-with-objects/labels.md @@ -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 %}} diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md new file mode 100644 index 0000000000..3dad74fb07 --- /dev/null +++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md @@ -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: +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: + Mounts: + Volumes: +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 %}} diff --git a/content/id/examples/controllers/replication.yaml b/content/id/examples/controllers/replication.yaml new file mode 100644 index 0000000000..e43ccbc32d --- /dev/null +++ b/content/id/examples/controllers/replication.yaml @@ -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 \ No newline at end of file diff --git a/content/pl/_index.html b/content/pl/_index.html index 4d7de6d3b4..4e55c429bd 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -45,12 +45,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr


- Weź udział w KubeCon w Amsterdamie 30.03-2.04.2020 + Weź udział w KubeCon w Amsterdamie (lipiec/sierpień)



- Weź udział w KubeCon w Szanghaju 28-30.07.2020 + Weź udział w KubeCon w Bostonie 17-20.11.2020
diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md index 8be3830b9c..3f147f5f43 100644 --- a/content/pl/docs/concepts/_index.md +++ b/content/pl/docs/concepts/_index.md @@ -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żą: diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md index eda8ed7519..966f67b004 100644 --- a/content/pl/docs/concepts/overview/components.md +++ b/content/pl/docs/concepts/overview/components.md @@ -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 diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 5813ada50e..40dc3344b1 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -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 %}} diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index f03f7857bd..28a2e77ebc 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -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 diff --git a/content/pl/docs/contribute/_index.md b/content/pl/docs/contribute/_index.md index ad2a2adb70..bd40241596 100644 --- a/content/pl/docs/contribute/_index.md +++ b/content/pl/docs/contribute/_index.md @@ -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 diff --git a/content/pl/docs/home/_index.md b/content/pl/docs/home/_index.md index 662670fb51..f6382cdd84 100644 --- a/content/pl/docs/home/_index.md +++ b/content/pl/docs/home/_index.md @@ -14,6 +14,8 @@ menu: weight: 20 post: >

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 pomóc w jej tworzeniu!

+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 (CNCF). 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. diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md index 92177da44b..41a213e5e3 100644 --- a/content/pl/docs/reference/_index.md +++ b/content/pl/docs/reference/_index.md @@ -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 diff --git a/content/pl/docs/reference/glossary/cluster.md b/content/pl/docs/reference/glossary/cluster.md index 0021caefe0..eebf2a4fa9 100755 --- a/content/pl/docs/reference/glossary/cluster.md +++ b/content/pl/docs/reference/glossary/cluster.md @@ -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ł. -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. diff --git a/content/pl/docs/reference/glossary/container-runtime.md b/content/pl/docs/reference/glossary/container-runtime.md index 804e367a70..170d500221 100644 --- a/content/pl/docs/reference/glossary/container-runtime.md +++ b/content/pl/docs/reference/glossary/container-runtime.md @@ -15,7 +15,7 @@ tags: -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). diff --git a/content/pl/docs/reference/glossary/kube-controller-manager.md b/content/pl/docs/reference/glossary/kube-controller-manager.md index 4a3a4e64b5..cd1ac2adfa 100755 --- a/content/pl/docs/reference/glossary/kube-controller-manager.md +++ b/content/pl/docs/reference/glossary/kube-controller-manager.md @@ -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" >}}. diff --git a/content/pl/docs/reference/glossary/kube-proxy.md b/content/pl/docs/reference/glossary/kube-proxy.md index 9a555dbe91..c985c4b55a 100755 --- a/content/pl/docs/reference/glossary/kube-proxy.md +++ b/content/pl/docs/reference/glossary/kube-proxy.md @@ -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">}}. -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. diff --git a/content/pl/docs/reference/glossary/kube-scheduler.md b/content/pl/docs/reference/glossary/kube-scheduler.md index 074680ac02..4bbcc99a0f 100755 --- a/content/pl/docs/reference/glossary/kube-scheduler.md +++ b/content/pl/docs/reference/glossary/kube-scheduler.md @@ -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. -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. diff --git a/content/pl/docs/reference/glossary/kubelet.md b/content/pl/docs/reference/glossary/kubelet.md index ad957da9a7..551f5406a6 100755 --- a/content/pl/docs/reference/glossary/kubelet.md +++ b/content/pl/docs/reference/glossary/kubelet.md @@ -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" >}}. - + 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. diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index 0d0fde34b8..8875cd6afd 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -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)| | ✔ | ✔ | | | -| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | | -| [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/) | ✔ | | | | | -| [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | -| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ | -| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | -| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | -| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | -| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| -| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ -| [Containership](https://containership.io) | ✔ |✔ | | | | -| [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) | | | | | | ✔ -| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | -| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ -| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ -| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ -| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | -| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | -| [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/) | |✔| ✔ | | | -| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | -| [KubeSail](https://kubesail.com/) | ✔ | | | | | -| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | -| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | -| [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/) | | | ✔ | | | -| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | -| [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) | ✔ | ✔ | | | | -| [oVirt](https://www.ovirt.org/) | | | | | ✔ | -| [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/) | ✔ | ✔ | ✔ -| [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/)  | ✔ | ✔ | | | | -| [Supergiant](https://supergiant.io/) | |✔ | | | | -| [SUSE](https://www.suse.com/) | | ✔ | | | | -| [SysEleven](https://www.syseleven.io/) | ✔ | | | | | -| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | -| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | -| [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/) | ✔ | | | | | | +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 %}} diff --git a/content/pl/docs/tasks/_index.md b/content/pl/docs/tasks/_index.md index 1d96d99a0b..253cd26cd2 100644 --- a/content/pl/docs/tasks/_index.md +++ b/content/pl/docs/tasks/_index.md @@ -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_. diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index 6005968936..0723c6f4a4 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -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/) diff --git a/content/pl/docs/tutorials/hello-minikube.md b/content/pl/docs/tutorials/hello-minikube.md index f962199317..1a7da3cd3c 100644 --- a/content/pl/docs/tutorials/hello-minikube.md +++ b/content/pl/docs/tutorials/hello-minikube.md @@ -8,7 +8,7 @@ menu: weight: 10 post: >

Jesteś gotowy ubrudzić ręce? Zbuduj własny klaster kubernetes z działającą na nim aplikacją "Hello World" w Node.js.

-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 80/TCP 26s + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 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 %}} diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 64b9336dec..e5d4769916 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -77,14 +77,14 @@ weight: 10
-

Węzły typu master zarządzają klastrem, pozostałe węzły są wykorzystywane do uruchamiania na nich aplikacji.

+

Węzły typu master zarządzają klastrem i węzłami wykorzystywanymi do uruchamiania aplikacji.

-

Kiedy instalujesz aplikację na Kubernetes, polecasz masterowi uruchomienie kontenera z aplikacją. Master zleca uruchomienie kontenera na węzłach klastra. Węzły komunikują się z masterem przy użyciu Kubernetes API, wystawianego przez mastera. Użytkownicy końcowi mogą korzystać bezpośrednio z Kubernetes API do komunikacji z klastrem.

+

Kiedy instalujesz aplikację na Kubernetes, polecasz masterowi uruchomienie kontenera z aplikacją. Master zleca uruchomienie kontenera na węzłach klastra. Węzły komunikują się z masterem przy użyciu Kubernetes API, wystawianego przez mastera. Użytkownicy końcowi mogą korzystać bezpośrednio z Kubernetes API do komunikacji z klastrem.

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.

diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index be179683c1..ea083b33e7 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -17,7 +17,16 @@ weight: 20
+
+
+

+ Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. Dowiedz się więcej na temat Podów. +

+
+
+
+
Do pracy z terminalem użyj wersji na desktop/tablet diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 2dd9a35e99..d3fa9a8343 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -81,11 +81,6 @@ weight: 10
-
-
-

Możemy połączyć tworzenie Deploymentu i Serwisu stosując opcję
--expose w kubectl.

-
-

diff --git a/content/pl/examples/minikube/Dockerfile b/content/pl/examples/minikube/Dockerfile index 1fe745295a..dd58cb7e75 100644 --- a/content/pl/examples/minikube/Dockerfile +++ b/content/pl/examples/minikube/Dockerfile @@ -1,4 +1,4 @@ FROM node:6.14.2 EXPOSE 8080 COPY server.js . -CMD node server.js +CMD [ "node", "server.js" ] diff --git a/content/ru/docs/concepts/_index.md b/content/ru/docs/concepts/_index.md index 997a1b2b59..b2e7e77c79 100644 --- a/content/ru/docs/concepts/_index.md +++ b/content/ru/docs/concepts/_index.md @@ -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 diff --git a/content/ru/docs/concepts/overview/components.md b/content/ru/docs/concepts/overview/components.md index 9689c2e1fd..d1e417cd85 100644 --- a/content/ru/docs/concepts/overview/components.md +++ b/content/ru/docs/concepts/overview/components.md @@ -23,7 +23,7 @@ card: {{% capture body %}} -## Панель управления компонентами +## Плоскость управления компонентами Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик). diff --git a/content/ru/docs/contribute/style/style-guide.md b/content/ru/docs/contribute/style/style-guide.md index 612111c673..5a74f1ed0f 100644 --- a/content/ru/docs/contribute/style/style-guide.md +++ b/content/ru/docs/contribute/style/style-guide.md @@ -74,7 +74,7 @@ PodList — это список Pod. | Pod List — это список подо Можно | Нельзя :--| :----- _Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ... -Эти компоненты формируют _панель управления_. | Эти компоненты формируют **панель управления**. +Эти компоненты формируют _плоскость управления_. | Эти компоненты формируют **плоскость управления**. {{< /table >}} ### Оформляйте как код имена файлов, директории и пути diff --git a/content/ru/docs/reference/glossary/cluster.md b/content/ru/docs/reference/glossary/cluster.md index 79e10c8fcc..00c5609b48 100644 --- a/content/ru/docs/reference/glossary/cluster.md +++ b/content/ru/docs/reference/glossary/cluster.md @@ -14,4 +14,4 @@ tags: Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. -В рабочих узлах размещены поды, являющиеся компонентами приложения. Панель управления управляет рабочими узлами и подами в кластере. В промышленных средах панель управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. +В рабочих узлах размещены поды, являющиеся компонентами приложения. Плоскость управления управляет рабочими узлами и подами в кластере. В промышленных средах плоскость управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. diff --git a/content/ru/docs/reference/glossary/node.md b/content/ru/docs/reference/glossary/node.md index 0a2cc77e62..34f68b99b0 100755 --- a/content/ru/docs/reference/glossary/node.md +++ b/content/ru/docs/reference/glossary/node.md @@ -14,4 +14,4 @@ tags: -Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< 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" >}}. diff --git a/content/ru/docs/setup/learning-environment/minikube.md b/content/ru/docs/setup/learning-environment/minikube.md index 1e0cb02673..586a491ad3 100644 --- a/content/ru/docs/setup/learning-environment/minikube.md +++ b/content/ru/docs/setup/learning-environment/minikube.md @@ -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 diff --git a/content/ru/docs/tutorials/hello-minikube.md b/content/ru/docs/tutorials/hello-minikube.md index 845ccc3600..7bbb5b0f2b 100644 --- a/content/ru/docs/tutorials/hello-minikube.md +++ b/content/ru/docs/tutorials/hello-minikube.md @@ -8,7 +8,7 @@ menu: weight: 10 post: >

Готовы испачкать руки? Создайте простой кластер Kubernetes с запуском "Hello World" на Node.js

-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 diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index 1971035ebd..9c07ff3097 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -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` 服务会自动创建。通过请求 `:`，可以从集群的外部访问一个 `NodePort` 服务。 * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。 diff --git a/content/zh/docs/reference/glossary/applications.md b/content/zh/docs/reference/glossary/applications.md index cd02a4ee14..cbff609142 100644 --- a/content/zh/docs/reference/glossary/applications.md +++ b/content/zh/docs/reference/glossary/applications.md @@ -23,4 +23,5 @@ tags: - fundamental --- --> + 各种容器化应用运行所在的层。 diff --git a/content/zh/docs/reference/glossary/control-plane.md b/content/zh/docs/reference/glossary/control-plane.md index 1916feac7f..05f3f57978 100644 --- a/content/zh/docs/reference/glossary/control-plane.md +++ b/content/zh/docs/reference/glossary/control-plane.md @@ -25,7 +25,8 @@ tags: - fundamental --- --> + - 容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 \ No newline at end of file + 容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 diff --git a/content/zh/docs/reference/glossary/pod-lifecycle.md b/content/zh/docs/reference/glossary/pod-lifecycle.md index 67376a475c..bb3811ccf8 100644 --- a/content/zh/docs/reference/glossary/pod-lifecycle.md +++ b/content/zh/docs/reference/glossary/pod-lifecycle.md @@ -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 生命周期 -id: pod-lifecycle -date: 2019-02-17 -full-link: /docs/concepts/workloads/pods/pod-lifecycle/ -related: - - pod - - container -tags: - - fundamental -short_description: > - 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 - ---- + + + 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 - + + diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh/docs/reference/glossary/service.md index 67a1ba8404..54a03b3b1a 100755 --- a/content/zh/docs/reference/glossary/service.md +++ b/content/zh/docs/reference/glossary/service.md @@ -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: diff --git a/content/zh/docs/reference/glossary/storage-class.md b/content/zh/docs/reference/glossary/storage-class.md index 52886478eb..49cadefe44 100644 --- a/content/zh/docs/reference/glossary/storage-class.md +++ b/content/zh/docs/reference/glossary/storage-class.md @@ -1,20 +1,3 @@ - - --- title: 存储类别 id: storageclass @@ -29,9 +12,30 @@ tags: - storage --- + + + + StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 + diff --git a/content/zh/docs/reference/glossary/upstream.md b/content/zh/docs/reference/glossary/upstream.md index 7f2c7ded3e..118b3838f7 100644 --- a/content/zh/docs/reference/glossary/upstream.md +++ b/content/zh/docs/reference/glossary/upstream.md @@ -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: diff --git a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md index a7de28d98b..53795cf0d6 100644 --- a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -3,8 +3,21 @@ title: 为容器设置环境变量 content_template: templates/task --- + + {{% capture overview %}} + + 本页将展示如何为 kubernetes Pod 下的容器设置环境变量。 {{% /capture %}} @@ -19,46 +32,81 @@ content_template: templates/task {{% capture steps %}} + + ## 为容器设置一个环境变量 + + 创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 `env` 或者 `envFrom` 字段来设置环境变量。 + + 本示例中，将创建一个只包含单个容器的 Pod。Pod 的配置文件中设置环境变量的名称为 `DEMO_GREETING`， 其值为 `"Hello from the environment"`。下面是 Pod 的配置文件内容： {{< codenew file="pods/inject/envars.yaml" >}} + 1. 基于 YAML 文件创建一个 Pod： ```shell kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml ``` - + + 1. 获取一下当前正在运行的 Pods 信息： ```shell kubectl get pods -l purpose=demonstrate-envars ``` - + + 查询结果应为： ```shell NAME READY STATUS RESTARTS AGE envar-demo 1/1 Running 0 9s ``` - + + 1. 进入该 Pod 下的容器并打开一个命令终端： ```shell kubectl exec -it envar-demo -- /bin/bash ``` + 1. 在命令终端中通过执行 `printenv` 打印出环境变量。 ```shell root@envar-demo:/# printenv ``` + 打印结果应为： ```shell @@ -69,7 +117,10 @@ content_template: templates/task DEMO_GREETING=Hello from the environment DEMO_FAREWELL=Such a sweet sorrow ``` - + + 1. 通过键入 `exit` 退出命令终端。 + * 有关环境变量的更多信息，请参阅[这里](/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 %}} - - - diff --git a/content/zh/docs/tasks/job/parallel-processing-expansion.md b/content/zh/docs/tasks/job/parallel-processing-expansion.md index 5cbdc3e8da..e113804e73 100644 --- a/content/zh/docs/tasks/job/parallel-processing-expansion.md +++ b/content/zh/docs/tasks/job/parallel-processing-expansion.md @@ -1,302 +1,341 @@ ---- -title: 使用扩展进行并行处理 -content_template: templates/concept -weight: 20 ---- - - - -{{% capture overview %}} - - -在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes 作业。您可能希望熟悉 -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本、非并行使用。 - -{{% /capture %}} - - -{{% capture body %}} - - - -## 基本模板扩展 - - -首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中 - -{{< codenew file="application/job/job-tmpl.yaml" >}} - - -与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是作业对象的 yaml 表示， -YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。 - - -在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并休眠一段时间。 -在真实的用例中，处理将是一些重要的计算，例如呈现电影的帧，或者处理数据库中的一系列行。例如，`$ITEM` 参数将指定帧号或行范围。 - - -这个作业及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。 -这个标签使得我们可以方便地同时操作组中的所有作业。 -我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些作业的所有 pod。 -创建作业之后，系统将添加更多的标签来区分一个作业的 pod 和另一个作业的 pod。 -注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。 - - -下一步，将模板展开到多个文件中，每个文件对应要处理的项。 - -```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 -``` - - -检查是否工作正常： - -```shell -$ ls jobs/ -job-apple.yaml -job-banana.yaml -job-cherry.yaml -``` - - -在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。 -您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成作业对象。 - - -接下来，使用 kubectl 命令创建所有作业： - -```shell -$ kubectl create -f ./jobs -job "process-item-apple" created -job "process-item-banana" created -job "process-item-cherry" created -``` - - -现在，检查这些作业： - -```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 -``` - - -在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。) - - -我们可以检查 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 -``` - - -没有一个命令可以一次检查所有作业的输出，但是循环遍历所有 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 -``` - - - -## 多个模板参数 - - -在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。 -但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。 - - -这个稍微复杂一点的示例使用 jinja2 板语言来生成我们的对象。 -我们将使用一行 python 脚本将模板转换为文件。 - - -首先，粘贴作业对象的以下模板到一个名为 `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 %} - -``` - - -上面的模板使用 python dicts 列表（第1-4行）定义每个作业对象的参数。 -然后 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。 -我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。 -我们可以将输出直接传递给 kubectl 来创建对象。 - - -如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。 -现在，使用这个一行 python 程序来展开模板: - -```shell -alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' -``` - - - -输出可以保存到一个文件，像这样： - -```shell -cat job.yaml.jinja2 | render_template > jobs.yaml -``` - - -或直接发送到 kubectl，如下所示： - -```shell -cat job.yaml.jinja2 | render_template | kubectl create -f - -``` - - -## 替代方案 - - -如果您有大量作业对象，您可能会发现： - - - -- 即使使用标签，管理这么多作业对象也很麻烦。 -- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建作业并等待其完成。 -- 同时创建的大量作业会使 Kubernetes apiserver、控制器或调度程序过载。 - - - -在这种情况下，您可以考虑 -其他[工作模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 - -{{% /capture %}} +--- +title: 使用扩展进行并行处理 +content_template: templates/concept +min-kubernetes-server-version: v1.8 +weight: 20 +--- + + + +{{% capture overview %}} + + +在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes Job。您可能需要先熟悉 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本概念、非并行以及如何使用它。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 基本模板扩展 + + +首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。 + +{{< codenew file="application/job/job-tmpl.yaml" >}} + + +与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是 Job 对象的 yaml 表示， +YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。 + + +在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并睡眠一段时间。 +在真实的用例中，处理将是一些重要的计算，例如渲染电影的一帧，或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。 + + +这个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。 +这个标签使得我们可以方便地同时操作组中的所有作业。 +我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些 Job 的所有 pod。 +创建作业之后，系统将添加更多的标签来区分一个 Job 的 pod 和另一个 Job 的 pod。 +注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。 + + +下一步，将模板展开到多个文件中，每个文件对应要处理的项。 + +```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 +``` + + +检查是否工作正常： + +```shell +ls jobs/ +``` + + +输出类似以下内容： + +``` +job-apple.yaml +job-banana.yaml +job-cherry.yaml +``` + + +在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。 +您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成 Job 对象。 + + +接下来，使用 kubectl 命令创建所有作业： + +```shell +kubectl create -f ./jobs +``` + + +输出类似以下内容： + +``` +job.batch/process-item-apple created +job.batch/process-item-banana created +job.batch/process-item-cherry created +``` + + +现在，检查这些作业： + +```shell +kubectl get jobs -l jobgroup=jobexample +``` + + +输出类似以下内容： + +``` +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 +``` + + +在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。) + + +使用同样的标签选择器，我们还可以检查 pods： + +```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 +``` + + +我们可以使用以下操作命令一次性地检查所有作业的输出： + +```shell +kubectl logs -f -l jobgroup=jobexample +``` + + +输出内容为： + +``` +Processing item apple +Processing item banana +Processing item cherry +``` + + + +## 多个模板参数 + + +在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。 +但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。 + + +这个稍微复杂一点的示例使用 jinja2 模板语言来生成我们的对象。 +我们将使用一行 python 脚本将模板转换为文件。 + + +首先，粘贴 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 %} + +``` + + +上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。 +然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。 +我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。 +我们可以将输出直接传递给 kubectl 来创建对象。 + + +如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。 +现在，使用这个一行 python 程序来展开模板: + +```shell +alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' +``` + + + +输出可以保存到一个文件，像这样： + +```shell +cat job.yaml.jinja2 | render_template > jobs.yaml +``` + + +或直接发送到 kubectl，如下所示： + +```shell +cat job.yaml.jinja2 | render_template | kubectl apply -f - +``` + + +## 替代方案 + + +如果您有大量作业对象，您可能会发现： + + + +- 即使使用标签，管理这么多 Job 对象也很麻烦。 +- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建 Job 并等待其完成。 +- 同时创建大量作业会使 Kubernetes apiserver、控制器或者调度器负压过大。 + + + +在这种情况下，您可以考虑其他的[作业模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 + +{{% /capture %}} diff --git a/content/zh/docs/tutorials/hello-minikube.md b/content/zh/docs/tutorials/hello-minikube.md index a8587d6967..c10be6b6f9 100644 --- a/content/zh/docs/tutorials/hello-minikube.md +++ b/content/zh/docs/tutorials/hello-minikube.md @@ -30,12 +30,13 @@ card: --> {{% capture overview %}} + -本教程向您展示如何使用 [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 >}} @@ -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" >}} + @@ -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 >}} + -## 创建 Minikube 集群 - -1. 点击 **启动终端** - {{< kat-button >}} - - {{< note >}}如果您本地安装了 Minikube, 运行 `minikube start`.{{< /note >}} - 2. 在浏览器中打开 Kubernetes dashboard： ```shell minikube dashboard ``` + + 3. 仅限 Katacoda 环境：在终端窗口的顶部，单击加号，然后单击 **选择要在主机 1 上查看的端口**。 4. 仅限 Katacoda 环境：输入“30000”，然后单击 **显示端口**。 + ## 创建 Deployment Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 + + 1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker 镜像运行 Container。 ```shell kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node ``` + + 2. 查看 Deployment： ```shell kubectl get deployments ``` - 输出: + + + 输出结果类似于这样： - ```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. 查看 Pod： ```shell kubectl get pods ``` - 输出: - ```shell + + + 输出结果类似于这样： + + ``` NAME READY STATUS RESTARTS AGE hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m ``` + + 4. 查看集群事件： ```shell kubectl get events ``` + + 5. 查看 `kubectl` 配置： ```shell kubectl config view ``` + + {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/docs/user-guide/kubectl-overview/)。{{< /note >}} + ## 创建 Service 默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。要使得 `hello-node` 容器可以从 Kubernetes 虚拟网络的外部访问，您必须将 Pod 暴露为 Kubernetes [*Service*](/docs/concepts/services-networking/service/)。 + + 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. 查看您刚刚创建的服务: ```shell kubectl get services ``` - 输出: + - ```shell + 输出结果类似于这样: + + ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s kubernetes ClusterIP 10.96.0.1 443/TCP 23m ``` + 在支持负载均衡器的云服务提供商上，将提供一个外部 IP 来访问该服务。在 Minikube 上，`LoadBalancer` 使得服务可以通过命令 `minikube service` 访问。 + 3. 运行下面的命令： ```shell minikube service hello-node ``` + 4. 仅限 Katacoda 环境：单击加号，然后单击 **选择要在主机 1 上查看的端口**。 -5. 仅限 Katacoda 环境：输入 `30369`（请参阅服务输出中与 `8080` 相对的端口），然后单击 + +5. 仅限 Katacoda 环境：请注意在 service 输出中与 `8080` 对应的长度为 5 位的端口号。此端口号是随机生成的，可能与您不同。在端口号文本框中输入您自己的端口号，然后单击显示端口。如果是上面那个例子，就需要输入 `30369`。 这将打开一个浏览器窗口，为您的应用程序提供服务并显示 “Hello World” 消息。 ## 启用插件 -Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用、禁用和打开。 +Minikube 有一组内置的 {{< glossary_tooltip text="插件" term_id="addons" >}}，可以在本地 Kubernetes 环境中启用、禁用和打开。 1. 列出当前支持的插件： @@ -396,37 +303,55 @@ Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用 minikube addons list ``` - 输出: + - ```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. 启用插件，例如 `metrics-server`： ```shell - minikube addons enable heapster + minikube addons enable metrics-server ``` - 输出: + + + 输出结果类似于这样： - ```shell - heapster was successfully enabled ``` + metrics-server was successfully enabled + ``` + + 3. 查看刚才创建的 Pod 和 Service： @@ -434,59 +359,60 @@ Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用 kubectl get pod,svc -n kube-system ``` - 输出: + - ```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 80/TCP 26s + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m - service/kubernetes-dashboard NodePort 10.109.29.1 80:30000/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s ``` -4. 禁用 `heapster`： + + +4. 禁用 `metrics-server`： + ```shell - minikube addons disable heapster + minikube addons disable metrics-server ``` - 输出: + - ```shell - heapster was successfully disabled + 输出结果类似于这样： + + ``` + metrics-server was successfully disabled ``` + ## 清理 现在可以清理您在集群中创建的资源： @@ -496,13 +422,21 @@ kubectl delete service hello-node kubectl delete deployment hello-node ``` -可以停止 Minikube VM： + + +可选的，停止 Minikube 虚拟机（VM）： ```shell minikube stop ``` -或者，删除 Minikube VM： + + +可选的，删除 Minikube 虚拟机（VM）： ```shell minikube delete @@ -514,11 +448,11 @@ minikube delete * 进一步了解 [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 %}} diff --git a/content/zh/docs/tutorials/kubernetes-basics/_index.html b/content/zh/docs/tutorials/kubernetes-basics/_index.html index ecfbbd626a..39b52b2ce1 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/_index.html +++ b/content/zh/docs/tutorials/kubernetes-basics/_index.html @@ -1,6 +1,11 @@ --- title: 学习 Kubernetes 基础知识 linkTitle: 学习 Kubernetes 基础知识 +weight: 10 +card: + name: tutorials + weight: 20 + title: 基础知识介绍 --- diff --git a/content/zh/examples/admin/cloud/ccm-example.yaml b/content/zh/examples/admin/cloud/ccm-example.yaml index 4c98162a70..27386be675 100644 --- a/content/zh/examples/admin/cloud/ccm-example.yaml +++ b/content/zh/examples/admin/cloud/ccm-example.yaml @@ -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= # 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: "" diff --git a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml index 5e6d55a6b2..3676a0acdb 100644 --- a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml +++ b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -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= - # 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= + # 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 diff --git a/content/zh/examples/admin/dns/dnsutils.yaml b/content/zh/examples/admin/dns/dnsutils.yaml new file mode 100644 index 0000000000..5eb9833f39 --- /dev/null +++ b/content/zh/examples/admin/dns/dnsutils.yaml @@ -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 diff --git a/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml b/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml index 896d98ec2f..0a2083acd8 100644 --- a/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml +++ b/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml @@ -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: diff --git a/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml b/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml index 88c165d144..2539c2d309 100644 --- a/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml +++ b/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml @@ -1,5 +1,5 @@ -kind: PersistentVolumeClaim apiVersion: v1 +kind: PersistentVolumeClaim metadata: name: pvc-quota-demo-2 spec: diff --git a/content/zh/examples/admin/resource/quota-objects-pvc.yaml b/content/zh/examples/admin/resource/quota-objects-pvc.yaml index b38256b897..728bb4d708 100644 --- a/content/zh/examples/admin/resource/quota-objects-pvc.yaml +++ b/content/zh/examples/admin/resource/quota-objects-pvc.yaml @@ -1,5 +1,5 @@ -kind: PersistentVolumeClaim apiVersion: v1 +kind: PersistentVolumeClaim metadata: name: pvc-quota-demo spec: diff --git a/content/zh/examples/admin/sched/my-scheduler.yaml b/content/zh/examples/admin/sched/my-scheduler.yaml index ab0c385cd6..4903c6f54c 100644 --- a/content/zh/examples/admin/sched/my-scheduler.yaml +++ b/content/zh/examples/admin/sched/my-scheduler.yaml @@ -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: [] diff --git a/content/zh/examples/application/deployment-scale.yaml b/content/zh/examples/application/deployment-scale.yaml index 3bdc7b6f5b..68801c971d 100644 --- a/content/zh/examples/application/deployment-scale.yaml +++ b/content/zh/examples/application/deployment-scale.yaml @@ -14,6 +14,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.8 + image: nginx:1.14.2 ports: - containerPort: 80 diff --git a/content/zh/examples/application/deployment-update.yaml b/content/zh/examples/application/deployment-update.yaml index 8c683d6dc7..18e8be65fb 100644 --- a/content/zh/examples/application/deployment-update.yaml +++ b/content/zh/examples/application/deployment-update.yaml @@ -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 diff --git a/content/zh/examples/application/deployment.yaml b/content/zh/examples/application/deployment.yaml index 0f526b16c0..2cd599218d 100644 --- a/content/zh/examples/application/deployment.yaml +++ b/content/zh/examples/application/deployment.yaml @@ -14,6 +14,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 diff --git a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml index ec4e48bc21..7dcfb6c263 100644 --- a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml +++ b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml @@ -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 diff --git a/content/zh/examples/application/mysql/mysql-pv.yaml b/content/zh/examples/application/mysql/mysql-pv.yaml index 6f4e692f3b..c89779a83f 100644 --- a/content/zh/examples/application/mysql/mysql-pv.yaml +++ b/content/zh/examples/application/mysql/mysql-pv.yaml @@ -1,5 +1,5 @@ -kind: PersistentVolume apiVersion: v1 +kind: PersistentVolume metadata: name: mysql-pv-volume labels: diff --git a/content/zh/examples/application/mysql/mysql-statefulset.yaml b/content/zh/examples/application/mysql/mysql-statefulset.yaml index e0c04007a8..b69af02c59 100644 --- a/content/zh/examples/application/mysql/mysql-statefulset.yaml +++ b/content/zh/examples/application/mysql/mysql-statefulset.yaml @@ -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$( 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 "$( - # /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"} - - 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 - - - - type parser - format /^(?\w)(? - - - type record_reformer - enable_ruby true - tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')} - - - # Detect exceptions in the log output and forward them as one log entry. - - @type copy - - - @type prometheus - - - type counter - name logging_line_count - desc Total number of lines generated by application containers - - tag ${tag} - - - - - @type detect_exceptions - - remove_tag_prefix raw - message log - stream stream - multiline_flush_interval 5 - max_bytes 500000 - max_lines 1000 - - - 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 - - type tail - format syslog - path /var/log/startupscript.log - pos_file /var/log/gcp-startupscript.log.pos - tag startupscript - - - # 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 - - type tail - format /^time="(?