The `*.profile` file referenced do not need to be provided in a separate
file. Making them separate files is preventing Hugo 0.57.2 from correctly
building the site.
This PR separates the graduated/deprecated feature gates into a separate
table. When updating the table contents by browsing the source code, we
also found some missing items which are added in this PR as well.
(cherry picked from commit faae88f478)
1. Confirm the document content is similar as en version.
2. Merge the zh release-1.14 version into 1.15 version
3. add the 1.14 all sample into 1.15 for template work. The build looks fine.
- docs
- concepts
- architecture
* Update DaemonSet deletion documentation
The "Updating a DaemonSet" section referred to pre-1.6 behavior, where
rolling updates of DaemonSets were not supported and thus orphaned pods
from deleted DaemonSets would not be replaced by a new DaemonSet.
Describe the new behavior, where orphaned pods can be adopted by a new
DaemonSet and may be replaced depending on the update strategy in use.
* Tweak language around Pod replacement after DaemonSet deletion
* Update note about DaemonSet rolling updates
No need to call out the version in which rolling updates for DaemonSets
were introduced given how long they've been supported.
* Fix title of audit task
The content the title refers to indicates an intent of describing how
to configure auditing for multiple apiservers rather than multiple
clusters.
* Update content/en/docs/tasks/debug-application-cluster/audit.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* ID translation for assign-pod-node
* fix typo
* add pods/pod-nginx.yaml example file
* add pods/pod-with-node-affinity.yaml example file
* add pods/pod-with-pod-affinity.yaml example file
* Apply suggestions from code review
Co-Authored-By: Irvi Aini <7439590+irvifa@users.noreply.github.com>
* tidy up words following code review suggestion
A fix for the v1.15 API version was missed in the #14775 PR
because the dev-1.15 branch was forked from the master branch
before the fix and has been merged back to the master after it.
* Add a helper script for localization
The script generates a report of outdated contents in
`content/<l10n-lang>` directory by comparing two l10n
team milestone branches.
* Add description for scripts/diff_l10n_branches.py
Add shortcode, partial, and css so we can display an accouncement
site-wide.
Create a shortcode for use in content/en/ _index.html so
announcement is displayed on website landing page.
Create a partial for use in layouts/docs/baseof.html so
announcement is displaye on every page in '<url>/docs/home'
directory.
Add two values to config.toml: announcement (boolean) for toggling
display of announcement; announcement_message, which is the actual
message.
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
- Gardener is a fully managed service, including day-1 and day-2 operations
- Gardener supports OpenStack (and Packet Cloud), which is often the foundation for on-premise installations
See e.g. adopters like https://bnerd.com which are offering a Gardener-based fully managed Kubernetes service in their own OpenStack DCs. More information at https://github.com/gardener/gardener/blob/master/ADOPTERS.md.
* Translate `concepts/scheduling/_index.md` to Korean (#16072)
* Translate concepts/workloads/controllers/replicaset.md in Korean (#16070)
* Update outdated content in dev-1.15-ko.5 (#16162)
* Translate using-api/client-libraries into korean (#16182)
* ko: translate concepts/cluster-administration/proxies (#16030)
* Translate concepts/workloads/controllers/deployment.md in Korean (#16113)
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: Eden <longlg88@naver.com>
Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: Sunghoon Kang <me@devholic.io>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <gochist@gmail.com>
This patch turns the glossary entry for "workloads" into "workload" in
order to be consistent with other terms in the glossary. In addition,
the definition is modified to match what the overlay tip for the
"Workload" tag at the top of the glossary page says, which is
"Applications running on Kubernetes".
A workload is *not* a core object itself. Rather, it is a general
concept. Various other core objects describe different types of
workloads, and the glossary definition is appropriately modified to make
that clear.
Fixes Issue #14107
- Sample CRD will not work due to apiextensions.k8s.io/v1beta1 setting preserveUnknownFields to true by default. Set to `false`.
- Provide required `type: object` at `openAPIV3Schema` root for both versions to avoid `schema.openAPIV3Schema.type: Required value: must not be empty at the root` error.
* Add id translation for logging
* Fix templating issue
* Fix templating issue
* Fix templating issue
* Add files example for SIG ID logging docs
* Fix id-cluster-logging
* Add link references which were removed with #16011
Signed-off-by: David Schneider <schneider@puzzle.ch>
* Move link references into correct capture block
* Translate concepts/workloads/pods/pod/ in Japanese (#13671)
* [ja] Copy en/docs/concepts/workloads/pods/pod.md into ja/
* [ja] Translate docs/concepts/workloads/pods/pod/
* [ja] Modify translation of docs/concepts/workloads/pods/pod/
Reflect review - add trailing 'ー' to some technical terms
* [ja] Fix translation of 'Persistent Volumes' (#13848)
s/永続化ボリューム/永続ボリューム/g
* Translated cron-jobs.md in Japanese (#13937)
* Translate cron-jobs.md in Japanese (#13392)
* Update cron-jobs.md
* Create automated-tasks-with-cron-jobs.md in Japanese directory
* Fix translation (#13392)
* Translate cron-jobs.md in Japanese (#13392)
* Update cron-jobs.md
* Create automated-tasks-with-cron-jobs.md in Japanese directory
* Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory"
This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d.
* Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory"
This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d.
* Fix conflict (#13392)
* Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory""
This reverts commit c5fc9d93d6d789a13a0a28ec4b85f9e7aeb81e38.
* Revert "Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory"""
This reverts commit 095e760c6deb620da548d06a851c8f7ade71a15d.
* Fix that as it was pointed out (#13392)
* Delete double same sesntence (#13392)
* copy includes directory (#14020)
* Translate docs/home/_index.md into Japanese (#14068) (#14074)
* Translate concepts/overview/components.md into Japanese (#14067)
* Translate glossaries used in concepts/overview/components.md into Japanese (#14044)
* Translate concepts/overview/components.md into Japanese (#14044)
* Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese (#13668)
* Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese
* Apply suggestions from code review
Co-Authored-By: sotoiwa <sotoiwa@gmail.com>
* Better translation from code review
* Translate tasks/access-application-cluster/service-access-application-cluster/ in Japanese (#13701)
* Update fluentd image (#13661)
Signed-off-by: ialidzhikov <i.alidjikov@gmail.com>
* update zh kubelet-config-file doc (#13495)
* update zh kubelet-config-file doc
* change kubelet config types address
* add space between en words and zh words
* revert en version change
* correct container hyperlinks in init container (#12387)
* correct container hyperlinks in init container
* correct zh trans and update anchor inside page
* Incorrect details about startingDeadlineSeconds.. (#13530)
On this page, the default value of startingDeadlineSeconds is mentioned as 100 seconds which is not true. So removing this statement.
* Fix typos (#13376)
* add Nokia case study (#13676)
* Fix typo in API page (#13687)
Associated with #13686
* fix typo in pod-lifecycle (#13689)
Asscociated with #13688
* issue 13383
* modify the link part
* Revert "modify the link part"
This reverts commit 2ae91dca574b54a14d255320721df4313346de28.
* Revert "Revert "modify the link part""
This reverts commit e5b80b6258ce2210fc9a4b46e08fb8c000fe6330.
* Revert "Revert "Revert "modify the link part"""
This reverts commit 427916e7c6c4d6423222ff76b5fd8c12dc913ce1.
* Revert "Merge remote-tracking branch 'origin/master' into issue_13383"
This reverts commit 98099d805c7377826cb4d84bd0fece0f6362cb40, reversing
changes made to 969e7f3f5cf63622e24137a2e374b0ab9e272514.
* modify the link part
* Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#14025)
* Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#13952)
* Apply suggestions to /concepts/overview/working-with-objects/kubernetes-objects/ from code review
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Translate concepts/overview/working-with-objects/names.md into Japanese (#14066)
* Translate content/ja/docs/concepts/overview/working-with-objects/names.md into Japanese
* Translate docs/reference/glossary/name.md into Japanese
* Translate docs/reference/glossary/uid.md into Japanese
* Apply suggestions to concepts/overview/working-with-objects/names.md from review comments
* Translate concepts/overview/kubernetes-api.md into Japanese (#14343)
* Translate concepts/overview/kubernetes-api.md into Japanese
* Update translations for concepts/overview/kubernetes-api.md
* Translate overview/working-with-objects/labels.md in Japanese (#14183) (#14319)
* Translate overview/working-with-objects/labels.md in Japanese (#14183)
* Update translations for concepts/overview/working-with-objects/labels.md.
* Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) (#14494)
* Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426)
* Update translation for concepts/workloads/pods/pod-overview.md.
* Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) (#14535)
* Translate overview/working-with-objects/field-selectors.md in Japanese (#14350)
* Update translations for concepts/overview/working-with-objects/field-selectors.md.
* Update translation for concepts/overview/working-with-objects/field-selectors.md
* Translate overview/working-with-objects/common-labels/ in Japanese (#14397) (#14403)
* Translate overview/working-with-objects/common-labels/ in Japanese (#14397)
* Update translation for concepts/overview/working-with-objects/common-labels.md
* Translate concepts/storage/volume-snapshot-classes/ in Japanese (#14846) (#14849)
* ja-trans: tasks/run-application/run-stateless-application-deployment/ (#14955)
* ja-trans: tasks/run-application/run-stateless-application-deployment/
* modify "exploring" translation
* ja-trans: concepts/containers/container-environment-variables/ (#14116)
* ja-trans: concepts/containers/container-environment-variables/
* removed redundant expressions
* ja-trans: Translate tasks/debug-application-cluster/get-shell-running… (#14146)
* ja-trans: Translate tasks/debug-application-cluster/get-shell-running-container/ #13381
* Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
Fix typo
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* ja-trans: concepts/containers/container-lifecycle-hooks/ (#14169)
* ja-trans: tasks/debug-application-cluster/debug-init-containers/ (#14488)
* ja-trans: tasks/debug-application-cluster/debug-init-containers/
* modified traslation of should
* Translate concepts/workloads/controllers/replicaset/ in Japanese (#14634) (#14641)
* Translate concepts/workloads/controllers/replicaset.md in Japanese (#14634)
* Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634)
* Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634)
* Translate concepts/overview/working-with-objects/annotations/ in Japanese (#13382) (#14396)
* Translate overview/working-with-objects/annotations.md in Japanese (#13382)
* Delete a empty line in concepts/overview/working-with-objects/annotations.md (#13382)
* Update translation for concepts/overview/working-with-objects/anotations.md
* ja-trans: tasks/run-application/scale-stateful-set/ (#15289)
* [ja] Fix translation of 'Persistent Volumes' (#13848)
s/永続化ボリューム/永続ボリューム/g
* ja-trans: tasks/run-application/scale-stateful-set/
* Update content/ja/docs/tasks/run-application/scale-stateful-set.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Update content/ja/docs/tasks/run-application/scale-stateful-set.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* added postpositional particle
* ja-trans: tasks/debug-application-cluster/debug-stateful-set/ (#15282)
* [ja] Fix translation of 'Persistent Volumes' (#13848)
s/永続化ボリューム/永続ボリューム/g
* ja-trans: tasks/debug-application-cluster/debug-stateful-set/
* ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ (#14939)
* [ja] Fix translation of 'Persistent Volumes' (#13848)
s/永続化ボリューム/永続ボリューム/g
* ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/
* ja-trans: unify the ending of sentences
* follow the master branch update
* reflect a suggestion and modify translation of container
* ja-trans: tasks/run-application/delete-stateful-set/ (#15293)
* [ja] Fix translation of 'Persistent Volumes' (#13848)
s/永続化ボリューム/永続ボリューム/g
* ja-trans: tasks/run-application/delete-stateful-set/
* Update content/ja/docs/tasks/run-application/delete-stateful-set.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Update content/ja/docs/tasks/run-application/delete-stateful-set.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Update content/ja/docs/tasks/run-application/delete-stateful-set.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Update content/ja/docs/tasks/run-application/delete-stateful-set.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* modified traslation of backing
* ja-trans: tasks/configure-pod-container/attach-handler-lifecycle-event/ (#14328)
* Translate overview/working-with-objects/namespaces.md in Japanese (#14045) (#14161)
* Translate overview/working-with-objects/namespaces.md in Japanese (#14045)
* Update translations for concepts/overview/working-with-objects/namespaces.md
* ja-trans: fix Japanese Translation in concepts/overview/working-with-objects/namespaces.md (#14045)
* ja-trans: includes/default-storage-class-prereqs.md (#15376)
* ja-trans: includes/default-storage-class-prereqs.md
* Update content/ja/includes/default-storage-class-prereqs.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Translate tasks/run-application/run-replicated-stateful-application/ in Japanese (#15368)
* Translate tasks/run-application/run-replicated-stateful-application/ in Japanese
* add a base document in english
* Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com>
* Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
Co-Authored-By: Kohei Ota <kohei.ota@zozo.com>
* small fixs
「複製」という言葉を使わず「レプリケーション」と「クローン」に使い分けるように変更。
「ステートフルなアプリケーション」を「ステートフルアプリケーション」に変更。
* small fix
* Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) (#14576)
* Translate concepts/workloads/pods/init-containers.md in Japanese (#14543)
* Improve japanese translation in concepts/workloads/pods/init-containers.md (#14543)
* Add new line in ja/concepts/workloads/pods/init-containers.md (#14543)
* Add new line in ja/concepts/workloads/pods/init-containers.md (#14543)
* translate contribute/_index.md to japanese. (#15406)
* translate contribute/_index.md to japanese.
* trim spaces.
* Add missing translation.
* Translate concepts/workloads/controllers/daemonset/ in Japanese #14761 (#14767)
* Translate concepts/workloads/controllers/daemonset/ in Japanese (#14761)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/daemonset.md (#14767)
* Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) (#14720)
* Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/garbage-collection.md (#14718)
* Translate concepts/workloads/pods/podpreset/ in Japanese (#14544) (#14581)
* Translate concepts/workloads/pods/podpreset.md in Japanese (#14544)
* Update translation for concepts/workloads/pods/podpreset.md.
* ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544)
* ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544)
* ja-trans: Delete translated sentence in concepts/workloads/pods/podpreset (#14544)
* ja-trans: Delete duplicated sentence in concepts/workloads/pods/podpreset (#14544)
* Translate concepts/containers/runtime-class/ in Japanese (#14670) (#14673)
* Translate concepts/containers/runtime-class.md in Japanese (#14670)
* ja-trans: Improve Japanese translation in concepts/containers/runtime-class.md (#14670)
* Translate concepts/services-networking/dns-pod-service/ in Japanese #14777 (#14805)
* Translate concepts/services-networking/dns-pod-service/ in Japanese (#14777)
* ja-trans: Improve Japanese translation in concepts/services-networking/dns-pod-service.md (#14777)
* Translate concepts/workloads/controllers/statefulset/ in Japanese #14679 (#14696)
* Translate concepts/workloads/controllers/statefulset.md in Japanese (#14679)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/statefulset.md (#14679)
* ja-trans: Improve some Japanese translation in concepts/workloads/controllers/statefulset.md (#14679)
* ja-trans: Improve some titles in concepts/workloads/controllers/statefulset.md (#14679)
* ja-trans: Improve some Japanese translations in concepts/workloads/controllers/statefulset.md (#14679)
* Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese #14734 (#14735)
* Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese (#14734)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/ttlafterfinished.md (#14734)
* ja-trans: Delete some Japanese words in concepts/workloads/controllers/ttlafterfinished.md (#14734)
* ja-trans: Fix typo in concepts/workloads/controllers/ttlafterfinished.md (#14734)
* Translate concepts/storage/dynamic-provisioning/ in Japanese #14847 (#14916)
* Translate concepts/storage/dynamic-provisioning/ in Japanese (#14847)
* ja-trans: Improve Japanese translation in concepts/storage/dynamic-provisioning.md (#14847)
* ja-trans: Improve some Japanese translation in concepts/storage/dynamic-provisioning.md (#14847)
* ja-trans: Improve some Japanese translations in concepts/storage/dynamic-provisioning.md (#14847)
Add new section for content guidelines
Add table of examples of what is and is not allowed
Add examples of links to Linux Academy courses based on discussion
during the Aug 20 SIG Docs meeting.
Remove example table and reformat based on feedback
Move content guide to its own page
Update existing pages to mention new Content Guide page
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
In nginx ingress controller Version 0.22.0 and beyond, any substrings within the request URI that need to be passed to the rewritten path must explicitly be defined in a capture group. Please refer doc here :
* `https://kubernetes.github.io/ingress-nginx/examples/rewrite/#rewrite-target`
* `https://stackoverflow.com/a/55193468/5527839 `
Currently, what was mentioned in the docs, didnt work for me. I was using minikube version `1.2.0` which uses ingress above v0.21.0. After reading the docs provided in above two links, was able to figure out where it was lacking. Have mentioned the changes in the proposed file change.
* translated term: toleration
* update translation: toleration
* Update translation: toleration
translated terme "taint" as "marquage" in French and "schedule" as "ordonnancer" in French
* Update translation: toleration
typo fixup
* Translate CCM page in French
* Update content/fr/docs/tasks/administer-cluster/running-cloud-controller.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
It's very difficult to figure out e.g. the correct quotes to use from
regular text that is subject to being converted for typographers quotes.
Use code literals instead to ensure that nothing is modified, and to
distinguish literals from accompanying text.
Signed-off-by: Zane Bitter <zbitter@redhat.com>
* Add Link /docs/reference/ in Korean (#15610)
* Translate tasks/debug-application-cluster/resource-usage-monitoring in Korean (#15593)
* Translate tasks/inject-data-application/define-environment-variable-container in Korean (#15606)
* ko: Update outdated files in dev-1.15-ko.3 (#15605)
* Translate home/supported-doc-version in Korean (#15621)
* ko: Update some files in reference/glossary (#15631)
* Translate reference/glossary/cloud-provider.md in Korean (#15685)
* Translate docs/reference/using-api/api-overview in Korean (#15644)
* Translate tasks/debug-application-cluster/resource-metrics-pipeline in Korean (#15665)
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Seokho <shsongist@gmail.com>
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Yoon <learder@gmail.com>
Co-authored-by: JiMyung Lee <lee.ji.myung@gmail.com>
Co-authored-by: lapee79 <lapee79@gmail.com>
Co-authored-by: Sunghoon Kang <hoon@linecorp.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr>
It switched from a naming scheme of service1/service2 to s1/s2. That can be confusing for new people, and I propose we stick to only one naming scheme.
Add hyperlink to 'communicate' in Participating in SIG Docs section.
Hyperlink points to Participating in SIG Docs discussions section further down the page.
Add info to Submit a pull request bullet 5 about putting fixes #<issue_number>
or closes #<issue_number> to the PR description so GitHub will automatically close the issue
* Improvement for kubectl patch command
This command does not work in Powershell. A specific note would help the developers to take care of the same.
* Fixed review comments
Added different tabs for bash and PowerShell.
* Removing note for PowerShell
Hugo is not able to add note along with shortcode. Hence removing note.
* Update device plugin docs for Kubernetes 1.14
& related pages
This change is mainly about feature-state shortcodes & similar.
(if there's a way to get the short version string, eg "1.14" rather
than "v1.14", then that could go in place of the hard coded value
in this commit).
* Fix code block formatting
eg code blocks incorrectly marked as:
```shell
* Use glossary shortcodes where appropriate
* Hyperlink to Prometheus
* Tidy Markdown formatting
* Change example vendor domain name
Use a name inside ".example" to highlight that this is a DNS
domain name.
* Reword device plugins documentation
* Tweak headings for device plugins
* Add "what's next" to device plugins docs
* Tweak wording for device plugins docs
* Add KubeVirt device plugins
- tested on macOS with BSD's grep and GNU's. same flags, same output.
- there are some 55 CPU flags on mac, so highlighting VMX makes it
easier to grasp
- using `egrep` on linux and `grep` on mac, not necessary
- precision: the VT-x feature is NOT an OS feature...
* Add OPA Gatekeeper blog post
* address comments
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* address more comments
* Update based on beta release
* Update publish date; reword intro
* Document the enableServiceLinks flag
There are many cases of service discovery environment variables clashing with env vars expected by programs, causing hard to debug problems. The enableServiceLinks flag added in 1.13 should be mentioned here and not only on the API reference.
* Update connect-applications-service.md
* Update content/en/docs/concepts/services-networking/connect-applications-service.md
Co-Authored-By: Qiming <tengqim@cn.ibm.com>
* rephrased the action to use active voice style
* porting some information from kubeadm-init.md to kubelet-integration.md doc
from reference/setup-tools/kubeadm/kubeadm-init.md to setup/production-environment/tools/kubeadm/kubelet-integration.md
includes edits I just proposed in #15421 and #80136
* improve wording re. systemd in kubelet-integration.md
* removing quotes and adding the in kubelet-integration.md
* Update content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
Co-Authored-By: Lubomir I. Ivanov <neolit123@gmail.com>
because with busybox/0.log it fails as shown below (unless you mkdir busybox,
with the correct permission, which is an extra step we can avoid for a tutorial like this)
FATA[0000] Starting the container "3c71f8c3abfcac0f8357fa25be896062f05f88e1d9acbd7a033afeee9a54f3c4" failed: rpc error: code = Unknown desc = failed to create containerd task: failed to create container loggers: failed to create and open log file: open busybox/0.log: no such file or directory
CSR API isn't guaranteed to use the cluster CA. The CA used to sign
certs using the CSR API depends on the specific cluster stup. Admins can
use a separate CA if they choose to.
Users shouldn't rely on verifying those certs using the CA bundle
mounted with service account secrets.
The doc page is reworded to remove most mentions of cluster CA and
instead focus on API usage specifics.
The content describing authorization modes used the term "authorization
modules" erroneously. This patch uses the term "mode" as is appropriate
but keeps the section link header the old "authorization-modules" in
order not to break older links.
- Mark as relevant to networking.
- Unmark as a core object. kube-proxy is not an API object.
- Fix hyperlink to reference docs.
- Include hyperlink in definition. This is used in /docs/concepts/overview/components/
- Revise wording.
* remove doc from kubeadm-init.md which is duplicated in kubelet-integration.md
This section in reference/setup-tools/kubeadm/kubeadm-init.md seems to significantly overlap with setup/production-environment/tools/kubeadm/kubelet-integration.md - looks like someone copy/pasted it at some point? The information in kubelet-integration.md looks more up to date than this (e.g. there actually is no `--allow-privileged=true` or `--network-plugin=cni` here?). Therefore lets delete the sections content, and have a short line linking to the other one.
If this is accepted, then #15421 is moot (because #15423 moves it to the new place).
* shorten link re. removed doc from kubeadm-init.md
as requested in https://github.com/kubernetes/website/pull/15424/ review
* drop https://kubernetes.io from link in kubeadm-init.md
* Revert "shorten link re. removed doc from kubeadm-init.md"
This reverts commit f128ce7dc2022e424a28ffc3faacb7b9a8af0ad8.
* fix bad wording
* update kubeadm-init.md based on kbhawkey review feedback
* remove duplicate sentence in kubeadm-init.md
* Adding cgroup to glossary
Adding cgroup to glossary
* Removed value from aka field
* Updating cgroups.md with cgroups changed to cgroup
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Modified cgroups to singular
* Title update and remove etc
Updated the title as mentioned in v2 docs and removed etc
* Update cgroups.md
Adding different short description
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Updated cgroups.md short description
* Changed file name and glossary title
* Changed the title to make it consistent
* Reference/tools/v0.1 (#15401)
* Translate reference/glossary/contributor.md in Korean (#15433)
* Translate reference/glossary/cla in Korean (#15436)
* Update what-is-kubernetes.md (#15446)
* Translate glossary components tagged with `Fundamental` into korean (#15426)
* Translate content/ko/docs/concepts/overview/working-with-objects/fiel… (#15393)
* Translate tasks/administer-cluster/cluster-management in Korean (#15472)
Co-Authored-By: lapee79 <lapee79@gmail.com>
Co-Authored-By: alice_k106 <alice_k106@naver.com>
Co-Authored-By: Sunghoon Kang <me@devholic.io>
Co-Authored-By: 박주은 <elpion19@gmail.com>
Co-Authored-By: JiMyung Lee <lee.ji.myung@gmail.com>
Co-Authored-By: Sean Park <seanpark.hh@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
* Added Tencent Cloud Production Environment Solution
* Add an article on how to run kubernetes on Tencent Kubernetes Engine : content/en/docs/setup/production-environment/turnkey/tke.md
* Document modifications have been made as recommended by reviewer sftim. Please select this document when merging.
* Document optimization
* Modify the contents of the document : content/en/docs/setup/production-environment/turnkey/tke.md
* Add A What's Next section
* Add content: TKE is a Certified Kubernetes product.
* Add reviewers and other information.
* Delete a space
* Change information about reviewers
* Remove reviewers.
* pod-network to be done only on master node
added a note saying that Install a pod-network add on need to be done only on the master node
* updated where to run pod-network doc
All admission control plugins support two modes for specifying their
configuration: linking to an external file using the `path` key in the
shared admission configuration file, or directly embedding the
configuration using the `configuration` key in the shared admission
configuration file.
This commit makes the ImagePolicyWebhook documentation mention the
embedded configuration option.
* Adding China unicom Case Study
* Adding comma
* Update index.html
Now the verb was conjugated correctly.
* Update index.html
Added comma to separate items correctly.
* Update index.html
Removing the br element.
* Update index.html
Correction in verbal conjugation.
* New getting started blog post
I'd like to submit a blog post for the kubernetes.io blog targeted to people just getting started with Kubernetes. I myself am still new to it but want to start writing more to share what I am learning and help others along the way. My point of view is a little different than most people who post on the kubernetes.io blog since I am an independent consultant and I also work mostly with Microsoft products - so some of my resources are from Microsoft which seems rare for some reason in most Kubernetes blog posts I find on the web.
* Added the images and changed md for path
I added the image files and changed the paths in the markdown to /static/images/blog/...
* fix path
* Added date to header
Added a date to get it on netlify preview
* made changes
* Update and rename get-started-with-kubernetes-using-python.md to 2019-07-23-get-started-with-kubernetes-using-python.md
When upgrading controlplane nodes, upgrading the kubelets should be done
as the last step after "kubeadm upgrade" was run on all of the control
plane nodes already.
Also apply consistency related cleanup to sections and section names.
I changed a question that had no question mark into a statement. I also changed the heading from the first person to the second person, because the topic it treats the reader as the second person everywhere else.
Using tabs in this partials seems to cause Hugo to parse the partial
as a code block instead of rendering the HTML code.
Solves #14792 rendering issues.
* Switch to "failure zone" term
Previous wording, "availability zone", is specific to certain cloud
service providers (eg AWS).
* Refer to glossary terms where appropriate
* Reword signposting to examples
* Assign stable name to anchor
* Link to standard node labels
* Fix incorrect feature state claims
* NodeRestriction admission plugin needs Kubernetes v1.11
(or later)
* Move further reading to whatsnext section
* Fix link to cluster setup
* Drop advice about older kubectl
Kubernetes v1.14+ definitely does offer a compatible kubectl
* Drop outdated comment about downloading examples
* Call an availability zone an availability zone
* Improve init containers page
- Overall rewording
- Link to “Debug init containers” in whatsnext
- Explain terms / use glossary references
- Use glossary shortcodes where appropriate
- Expand terms like QoS and cgroup that aren't in the glossary
- Only document & recommend stable syntax
- Tweak initContainer examples to use project style
- Drop vestigialreference to StatefulSet
Also: write “container” in lower case
Most of the places where this page talks about containers, it's as a
concept rather than an object in the Kubernetes API. Adjust case
accordingly.
* Reword what's next section
* Add docs/concepts/cluster-administration/logging.md
* Add depending examples
* Translate first 2 chapters
* Coorect the path to debug/counter-pod.yaml
Only the english versions can be directly referenced.
* translate last chapter and adjust to doc style guide
* Fix french ortographic and gramatical errors
* Fix french grammar and orthograph
* Translate concepts/workloads/controllers/replicationcontroller in Korean (#15044)
* ko: Update outdated 1.14-ko.4 branch (#15099)
* Translate tasks/access-application-cluster/configure-access-multiple-clusters in Korean (#15121)
* Translate standardized glossary items in Tag Network into Korean (#15278)
* ko: Keep up with upstream - renamed files (#15030)
Co-Authored-By: Seokho <shsongist@gmail.com>
Co-Authored-By: lapee79 <lapee79@gmail.com>
Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Ubuntu 16.04.5 LTS
apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm=1.14.x-00 && apt-mark hold kubeadm gives the below error
The following packages have unmet dependencies:
kubelet : Depends: kubernetes-cni (= 0.6.0) but 0.7.5-00 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
Unholding the kubelet with kubeadm fixes the problem.
* Add scheduler concept page
* Rename scheduling overview
* Fix non-ASCII colon symbols
* Reword scheduler concept page
* Move scheduler performance tuning into scheduling
* Signpost from overview to kube-scheduler, etc
* Add whatsnext section to scheduler concept
* Restructure scheduling concept
Now there's a concept page for scheduling, some of the details
in the performance tuning page can have a better home.
* Omit link to (unwritten) scheduling extensions page
* Drop deprecated / superseded filtering rules
* Updated Korean setup and cassandra pages to remove broken pick-right-solution page
* took out the errant Getting Started line with the pick-right-solution link. It's not in the English version at all.
This change is required since the 3.8 manifest moves to using
apps/v1 instead of extensions/v1beta1 for types like DaemonSet
and Deployment.
See PR 70672 of k/k.
* Update api reference contrib doc
See issue #14111
* updates to api ref contrib guide
* further updates to api ref contrib
* more updates api ref contrib
lose apt-mark unhold kubectl when apt-get install kubectl. If not unhold kubectl, it would return the error follows:
``` shell
root@ecs-k8s-master:~# apt-mark unhold kubelet && apt-get update && apt-get install -y kubelet=1.15.0-00 kubectl=1.15.0-00 && apt-mark hold kubelet
kubelet was already not hold.
Hit:1 https://download.docker.com/linux/ubuntu xenial InRelease
Hit:2 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial InRelease
Hit:3 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial-updates InRelease
Get:4 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial-backports InRelease [107 kB]
Hit:4 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial-backports InRelease
Hit:5 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial-security InRelease
Hit:6 https://packages.cloud.google.com/apt kubernetes-xenial InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic linux-image-4.4.0-145-generic linux-modules-4.4.0-145-generic
Use 'apt autoremove' to remove them.
The following held packages will be changed:
kubectl
The following packages will be upgraded:
kubectl kubelet
2 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
E: Held packages were changed and -y was used without --allow-change-held-packages.
```
1. Replace net.ipv4.route.min_pmtu with net.core.somaxconn in the
example of using unsafe sysctls in containers, since the former is not
accessible within container namespace at all.
2. Not all net.* sysctls are namespaced. Explain the correct way to
identify the namespaced networking sysctls.
* fix path of game.properties file
It has been dowloaded to configure-pod-container/configmap/game.properties
* fix typo: kustomization instead of kusotmization
Due to a couple missing newlines and missing closing fixed-width quote
delimiter, the bulleted list of extensions to core constructs was being
incorrectly displayed.
* Update and organize the content on Deployments
fix formatting issues
Format a note
Formats the content
Format content
Fix formatting issues
Format content
Format content
Update and organize the content on Deployments
* Update the content as per the comments
* Update as per the comments
* Update as per the comments
- Ignore 'xtrabackup_slave_info' if it is an empty file.
- Remove the tailing semicolon in 'xtrabackup_slave_info'.
- Stop script when 'CHANGE MASTER' is failed, then rename 'change_master_to.sql.in' only when changing master is successful.
There's some SASS that adds a logo to the CNCF section of the page at
https://kubernetes.io/ (and its localizations).
Narrow this styling to apply only to the home page.
Init Containers were specified using custom annotations in k8s 1.5. In
k8s 1.6, these annotations were replaced with the
`Pod.Spec.initContainers` collection and the old annotations were
deprecated in 1.6 and no longer supported in 1.8. There's no reason to
clutter the docs with the old annotation syntax.
* translated glossary/application-architect from en to fr
* translated title section of glossary/application-architect.md from en to fr
* changed 'micro-prestations' to 'micro-services
* This URL is a better link directly to the feature
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Convert links to relative links, clean up a conversion comment
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Initial blog post draft for kubeadm v1.15
* More edits, and add pictures
* Incorporate changes from review and add hugo metadata
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Update logo and some final edits
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Some minor fixes, fix the logo and author attribution
* Fix list formatting
* Fix an other list formatting issue
* Update 2019-06-24-kubeadm-ha-v115.md
Removed ambiguous word 'temporarily', as namespace set using that method, is not temporary. It is permanent for a current resource and there is no concept of a temporary namespace in K8s.
Also, for consisteny '--namespace' flag added after the actual command.
* Updates HAProxy Ingress Controller information to point to new controller supported by haproxytech
* Update content/en/docs/concepts/services-networking/ingress-controllers.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Added listing for AWS VPC CNI
Added listing for AWS VPC CNI under "How to implement the Kubernetes networking model".
* Added AWS VPC CNI
* Added AWS VPC CNI to Installing a pod network add-on
* Updated tabs to alphabetical order
* Fix formatting in 2019-06-20-Future-of-CRDs-Structural-Schemas.md
Hugo seems to be incompatible with the Github markdown formatting.
* Fix doc link
* Defaulting is alpha
* Adding what's new section to namespace concepts
To learn more about namespaces and give better navigation this section is added.
* Update namespaces.md
There's been a number of questions around the difference between the external.metrics.k8s.io and custom.metrics.k8s.io in #sig-autoscaling referring back to the HPA docs recently. Added links out to the design proposals for each and the relevant sections of the existing walkthrough docs.
We don't need to be the dispatch for all vulns, now that other projects are starting to have their own processes. But we don't want to discourage reports about stuff that isn't directly in k/k either.
Saying that we usually disclose vuln reports in 7 days is just not true. But, I think it's still good to aim for 7 days when we aren't blocked on and coordinating release of patches.
* Updated IP Address for /etc/hosts
Tested on Minikube for macOS.
When using Minikube, the IP address listed in `kubectl get ingress` is the internal Minikube IP address and is not available on the web browser.
Added advice to the user that when using Minikube, add the Minikube IP address to the Hosts file instead of the IP address displayed in `kubectl get ingress`.
* Update ingress-minikube.md
* Adding alternative command to create namespace
As this is first place user look to find details to create a namespace, added an alternative command to create a namespace. Also, this is mostly used way to create namepsace instead of YAML.
* Correcting Formatting
Correcting formatting for changes
* Update namespaces.md
* Updates the What is Kubernetes page
* Adds content to the what is kubernetes used for section.
* Updates the ordered list.
* Formats the content.
* Update the content as per the comments
* Fix a broken link
* add pod preset page for language/id
* fix formatting
* fix typos and wording
* fix formatting and add few missed lines
* fix note formatting
* add Garbage Collection page in Bahasa Indonesia and minor fix on Pod Preset page
* remove replication.yaml
* add controllers/replicaset.yaml to example
* fix formatting error
* change dependent to dependen and fix note translation
* delete trailing space in heading
* zh-trans: add 2019-06-11-contributor-summit-shanghai.md
* s/贡献者峰会活动/贡献者峰会/
* s/不过/不论/
* Adopt PR suggestion
* s/你/您/
* s/当前贡献者节/现有贡献者活动/
* s/在亚洲和大洋洲的很多贡献者/很多亚洲和大洋洲的贡献者/
* s/新开发者/新贡献者/
* Adopt PR suggestion.
* s/上海会展中心/上海世博中心/
* s/工作者/贡献者/
* Refresh original English text as the related PR got merged
* Rename the filename to be consistent with English blog post PR
This script will query all the changes that happen to a reference document (in English) since the last time a given translation was merged (For instance in French).
This could help all the translation team to keep up with the changes that happened inside the reference document.
* Highlight feature state for Ingress concept
* Fix command output marked as shell script
* Write "load balancer" as two words
* Clarify prerequisites for Ingress
* Tidy & reword
* Add link to Ingress Controllers topic
(further reading)
* Use a glossary tooltip for Secret
(readers may not have encountered that concept yet)
* Update term definitions in Ingress concept
- Adopt wording from glossary
(NB: glossary_definition shortcode didn't seem suitable)
- Replace terms with glossary_tooltip where appropriate
* [WIP] added accessibility guidelines to the style guide
Adopted the accessibility level A and AA guidelines to Markdown elements:
https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0¤tsidebar=%23col_overview&levels=aaa
We still need to define attributes for the front matter. See, https://github.com/kubernetes/website/issues/14286
I am yet to draft the guidelines for images and alt text.
* fixed the note
Update style-guide.md
Incorporated the changes suggested
Incorporated the changes suggested.
fixed the formatting issues in the table
fixed the spaces in the links section
fixed a space issue
fixed format issues in the link
added a11y guidelines to code section
removed a spacing issue
front matter guidelines best fit the using template section
Update content/en/docs/contribute/style/style-guide.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Update content/en/docs/contribute/style/style-guide.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Update content/en/docs/contribute/style/style-guide.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
incorporated the changes
incorporated the changes
Update content/en/docs/contribute/style/style-guide.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
title section for front matter guideline
updated the html characters
Update content/en/docs/contribute/style/style-guide.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Update style-guide.md
* Check for examples changes in all branch commits
Review all the commits in the branch looking for changes inside
content/*/examples and if any are found, trigger testing.
This assumes that the main line branch is named "master"
* Tidy examples testing wrapper
- print diagnostics to standard error
- check for a "Yes" value rather than for absence of "No"
* Add Ref to shared process namespaces
The article talking about ways container can talk to each other should include shared process namespace as a method
* Drop note on kube version in reference
* Put minikube install steps in per-OS tabs
* Work around nested <li> formatting issue
Using Markdown unordered lists inside tabs doesn't seem to work. These
changes are my work-around for that.
* Reword "laptop" to personal computer
Some computers aren't laptops
* Drop trailing whitespace
* Drop warning about removing other Mac hypervisors
* Move examples ahead of commands that use them
In support of https://github.com/kubernetes/website/issues/12740
The aim is to adopt a consistent style around providing downloadable
examples for use with kubectl, etc.
* Tweak wording for stateful app pod example
* Adopt formatting conventions for code blocks
* Move ReplicationController sample YAML to examples
In aid of https://github.com/kubernetes/website/issues/12740
* Move PodDisruptionBudget sample YAML to examples
In aid of https://github.com/kubernetes/website/issues/12740
* Update test schema for new examples
* Use Unicode ellipsis in example
Aim here is to make the elision more obvious
* Add comment about where to run probe
Add comment about where to run probe
Signed-off-by: Xiang Dai <764524258@qq.com>
* Update language
Signed-off-by: Xiang Dai <764524258@qq.com>
* Update language
Signed-off-by: Xiang Dai <764524258@qq.com>
* Update language
Signed-off-by: Xiang Dai <764524258@qq.com>
* fix grammar nits
Signed-off-by: Xiang Dai <764524258@qq.com>
* Add recommendation to use kms provider
Add a warning to encrypting secrets documentation that if using a provider with secrets encryption, kms provider is preferred as it materially changes the threat model.
* Update encrypt-data.md
* Update encrypt-data.md
Updated to include kms provider is Beta sice 1.12
* Update encrypt-data.md
* feat: add job application has some error and restartPolicy is not Nerver pod will be delete note
* feat: optimize delete pods related suggestion
* Update jobs-run-to-completion.md
* clarify Conditions section in arch/nodes.md
The field name is `conditions` (plural), so have the section name match
the field name. In addition, updates the JSON output of an individual
Condition to match all the fields returned in k8s 1.14+.
* add information about Allocatable to nodes.md
Since k8s 1.6, a Node object returns information about both the node's
capacity as well as the allocatable resources on the node. The latter is
a representation of the resources that are available for normal pods to
consume.
This patch adds information about capacity vs. allocatable to the
documentation about nodes and provides a link to where the reader can
find more information about reserving compute resources.
* Correction: sysctl entries aren't annotations
First, thank you for your work on this documentation. It means so much to so many users. I found that the sysctl documentation linked here explains that sysctl pod security policy entries are in the spec field, not done via annotation. This corrects it, using as much of the original language as possible from the linked sysctl documentation.
* Update pod-security-policy.md
* Adding example to show labels in POD yaml
This page talk about labels and its usage. Also it talk about syntax for specifying labels. But it does not show how we can have labels in resource manifest. So with this PR i am adding example which shows that how we can have labels in pod manifest.
* Changes to resolve review comments
Changes to resolve review comments
* Adding annotation example
Adding example to show how annotation looks like in manifest. This will help users to understand where exactly we can use the annotations whose details are already given on this page. Annotation `imageregistry: https://hub.docker.com/` used intentionally to make it more relevant as earlier section talk about registry address annotation.
* Resolving review comments
Resolving review comments
* Add zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
Add zh/examples/pods/lifecycle-events.yaml
Translate zh/includes/task-tutorial-prereqs.md to chinese
* Apply suggestions from code review
Thanks for tengqm's review
Co-Authored-By: Qiming <tengqim@cn.ibm.com>
* Apply suggestions from code review
Thanks for tengqm's help again
Co-Authored-By: Qiming <tengqim@cn.ibm.com>
* Modify the order of text in markdown format
* Unified translation into 处理函数
This patch promotes re-use of the existing kube-proxy glossary
definition by referencing it from overview/components.md. Similarly, we
move the definition of Container Runtime into a new glossary definition
so that other pages may refer to it.
* Update images.md
* Update content/en/docs/concepts/containers/images.md
That works fine and thank you.
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
**your.private.registry.example.com** is a better choice of domain name for a non-existing sample domain name than calling it **yourprivateregistry.com**
refer #14283
* Reword glossary entry for Service
New wording should be more suitable for inclusion via a
glossary_definition shortcode.
* Improve What's Next section for Service concept
* Rename Services concept to singular
This matches other concept documentation, eg Deployment.
* Use documentation IP address range
1.2.3.4 is outside the blocks reserved for documentation.
* Reword Service concept description
Services direct traffic to Pods, not containers
* Write IPVS in uppercase
Using `rm -Rf ~/.minikube` is not necessary in modern (v1.x) versions of minikube, and is highly discouraged as may can leave dangling VM's running, which minikube will fail to recover from.
Example issue: https://github.com/kubernetes/minikube/issues/4377
* Improve Pivotal row in Production Setup table.
- Provider column should contain company name
- Change check marks to product links to match other rows
Co-authored-by: Danny Berger <dberger@pivotal.io>
* Spell out PKS abbreviation.
Co-authored-by: Danny Berger <dberger@pivotal.io>
* Tweak glossary definition for Node
The services (eg kubelet) that run on a Node are not the kind of
Service that the Kubernetes API knows about. Reword accordingly.
Also, highlight that Docker is one container runtime and that
there are others.
* Adopt suggestions from https://github.com/kubernetes/website/pull/14523
Co-Authored-By: Rael Garcia <me@rael.io>
without specifying registry details for `image` value, You will get following error if you are using a private registry even when your private images are hosted in docker.hub and you have valid credentials configured for the same.
Failed to pull image "xxx/xxx-app:0.0.1": rpc error: code = Unknown desc = Error response from daemon: pull access denied for xxx/xxx-app, repository does not exist or may require 'docker login'
* document version changes of critical pod
* document system priority class name version requirement
* Update guaranteed-scheduling-critical-addon-pods.md
Minor updates:
- Add a full stop.
- Removed the 'Start the tutorial›' section. The sections are already linked from 1 to 6 and this section doe not add any value after point 6.
* Link to 'Add image pull secret to service account'
This page does not mention the fact that image pull secrets can be specified through a service account. So adding link to the section which gives details about 'adding image pull secret to service account'.
* Correcting link url
Correcting link url
* Translate declarative config for Bahasa Indonesia
* Fix typos and untranslated sentences from previous commit for declarative-config for Bahasa Indonesia
* Add _index.md to object-management-kubectl translations for Bahasa Indonesia
* Translate imperative-config.md for Bahasa Indonesia
* Update missing translations in imperative-config.md for Bahasa Indonesia
* Corrects procedure to get tab completion on Mac
Tab completion only requires the installation of bash-completion and sourcing the bash_completion script.
Installing bash-completion@2 doesn't work and source <(kubectl completion bash) is no longer necessary in the .bash_profile.
* Removed reference to other methods that don't work
* Update install-kubectl.md
The current content was not following the style guide and lacked information on what the user was doing under the quick start section. Added more information and tested the section out. Further reorganized the content.
Correct typos
Updated the content.
Updated the content
Fixed syntax error.
Update the unordered list formatting
Fix formatting issues
Formatting update
Format the content
Format the content
Format content
Format ordered content
Format unordered list
Clean up and reorganize minikube.md
Updated the content
Updated the content as per the comments received.
Fixed an error
Fixes the note shortcode
Fixes error in shortcode
Clean up and reorganize minikube.md
* Use note shortcode in kops glossary entry
This brings the entry closer to Kubernetes' style guide for
documentation.
* Reword kops glossary entry
- Write “Terraform” with a capital T (it's a proper noun)
- Adjust grammar
This commit is the fourth Korean l10n work for release-1.14.
Change List
* Translate concepts/overview/object-management-kubectl/declarative-config in Korean (#14285)
* translate cron-jobs.md to korean + add _index.md (#14024)
* ko: update outdated files in dev-1.14-ko.4 #14207 (#14347)
* Translate standardized glossary Tag Workload in Korean (#14208)
* translate to content/ko/docs/concepts/cluster-administration/controll… (#14234)
* ko: update concepts, contribute, tasks in dev-1.14-ko.4 #14207 (#14502)
* ko: update cheatsheet in dev-1.14-ko.4 (#14515)
Co-Authored-By: Woojin Na(Eddie) <kimchigood1130@gmail.com>
Co-Authored-By: Kim Young Dae <38598117+zer0big@users.noreply.github.com>
Co-Authored-by: Claudia J. Kang <claudiajkang@gmail.com>
Co-authored-by: Yoon <learder@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Seokho <shsongist@gmail.com>
* Add `content/fr/docs/tutorials/_index.md
* The navigation menu was broken without it.
* Translation from `content/en/docs/tutorials/_index.md`
* Update content/fr/docs/tutorials/_index.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
The link https://github.com/kubernetes/minikube#other-ways-to-install doesn't exist anymore.
So either we remove the link to it or we fix the minikube README and add a new section for alternative ways to install minikube.
What do you think?
* Add /content/fr/docs/reference/_index.md
* translate title and title Link
* take out the approvers section
* replace design by conception
* Update content/fr/docs/reference/_index.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Translate declarative config for Bahasa Indonesia
* Fix typos and untranslated sentences from previous commit for declarative-config for Bahasa Indonesia
* Add _index.md to object-management-kubectl translations for Bahasa Indonesia
* Translate imperative-command.md for Bahasa Indonesia
* Update translations for Imperative Command for Bahasa Indonesia
* Translate Disruptions docs to Indonesian
* Several changes regarding reviews:
- Use underscore for italic
- Italicize "cloud"
- Consistency of Disrupsi and Gangguan -> Use Disrupsi instead
- Change "usir" to italicized "evict"
- Change "pengontrol" to "pengendali"
- Change "kuras" to "drain"
- Emphasize first mention of disrupsi with bold instead
- Some typo and standard words fixes
- Fixes a potentially fatal translation of "hosting provider"
- From "penyedia layanan cloud" to "penyedia layanan Kubernetes
* Link upgrade to skewed version page
It provides the order of upgrade and shows which versions are supported.
Solves (at least partially ) #14420
* Update cluster-management.md
* Update cluster-management.md
* document pod downwardAPI fieldRef & resourceRef values of en version
* document pod downwardAPI fieldRef & resourceRef values of zh version
* typo correction
* Correcting minikube quickstart steps
In minikube quickstart section , it was difficult to differentiate between command and its output. Also, There was no details given for each steps and its expected output. This PR fixes these issues.
* Correcting number formatting
Correcting number formatting
* Correcting numbering
Correcting numbering
* Update content/en/docs/setup/minikube.md
Co-Authored-By: Franklin Yu <franklinyu@hotmail.com>
* Update content/en/docs/setup/minikube.md
Co-Authored-By: Franklin Yu <franklinyu@hotmail.com>
* Update content/en/docs/setup/minikube.md
Co-Authored-By: Franklin Yu <franklinyu@hotmail.com>
* Corrected formatting
Corrected formatting
* Correcting number sequence
Correcting number sequence
* Updated Linux Academy courses
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fix link syntax
* Update overview.md
Both local and pod port number are same i.e. 6379 which causes confusion to first time reader. This can be easily avoided by using two different port number.
* Correcting order of display for daemon set tasks
Correcting order of display for daemon set tasks
* Correcting display order of daemon set task
Correcting display order of daemon set task
here apt installs both kubelet and kubectl but just holds kubelet. I think kubectl should alse be held by apt-mark.
```
# replace x in 1.14.x-00 with the latest patch version
apt-mark unhold kubelet && \
apt-get update && apt-get install -y kubelet=1.14.x-00 kubectl=1.14.x-00 && \
apt-mark hold kubelet
```
Add meeting guidelines, graphic
Update embedded image
Use raw HTML for image link
Edit path
Indent list items
minor edits
Add line breaks for indentation
Add bolding
Add section for meetings
Feedback from jimangel
* Use glossary references where appropriate
* Link from Pod overview to detailed Pod concept
* Assume that privileged containers are stable
* Improve wording
* Write Pod in upper case
As Pod is an API object, write it in upper case.
* Add new translation in Bahasa Indonesia
* Add revision to translation
* Edit type translation cloud-providers in Bahasa Indonesia
* Edit type translation cloud-providers
* Add translation Cluster Administration Overview in Bahasa Indonesia
* Delete cluster administration overview
* Add translation controller metrics in Bahasa Indonesia
* FIx type
* Fix type controller metrics
* Fix type and formatting
This patch swaps all uses with extensions/v1beta1 with the new
networking.k8s.io/v1beta1 apiVersion for the Ingress resource.
Signed-off-by: Christopher M. Luciano <cmluciano@us.ibm.com>
* Define SLO acronym
Save people from having to search for the translation of SLO to Service-Level Objectives.
* replace SLO with direct PodDisruptionBudget reference
The orders of kind and metadata were inconsistent, and that made the
doc unreadable.
This fixes the orders in consistent way under pods/init-containers.md.
* updated self-hosting documentation
* removed more referances
* updated wording
* updated self-hosting warning to be more clear about the effects of pivot has on your cluster
* Update content/en/docs/setup/independent/self-hosting.md
Co-Authored-By: Klaven <mcounts@suse.com>
*minikube ssh* logs into the cluster as user 'docker'. The user 'docker' (uid=1000) does not have write permissions in /mnt to create a new directory and/or the example's HTML file. Use sudo(8) to create the directory as well as the HTML file nginx will ultimately serve.
* Fix typos and grammatical errors in README.md file
* Update README.md
make usage of the word 'website' in place of 'site' consistent across the file.
* Add new translation in Bahasa Indonesia
* Add revision to translation
* Edit type translation cloud-providers in Bahasa Indonesia
* Edit type translation cloud-providers
* Add translation Cluster Administration Overview in Bahasa Indonesia
* Delete cluster administration overview
* Add translation cluster administration overview in Bahasa Indonesia
* Delete cloud-providers. Shouldn't be here..
* Add translation cluster administration overview in Bahasa Indonesia
* Rewording cluster adminstration overview in ID
* Add new translation in Bahasa Indonesia
* Add revision to translation
* Edit type translation cloud-providers in Bahasa Indonesia
* Edit type translation cloud-providers
* Add translation Cluster Administration Overview in Bahasa Indonesia
* Delete cluster administration overview
Added steps to find out if virtualization in installed on the users OS.
Minor improvement
Capitalized Windows
Removed the shell from the command.
Update install-minikube.md
by kubectl apply.
The docs imply that lists whose elements are all primitives
are replaced by the applied config instead of being updated.
This PR states that explicitly for clarity.
* Add files via upload
KubeCon Barcelona 2019 Diversity Lunch & Hack Blog Post
* Update 2019-04-25-kubecon-diversity-lunch-and-hack.md
* Update and rename 2019-04-25-kubecon-diversity-lunch-and-hack.md to 2019-05-02-kubecon-diversity-lunch-and-hack.md
* Menerjemahkan connect-applicaitons-service kedalam bahasa Indonesia
* add examples files
* change title
* fix email
* fix minor typos and formatting
* fix minor & typo
* adding Elastic Stack for logging and monitoring
* added section on deploying Elasticsearch and Kibana
* more detail
* more detail
* First draft
* Using tutorial template.
* more goodness
* Describe autodiscover
* added verification steps
* Added cluster role binding
* Use Redis metrics and logs
* cleanup
* add cleanup
* unused
* Added language tags
* Added glossary_tooltip
* Added link
* Placed alternative steps in tabs
* shorten heading
* uppercase for Kubernetes objects
* cleanup secret
* grammar
* updated title and linked from the guestbook tutorial
* added reviewer. Thanks Tim!
* Removed default username/password
* typo, verbosity, more info.
`CPUCFSQuotaPeriod` Feature Gate is set from the flag name `CustomCPUCFSQuotaPeriod` per [`kube_features.go#163`](https://github.com/kubernetes/kubernetes/blob/master/pkg/features/kube_features.go#L163)
This PR updates the docs to suit.
In some respects it would be tidier to remove `Custom` prefix from `kube_features.go` so that the Feature Gate naming maps 1:1.
Happy to close this PR and do PR to remove 'Custom' prefix instead.
Added a step under the sections that guide the user to install the binary using curl on the OS. This is the same format maintained by the other section on this page.
* Add Setting up the OWNERS files section
* Update OWNERS_ALIASES patch
* Replace owners.md link with go.k8s.io/owners
* Replace github.com/kubernetes link with git.k8s.io
* Update OWNERS_ALIASES to use git.k8s.io link
* Sort patch diff in alphabetical order
* Specify clearly what teams should be added
* Remove the passive voice
* Complete alphabetical order phrase
* How You Can Help Localize Kubernetes Docs
Minor edits
Minor edits
Publish for 25 Apr
One typo
* Update 2019-04-25-latest-on-localization.md
* Update and rename 2019-04-25-latest-on-localization.md to 2019-04-26-latest-on-localization.md
* Translate declarative config for Bahasa Indonesia
* Fix typos and untranslated sentences from previous commit for declarative-config for Bahasa Indonesia
* Add _index.md to object-management-kubectl translations for Bahasa Indonesia
* Delete all pods matching the egrep pattern
* replace egrep with awk to delete pods by a pattern
* Update content/en/docs/reference/kubectl/cheatsheet.md
Co-Authored-By: ismailyenigul <ismailyenigul@gmail.com>
I thought this organization would give the users a better idea of what method to select based on the OS they use.
Initially, I was a wee bit confused when I saw how to Install kubectl binary with curl on the Mac OS and then another section on how to install Kubectl on the Mac OS.
Now, I moved the content under the $subject to the respective OS section.
P.S: I am still in the process of testing out the steps. :)
* Add translations for Ingress Controllers for Bahasa Indonesia
* Replace html tag italic with md syntax for Ingress Controller in Bahasa.
* Address typo and stuff for Ingress Controller translation to Bahasa Indonesia.
* Remove emphasis in title for Ingress Controller translation for Bahasa.
* Replace "obyek" with "objek".
* Fix minor typo and formatting.
* Blog post: Hardware Accelerated Crypto...
This adds a story of Hardware Accelerated SSL/TLS Termination
in Ingress Controllers using Kubernetes Device Plugins and RuntimeClass.
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
* Update Hardware-Accelerated-SSLTLS-Termination-in-Ingress-Controllers-using-Kubernetes-Device-Plugins-and-RuntimeClass.md
* Rename Hardware-Accelerated-SSLTLS-Termination-in-Ingress-Controllers-using-Kubernetes-Device-Plugins-and-RuntimeClass.md to 2019-04-23-Hardware-Accelerated-SSLTLS-Termination-in-Ingress-Controllers-using-Kubernetes-Device-Plugins-and-RuntimeClass.md
* Rename 2019-04-23-Hardware-Accelerated-SSLTLS-Termination-in-Ingress-Controllers-using-Kubernetes-Device-Plugins-and-RuntimeClass.md to 2019-04-24-Hardware-Accelerated-SSLTLS-Termination-in-Ingress-Controllers-using-Kubernetes-Device-Plugins-and-RuntimeClass.md
* menambahkan page pod overview
* finishing pod overview translate
* fix typo
* Change some words with suggest from reviewer
* fix typo and other for Pod Overview
* fix formatting issue
* Translate ingress for Bahasa Indonesia.
* Using markdown instead of html tag. Add `_index.md` in concepts.
* Remove italic md syntax from services-networking title in Bahasa.
* Replace all html italic tag in feature-state and Ingress for Bahasa.
* Address review for typo and paraprashing the content for Kubernetes in Bahasa.
* Fix nitty gritty Ingress translation for Bahasa Indonesia.
* Rebase from master
* Fix trailing . after inbound.
* Add Kubernetes Components in lang ID.
* Remove glossary since it's not translated yet.
* Add what is kubernetes? in ID lang
* Add kubernetes API in lang ID.
* Address id loc suggestions fo Kubernetes' overview.
* Remove uneeded lines of definitions.
* Add glossaries for Bahasa Indonesia.
* Add kubelet glossary for Bahasa Indonesia.
* Fix all italics due to missing period and false tag.
Plain language rocks
Remove an orphaned line
Remove note
Present tense rocks
Add repository
Feedback, round 1
Add team descriptions
Add Slack link
Feedback, part 2
Feedback from gochist
Remove link
* Revise guide for generating reference docs
This PR changes the guidance for generating reference documentation for
Kubernetes API and kubernetes components. The topic of making changes to
the upstream repo is separated out because 1) it is not a mandatory step
for generating the reference docs; 2) it is about a more advanced level
of documentation fix.
* light copyedit
* more light copyedits
* updated link for framework file
Fixed the invalid link referred by "framework file" in "Most of the common code are located in the framework file that leaves only one function to be implemented for different conversions.".
This fix is for the issue #13759 .
* updated framework file link reference to v1.14
changed docs version from v1.13.0 to v1.14.0 in the link reference
"framework file" -> https://github.com/kubernetes/kubernetes/tree/v1.14.0/test/images/crd-conversion-webhook/converter/framework.go
Changes the key name to `SPECIAL_LEVEL` in the config map volume definition.
This is consistent with the rest of the example. Otherwise, this pod does not
start because there is no key with that name in the `special-config` config map.
* Add formal definition of workloads
* Update workload.md
* add light copyedit
More section should not repeat short description. Both are served together on the built page.
These statement was intended to specify environment variable values available in the container but word 'environment variable' was missing so corrected these statements for better clarity.
fixed the invalid link referred by "this guide" in "In Kubernetes v1.11.0 and later, you can use kubeadm upgrade diff to see the changes that would be applied to static pod manifests."
this is fix for issue #13869
Add layouts/docs/glossary en i18n strings
Add layouts/docs/glossary es i18n strings
Use i18n strings in layouts/docs/glossary
Add layouts/blog/pager en i18n strings
Add layouts/blog/pager es i18n strings
Use i18n strings in layouts/blog/pager
Add layouts/blog/list en i18n strings
Add layouts/blog/list es i18n strings
Use i18n strings in layouts/case-studies/list
Add layouts/docs/search en i18n strings
Add layouts/docs/search es i18n strings
Use i18n strings in layouts/docs/search
Add layouts/partials/feedback en i18n strings
Add layouts/partials/feedback es i18n strings
Use i18n strings in layouts/partials/feedback
Set html lang using "{{ .Language }}"
* fixed the broken link
Fixed the broken link for CDK official documentation.
Resolving the issue #13820
* fixed broken link
made few changes required for the issue #13820
* Add es/docs/concepts index tree
* Add es/docs/contribute index tree
* Add es/docs/setup index tree
* Add es/docs/tutorials index tree
* Add es/docs/reference index tree
* Add es/docs/tasks index tree
* Add es/docs/reference landing page
* Add es/docs/home landing page
* Add es/docs/tutoriales landing page
* Add es/docs/getting-started-guides index tree
* Add es/docs/concepts landing page
* Add es/docs/contribute landing page
* Add es/docs/setup landing page
* Apply review requests and fixes
* Add OWNERS information for sig-docs-id
* Add Indonesian language to config.toml with highest weight
* Add README-id.md.
* Add common resources and case studies.
* Add i18n strings for Indonesian site
* Fix typos on OWNERS.
* Add Indonesian translation for home documentation
* Add kubernetes basics.
* Add Indonesian content for minikube tutorial
* Add Indonesian translation for setup cluster
* Fix typos on README-id, and replace you with more informal word
* Fix some typos and replace formal you expression on kubernetes basics
* fix an offense against the style guide.
> Refer to API objects without saying “object,” unless omitting “object” leads to an awkward construction.
* fix another one.
* [WIP] Clean up kubectl install page
Fixes issue #13577
* Update install-kubectl.md
Addresses @zacharaysarah and @jaredbhatti's comments.
Minor language Improvements:
- Deleted unnecessary adverbs
- Used fewer words where possible
Next pass will include deeper edits, with careful attention to the kubectl autocompletion section
* Update install-kubectl.md
* Create PID Limiting Blog
Blog from Derek Carr commissioned by Kaitlyn
* Update 2019-3-28-PID-Limiting
* Update and rename 2019-3-28-PID-Limiting to 2019-03-28-PID-Limiting
* Update and rename 2019-03-28-PID-Limiting to 2019-03-28-PID-Limiting.md
* Update 2019-03-28-PID-Limiting.md
* Update 2019-03-28-PID-Limiting.md
When using udp backend, flannel uses UDP port 8285 for sending encapsulated packets.
When using vxlan backend, kernel uses UDP port 8472 for sending encapsulated packets.
Make sure that your firewall rules allow this traffic for all hosts participating in the overlay network.
Fixed the broken link for 'kubectl autoscale' in the statement - Now that the server is running, we will create the autoscaler using kubectl autoscaling.
This issue is referenced in #13683
removed hyperlink from "An example" in the statement An example of this approach is a small container running logrotate periodically. However, it's recommended to use stdout and stderr directly and leave rotation and retention policies to the kubelet.
This fix is for issue #13656
The link for one function in the line "Most of the common code are located in the framework file that leaves only one function to be implemented for different conversions" has been changed.
Resolving issue #13760
There is a line accidentally added in kubefed.md:' ###### Auto-generated by spf13/cobra on 26-Mar-2019'. This is meaningless so removing this from the page.
This also fixes#13755
* Example for injecting single secret as env variable
Define a container environment variable with data from a single Secret
* Env variable using secret data
* Update pod-single-secret-env-variable.yaml
* Adding example for multiple env variable using secrets
Adding example for multiple env variables using secrets
* Create pod-secret-envFrom.yaml
* Update pod-multiple-secret-env-variable.yaml
* Update pod-multiple-secret-env-variable.yaml
* Update pod-multiple-secret-env-variable.yaml
* Update pod-single-secret-env-variable.yaml
* Update pod-multiple-secret-env-variable.yaml
* Update pod-single-secret-env-variable.yaml
* Different ways to add env variable using secret
Adding different ways to add env variable in pod using secret
* Correcting formatting issues
Correcting formatting issues
* Correcting format issue
init index.md
cleanup main doc
[docs-fr] add introduction and A record
[docs-fr] add dns policies for pods and services
[docs-fr] fix netlify deploy error when reading yaml file
[docs-fr] fix typos according to pr review
[docs-fr] update reviewers
I've attempted to have it make more sense by removing the word 'is'. Optionally, depending on the intended meaning, the sentence could read differently by leaving the word 'is' alone and changing the word 'through' to 'though'.
In given manifest, podManagementPolicy is set as Parallel, but in later section of page, the console logs of "kubectl get pods -w -l app=zk" command displays ordered behavior, which is not the actual result in case of Parallel option.
Sample logs from doc :
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 19s
zk-0 1/1 Running 0 40s
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 0s
zk-1 0/1 ContainerCreating 0 0s
zk-1 0/1 Running 0 18s
zk-1 1/1 Running 0 40s
zk-2 0/1 Pending 0 0s
zk-2 0/1 Pending 0 0s
zk-2 0/1 ContainerCreating 0 0s
zk-2 0/1 Running 0 19s
zk-2 1/1 Running 0 40s
## here pods are created in order
Actual results after applying the given manifest :
[taher@kubernetes-docker ~]$ kubectl apply -f zookeeper.yaml
service/zk-hs created
service/zk-cs created
poddisruptionbudget.policy/zk-pdb created
statefulset.apps/zk created
[taher@kubernetes-docker ~]$ kubectl get pods -w -l app=zk
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 3s
zk-1 0/1 Pending 0 3s
zk-2 0/1 ContainerCreating 0 3s
zk-1 0/1 Pending 0 4s
zk-0 0/1 Pending 0 4s
zk-1 0/1 Pending 0 5s
zk-0 0/1 Pending 0 5s
zk-1 0/1 Pending 0 5s
zk-1 0/1 ContainerCreating 0 5s
zk-0 0/1 Pending 0 5s
zk-2 0/1 Running 0 19s
zk-1 0/1 Running 0 24s
zk-2 1/1 Running 0 35s
zk-1 1/1 Running 0 37s
## here pods are created in parallel
Resolution :
Either change the value of podManagementPolicy option to OrderedReady or remove that option, so that StatefulSet will take it's default behavior.
k8s does not support nested namespaces but this is not specified anywhere in the document. I find this is the right place to document it as we introduce namespace concept here. Also these details are important to mention specifically for users who are coming from Docker UCP background.
* fix note shortcode, lists
- fix note shortcode for use in lists
- add example in style guide
* add more items to list
* update warning, caution, minor tweaks
* more updates
* Remove enable resource quota note
As of now, `ResourceQuotaScopeSelectors` is enabled by default, since it's in beta. So, let's remove it.
* Update resource-quotas.md
This commit adds two backwards compatible changes to prepare for the next Hugo version, most notable:
* All the `File` methods on `Page` has been deprecated and will give a warning in the next Hugo version. Adjust this by changing `.Dir` to ´.File.Dir` and similar.
* Version the capture shortcode to use the old behaviour for markdown rendering of shortcode inner content.
As reported in #13394, we have been incorrectly treating some resource
types from the 'extensions' group as the latest (recommended) version.
Resources impacted include `Ingress`, `NetworkPolicy`,
`PodSecurityPolicy` etc. This turned out to be a defect in the doc
generator which has been fixed.
* Connection reset blog post
* Update and rename 2019-03-27-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md to 2019-03-29-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md
* blog post on Minikube
* Updates
* Update 2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md
* Update 2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md
* Fix StorageObjectInUseProtection format in doc
Fix StorageObjectInUseProtection format to follow other admission controllers in doc.
* remove {#storageobjectinuseprotection}
* Correcting statement about Service ports
Correcting details about service ports and protocol. Removed statement saying Service supports the single port definition only and added details about multiport definitions.
* Correcting format changes
Correcting format changes as per feedback from reviewer.
This patch adds a entry in the kubeadm troubleshooting guide
about a problem that was found some time ago related to
kube-proxy DaemonSets and worker nodes in a CP setup.
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)
* Added documentation about Poseidon-Firmament scheduler
* Fixed some style issues.
* Udpated the document as per the review comments.
* Fixed some typos and updated the document
* Updated the document as per the review comments.
* Document timeout attribute for kms-plugin. (#12158)
See 72540.
* Official documentation on Poseidon/Firmament, a new multi-scheduler (#12343)
* Removed the old version of the Poseidon documentation. Incorrect location.
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S (#12069)
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)
* Added documentation about Poseidon-Firmament scheduler
* Fixed some style issues.
* Udpated the document as per the review comments.
* Fixed some typos and updated the document
* Updated the document as per the review comments.
* Updated the document as per review comments. Added config details.
* Updated the document as per the latest review comments. Fixed nits
* Made changes as per latest suggestions.
* Some more changes added.
* Updated as per suggestions.
* Changed the release process section.
* SIG Docs edits
Small edits to match style guidelines.
* add plus to feature state
* capitalization
* revert feature state shortcode
since this is a Kubernetes extension, not a direct feature, it shouldn't use the regular feature state tagging.
(cherry picked from commit 7730c1540b)
* Remove initializers from doc. It will be removed in 1.14 (#12331)
* kubeadm: Document CRI auto detection functionality (#12462)
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
* Minor doc change for GAing Pod DNS Config (#12514)
* Graduate ExpandInUsePersistentVolumes feature to beta (#10574)
* Rename 2018-11-07-grpc-load-balancing-with-linkerd.md.md file (#12594)
* Add dynamic percentage of node scoring to user docs (#12235)
* Add dynamic percentage of node scoring to user docs
* addressed review comments
* delete special symbol (#12445)
* Update documentation for VolumeSubpathEnvExpansion (#11843)
* Update documentation for VolumeSubpathEnvExpansion
* Address comments - improve descriptions
* Graduate Pod Priority and Preemption to GA (#12428)
* Added Instana links to the documentation (#12977)
* Added link to the Instana Kubernetes integration
* Added Instana link for services section
Added Instana and a link to the Kubernetes integration to the analytics services section and broadened the scope to APM, monitoring and analytics.
* Oxford comma /flex
* More Oxford commas, because they matter
* Update kubectl plugins to stable (#12847)
* documentation for CSI topology beta (#12889)
* Document changes to default RBAC discovery ClusterRole(Binding)s (#12888)
* Document changes to default RBAC discovery ClusterRole(Binding)s
Documentation for https://github.com/kubernetes/enhancements/issues/789 and https://github.com/kubernetes/kubernetes/pull/73807
* documentation review feedback
* CSI raw block to beta (#12931)
* Change incorrect string raw to block (#12926)
Fixes#12925
* Update documentation on node OS/arch labels (#12976)
These labels have been promoted to GA:
https://github.com/kubernetes/enhancements/issues/793
* local pv GA doc updates (#12915)
* Publish CRD OpenAPI Documentation (#12910)
* add documentation for CustomResourcePublishOpenAPI
* address comments
fix links, ordered lists, style and typo
* kubeadm: add document for upgrading from 1.13 to 1.14 (single CP and HA) (#13189)
* kubeadm: add document for upgrading from 1.13 to 1.14
- remove doc for upgrading 1.10 -> 1.11
* kubeadm: apply amends to upgrade-1.14 doc
* kubeadm: apply amends to upgrade-1.14 doc (part2)
* kubeadm: apply amends to upgrade-1.14 doc (part3)
* kubeadm: add note about "upgrade node experimental-control-plane"
+ add comment about `upgrade plan`
* kubeadm: add missing "You should see output similar to this"
* fix bullet indentation (#13214)
* mark PodReadinessGate GA (#12800)
* Update RuntimeClass documentation for beta (#13043)
* Update RuntimeClass documentation for beta
* Update feature gate & add upgrade section
* formatting fixes
* Highlight upgrade action required
* Address feedback
* CSI ephemeral volume alpha documentation (#10934)
* update kubectl documentation (#12867)
* update kubectl documentation
* add document for Secret/ConfigMap generators
* replace `kubectl create -f` by `kubectl apply -f`
* Add page for kustomization support in kubectl
* fix spelling errors and address comments
* Documentation for Windows GMSA feature (#12936)
* Documentation for Windows GMSA feature
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Enhancements to GMSA docs
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Fix links
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Fix GMSA link
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add GMSA feature flag in feature flag list
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Relocate GMSA to container configuration
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add example for container spec
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Remove changes in Windows index
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update configure-gmsa.md
* Update configure-gmsa.md
* Update configure-gmsa.md
* Update configure-gmsa.md
* Rearrange the steps into two sections and other edits
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Fix links
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add reference to script to generate GMSA YAMLs
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Some more clarifications for GMSA
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* HugePages graduated to GA (#13004)
* HugePages graduated to GA
* fixing nit for build
* Docs for node PID limiting (https://github.com/kubernetes/kubernetes/pull/73651) (#12932)
* kubeadm: update the reference documentation for 1.14 (#12911)
* kubeadm: update list of generated files for 1.14
NOTE: PLACEHOLDERS! these files are generated by SIG Docs each
release, but we need them to pass the k/website PR CI.
- add join_phase* (new sub phases of join)
- add init_phase_upload-certs.md (new upload certs phase for init)
- remove alpha-preflight (now both init and join have this)
* kubeadm: update reference docs includes for 1.14
- remove includes from alpha.md
- add upload-certs to init-phase.md
- add join-phase.md and it's phases
* kubeadm: update the editorial content of join and init
- cleanup master->control-plane node
- add some notes about phases and join
- remove table about pre-pulling images
- remove outdated info about self-hosting
* kubeadm: update target release for v1alpha3 removal
1.14 -> 1.15
* kubeadm: copy edits for 1.14 reference docs (part1)
* kubeadm: use "shell" for code blocks
* kubeadm: update the 1.14 HA guide (#13191)
* kubeadm: update the 1.14 HA guide
* kubeadm: try to fix note/caution indent in HA page
* kubeadm: fix missing sudo and minor amends in HA doc
* kubeadm: apply latest amends to the HA doc for 1.14
* fixed a few missed merge conflicts
* Admission Webhook new features doc (#12938)
- kubernetes/kubernetes#74998
- kubernetes/kubernetes#74477
- kubernetes/kubernetes#74562
* Clarifications and fixes in GMSA doc (#13226)
* Clarifications and fixes in GMSA doc
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update configure-gmsa.md
* Reformat to align headings and pre-reqs better
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Reformat to align headings and pre-reqs better
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Reformat to fix bullets
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Reword application of sample gmsa
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update configure-gmsa.md
* Address feedback to use active voice
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Address feedback to use active voice
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* RunAsGroup documentation for Progressing this to Beta (#12297)
* start serverside-apply documentation (#13077)
* start serverside-apply documentation
* add more concept info on server side apply
* Update api concepts
* Update api-concepts.md
* fix style issues
* Document CSI update (#12928)
* Document CSI update
* Finish CSI documentation
Also fix mistake with ExpandInUsePersistentVolumes documented as beta
* Overall docs for CSI Migration feature (#12935)
* Placeholder docs for CSI Migration feature
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Address CR comments and update feature gates
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add mappings for CSI plugins
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add sections for AWS and GCE PD migration
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add docs for Cinder and CSI Migration info
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Clarify scope to volumes with file system
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Change the format of EBS and Cinder CSI Migration sections to follow the GCE template
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Windows documentation updates for 1.14 (#12929)
* Updated the note to indicate doc work for 1.14
* first attempt at md export from gdoc
* simplifyig
* big attempt
* moving DRAFT windows content to PR for review
* moving content to PR in markdown for review
* updated note tags
* Delete windows-contributing.md
deleting this file as it is already ported to the github contributor guide
* fixed formatting in intro and cluster setup guide
* updating formatting for running containers guide
* rejiggered end of troubleshooting
* fixed minor typos
* Clarified the windows binary download step
* Update _index.md
making updates based on feedback
* Update _index.md
updating ovn-kubernetes docs
* Update _index.md
* Update _index.md
* updating relative docs links
updating all the links to be relative links to /docs
* Update _index.md
* Update _index.md
updates for windows services and ovn-kubernetes
* formatted for correct step numbering
* fix typos
* Update _index.md
updates for flannel PR in troubleshooting
* Update _index.md
* Update _index.md
updating a few sections like roadmap, services, troubleshooting/filing tickets
* Update _index.md
* Update _index.md
* Update _index.md
* Fixed a few whitespace issues
* Update _index.md
* Update _index.md
* Update _index.md
* add section on upgrading CoreDNS (#12909)
* documentation for kubelet resource metrics endpoint (#12934)
* windows docs updates for 1.14 (#13279)
* Delete sample-l2bridge-wincni-config.json
this file is not used anywhere
* Update _index.md
* Update _index.md
* Update _index.md
* Update _index.md
* Update _index.md
* Rename content/en/docs/getting-started-guides/windows/_index.md to content/en/docs/setup/windows/_index.md
moving to new location
* Delete flannel-master-kubectl-get-ds.png
* Delete flannel-master-kubeclt-get-pods.png
* Delete windows-docker-error.png
* Add files via upload
* Rename _index.md to add-windows-nodes.md
* Create _index.md
* Update _index.md
* Update add-windows-nodes.md
* Update add-windows-nodes.md
* Create user-guide-windows-nodes.md
* Create user-guide-windows-containers.md
* Update and rename add-windows-nodes.md to intro-windows-nodes.md
* Update user-guide-windows-containers.md
* Rename intro-windows-nodes.md to intro-windows-in-kubernetes.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-containers.md
* Update user-guide-windows-containers.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-containers.md
* Update _index.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
fixing the pause image
* Update intro-windows-in-kubernetes.md
changing tables from html to MD
* Update user-guide-windows-nodes.md
converting tables from HTML to MD
* Update intro-windows-in-kubernetes.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-nodes.md
updating the numbering , even though it messes up the notes a little bit. Jim will file a ticket to follow up
* Update user-guide-windows-nodes.md
* update to windows docs for 1.14 (#13322)
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update user-guide-windows-containers.md
* Update user-guide-windows-nodes.md
* Update intro-windows-in-kubernetes.md (#13344)
* server side apply followup (#13321)
* change some parts of serverside apply docs in response to comments
* fix typos and wording
* Update config.toml (#13365)
Existing details related to services are ambiguous as it does not give an idea when to use an environment variable for service discovery. Also, it does not talk about the DNS method of service discovery which is highly recommended. so corrected document to provide these missing details.
per the godocs:
// RootCAs defines the set of root certificate authorities
// that clients use when verifying server certificates.
// If RootCAs is nil, TLS uses the host's root CA set.
* E2E testing blog post
* E2E testing blog post: add information about optional command line flags
* Update and rename 2019-03-30-e2e-testing-for-everyone.md to 2019-03-22-e2e-testing-for-everyone.md
Adds a link to a new nodejs client library. New library builds on top of the godaddy lib, providing useful kubectl-like abstractions like `get` and `updateOrCreate`, and adds API-mapping and version-handling so the client code does not need to worry about compatibility across cluster versions.
Three optimizations:
- move example testing logic into a bash script to save travis specific
commands;
- use kubernetes release package (about 20MB) instead of git repo (about
800 MB at the moment);
- detect whether a PR contains changes to examples and skip examples
testing if not.
Closes: #13140
The tutorial has somebody expose this service externally, so they should be getting NodePort or LoadBalancer not ClusterIP. I followed this tutorial and that's what I got (as expected)
* Create 2019-03-12-kubeedge-k8s-based-edge-intro.md
Initial created.
* Create kubeedge-highlevel-arch.png
* Adding KubeEdge High Level Arch img
Adding KubeEdge High Level Arch img for the blog
* Adding KubeEdge Logo img
Adding KubeEdge Logo img for blog
* Updated KubeEdge intro blog
Updated all the sections for KubeEdge, a k8s based edge computing platform.
(2019-03-12-kubeedge-k8s-based-edge-intro)
* Update 2019-03-12-kubeedge-k8s-based-edge-intro.md
Minor format updates
* Update 2019-03-12-kubeedge-k8s-based-edge-intro.md
* [ReviewFix] 2019-03-12-kubeedge-k8s-based-edge-intro.md
Review of @stewart-yu fixed for KubeEdge/kubeedge link
* [ReviewFix] Format 2019-03-12-kubeedge-k8s-based-edge-intro.md
Linefeed update.
* Update 2019-03-12-kubeedge-k8s-based-edge-intro.md
* Update 2019-03-12-kubeedge-k8s-based-edge-intro.md
* [ReviewFix] 2019-03-12-kubeedge-k8s-based-edge-intro.md
KubeEdge control plane in cloud and extension part made it mode clear.
* Update 2019-03-12-kubeedge-k8s-based-edge-intro.md
* Rename 2019-03-12-kubeedge-k8s-based-edge-intro.md to 2019-03-19-kubeedge-k8s-based-edge-intro.md
* Update 2019-03-19-kubeedge-k8s-based-edge-intro.md
* Create Kubernetes-setup-using-Ansible-and-Vagrant.md
This blog describes the steps for to setting up a multi node Kubernetes cluster using Ansible and Vagrant.
* Apply suggestions from code review
Co-Authored-By: ljnaresh <naresh_lj@infosys.com>
* Markdown changes for syntax highting and reviews.
* Vagrant image & join command logic changes
* Update Kubernetes-setup-using-Ansible-and-Vagrant.md
* Adding author name and organization
* Markdown correction for colon
* Update Kubernetes-setup-using-Ansible-and-Vagrant.md
At its current form minikube fails to start with following error:
unknown flag: --AllowedUnsafeSysctls
Renaming it to allowed-unsafe-sysctls works as expected.
* Update command outputs to k8s 1.13 based
* Update command outputs to k8s 1.13 based (2)
* Add the way to download the example manifest and change datetime in a pod log
* create a job from remote url
* Update content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
Co-Authored-By: makocchi-git <makocchi@gmail.com>
* Fix not available config field in kubeadm-init.md
Update the line describing `unifiedControlPlaneImage`, since "unifiedControlPlaneImage" in ClusterConfiguration was changed to a boolean field called "useHyperKubeImage" in v1beta1.
( https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1 )
* Update image names and versions in kubeadm-init.md
$ kubeadm config images list
k8s.gcr.io/kube-apiserver:v1.13.4
k8s.gcr.io/kube-controller-manager:v1.13.4
k8s.gcr.io/kube-scheduler:v1.13.4
k8s.gcr.io/kube-proxy:v1.13.4
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.2.24
k8s.gcr.io/coredns:1.2.6
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
k8s.gcr.io/kube-proxy v1.13.4 fadcc5d2b066 10 days ago 80.3MB
k8s.gcr.io/kube-controller-manager v1.13.4 40a817357014 10 days ago 146MB
k8s.gcr.io/kube-scheduler v1.13.4 dd862b749309 10 days ago 79.6MB
k8s.gcr.io/kube-apiserver v1.13.4 fc3801f0fc54 10 days ago 181MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff4 4 months ago 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 5 months ago 220MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 14 months ago 742kB
* Update the way to use custom etcd image in kubeadm-init.md
According to rosti's [comment](https://github.com/kubernetes/kubeadm/issues/1255#issuecomment-439874004),
the `image` field under `etcd` (from `v1alpha3`) was replaced by a couple of fields - `imageRepository` and `imageTag`.
* Apply suggestions from @neolit123 in kubeadm-init.md
Suggestions from @neolit123: https://github.com/kubernetes/website/pull/13068#pullrequestreview-212806230
* Apply a suggestion from @rosti in kubeadm-init.md
A suggestion from @rosti : https://github.com/kubernetes/website/pull/13068#discussion_r264228348
We've redone OpenUnison's k8s integration to provide multiple "spins". We created a new page to point users to the GitHub repo that matches the "spin" they're looking for.
In the calculation of this `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
`88Gi` of local storage. - It was 98Gi for storage instead of 88Gi which is derived after negating System-Reserved+Kube-reserved+eviction+hard
* Clarified step of getting Kubernetes cluster name; fixed quoting in command that sets `APISERVER`.
Need to set `CLUSTER_NAME` before using it.
The single quote in the `APISERVER` command prevented the expansion of the `CLUSTER_NAME` variable.
* Remove whitespace
* ko-trans: Update outdated contents in ko7 branch (#12762)
* ko: Update outdated files in dev-1.13-ko.7 (#12805)
* ko: Translate docs/home/_index.md in Korean (#12829)
* Translate scheduler-perf-tuning.md in Korean (#12782)
* Translate concepts/overview/object-management-kubectl/overview in Korean (#12834)
* Fix new line in Korean translation scheduler-perf-tuning.md (#12835)
* ko: Translate tutorials/online-training/overview.md in Korean (#12854)
* ko: Translate contribute/_index.md in Korean (#12850)
* ko: Update localization guide about instruction-type content (#12877)
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho <shsongist@gmail.com>
Co-authored-by: Kim Young Dae <38598117+zer0big@users.noreply.github.com>
* Translate architecture concepts in French
* Update content/fr/docs/concepts/architecture/nodes.md
Co-Authored-By: sieben <remy.leone@gmail.com>
* Update content/fr/docs/concepts/architecture/nodes.md
Co-Authored-By: sieben <remy.leone@gmail.com>
* Update content/fr/docs/concepts/architecture/nodes.md
Co-Authored-By: sieben <remy.leone@gmail.com>
* Update content/fr/docs/concepts/architecture/nodes.md
Co-Authored-By: sieben <remy.leone@gmail.com>
* Translate website homepage to french
* Translate case-studies index page into french
* Translate kubeweekly block into french
* Fix translation of Kubernetes features title into french
* Fix SSH tunnel links
* Removed reference to GKE, which seemed to prompt the initial removal.
* Fixed the link to refer back to the correct paragraph now that it exists again.
* Noted deprecation of SSH tunnels but work to create a replacement.
Fix#8262
This reverts commit 1da65603af.
This reverts commit b8b71b6845.
* Update master-node-communication.md
Tidy up protocol support to show that TCP and UDP have support in
stable, whereas SCTP support is in alpha. For HTTP, direct users to
read up on Ingress instead.
* bluemix.net links are deprecated and no longer updated
* updated to new cloud.ibm.com link style
* also the product name is IBM Cloud Kubernetes Service, not Armada
* follow on to PR #12792
* Use feature-state note for CRI
* Note applicability to Linux hosts
* Explain cgroup ("control group")
* De-emphasize cgroup details
The individual runtime install steps already take account of this
advice.
* Fix bug about kubeadm upgrading
It will lead to the following error if using `yum upgrade -y kubeadm --disableexcludes=kubernetes` command:
<https://serverfault.com/questions/943696/fatal-unexpected-error-when-reading-kubeadm-config-configmap-clusterconfigurat>
Running `yum upgrade -y kubeadm --disableexcludes=kubernetes` command will upgrade the kubeadm to v1.13 but kubeadm v1.13 could not upgrade the v1.12 kubeadm cluster.
* Update kubeadm-upgrade-1-12.md
* Update kubeadm-upgrade-1-12.md
* Update kubeadm-upgrade-1-12.md
* add --csr-only option
The flag `--use-csr` is no longer available as of 1.13 on. Got replaced by `--csr-only`.
* replace deprecated kubeadm cert renewal flag
* Revising bluemix.net links to cloud.ibm.com
* bluemix.net links are deprecated and no longer updated
* updated to new cloud.ibm.com link style
* Removing blog content
* ko: Update outdated files in dev-1.13-ko.6 (#12456)
* Translate concepts/containers/runtime-class.md in Korean (#12459)
* Fix ko translation consistency for commandlinetool word (#12626)
* Added Korean localization guide (#12597)
* Translate containers/images.md in Korean (#12549)
* Translate container-lifecycle-hooks.md in Korean (#12534)
* Translate tasks/run-application/horizontal-pod-autoscale in Korean (#12565)
* Translate concepts/architecture/cloud-controller in Korean #11964 (#12483)
* ko-trans: add setup/certificate.md #12453 (#12520)
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Seokho <shsongist@gmail.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: Kim Young Dae <38598117+zer0big@users.noreply.github.com>
Co-authored-by: Yoon <learder@gmail.com>
* Create ingress-minikube.md
* Update ingress.md
* Move Ingress controllers content to own page
* Link to Set up Ingress on Minikube with the NGINX Controller task
* Minor edits
* Create ingress-controllers.md
* Update ingress-controllers.md
* Add Pod Disruption Budget to Glossary
* Update content/en/docs/reference/glossary/pod-disruption-budget.md
Cross referenced Pod term
Co-Authored-By: McCoyAle <mccoyale@gmail.com>
* Update pod-disruption-budget.md
* Add cross-namespace service account example, clarify binding wording
* Add create role and create clusterrole help
* Add reconcile documentation
* Document roleRef restrictions
- Use “Job” to mean the Kubernetes object
- Use “job” where capitalization hinders readability
- Use “task”, or other synonymous concepts, to avoid confusion
- Use “Pod” to mean the Kubernetes object
- Use “pod” where capitalization hinders readability
- Use “container” in lowercase everywhere
Also:
- Clarify work queue example for Job controller
- Fix advice on running Job example
- Tweak emphasis
* Use glossary terms when explaining Secret concept
* Tidy up advice on keeping Secrets secret
* Reformat note on how Secrets are displayed
* Use mebibytes
* Update network doc for ip-per-pod reqs
As per SIG-Network discussion, we can relax the requirement for all
nodes to be able to reach all pods on those platforms that do not
support hostNetwork.
The current thinking on Windows support is that hostNetwork is not a
requirement for Window users. As such, satisfying the old requirement
is very difficult and has no practical benefit.
This DOES NOT change the requirements for platforms that support
hostNetwork (e.g. Linux) nor does it make hostNetwork optional for Linux
nodes.
This PR also removes most comparisons to Docker, as they are stale and
no longer germane, and cleans up some of the text.
* Feedback on contents
* setup/cri: add a section about cgroup drivers
A cgroup driver is an important setting for the CRI and the kubelet.
Add a section that explains why "systemd" is the suggested value
for a driver when installing a CRI.
In the case of Docker the kubelet will receive this value automatically.
For the other CRIs, the users should tackle this manually.
* Update cri.md
* Update building-from-source.md
Update the page to be consistent with the concepts template.
* Update building-from-source.md
Update the page to be consistent with the concepts template.
It looks like `nginx -s quit` returns immediately rather than blocking until nginx has finished gracefully shutting down. As a result, just running `nginx -s quit` in the preStop hook won't work very well for high load and/or long running requests; nginx will get a TERM signal (and do a hard shutdown) immediately after `nginx -s quit` returns.
(I was getting connection errors while terminating pods, and adding a sleep-until-done to the preStop hook seemed to make them go away.)
* Add service path to CRD webhook conversion example
* Update wording in CRD conversion example to indicate it is serving traffic
Co-Authored-By: nrfox <nickfox25@gmail.com>
The changes are in line with one of the request for documentation update as per PR #55807 wherein it was observed that the preStop hook is not commissioned when the container is already in the terminated or completed state.
Braces removed as per the review comment. Multiple commits squashed
Braces removed as per the review comment
Update as per review, removed etc... and the statement is now cleaner
* Disruptions: make clearer not all voluntary disruptions are constrained by PDBs
Currently, there's confusion on whether all voluntary disruptions are constrained by PDBs.
For example, see the three comments [here](https://github.com/kubernetes/kubernetes/issues/39824#issuecomment-436322189).
* Update content/en/docs/concepts/workloads/pods/disruptions.md
Co-Authored-By: davidxia <davidxia@users.noreply.github.com>
* Update content/en/docs/concepts/workloads/pods/disruptions.md
Co-Authored-By: davidxia <davidxia@users.noreply.github.com>
* Update disruptions.md
* Alias for kubectl with completion.
Use a shorthand alias for `kubectl` that also works with completion. Using completion is great but typing `kubectl` each time is annoying.
* Update content/en/docs/reference/kubectl/cheatsheet.md
Co-Authored-By: jogy <johann@gyger.name>
* Update AKS mitigation link
Updated to include link to AKS documentation on mitigation.
* Updated Microsoft Recommendation
Updated with suggested changes
Rev Substitute en.toml for pedefined english shortcodes
Remove prefix Substitute en.toml for pedefined english shortcodes
Rev minor Substitute en.toml for pedefined english shortcodes
Address the issue raised in
https://github.com/kubernetes/kubernetes/issues/73808, where it became
clear it would be helpful for there to be a reminder for the user that
they are responsible for managing the StatefulSet which provides DNS
names for the pods in a StatefulSet.
Cleaned up the section __Revision History Limit__ to reflect the default value of `.spec.revisionHistoryLimit` being 10, instead of saying "All old ReplicaSets will be kept by default"
* Adding proposed blog post for building-a-kubernetes-edge-control-plane-for-envoy-v2
* Update article with improvements and author list
* Update and rename building-a-kubernetes-edge-control-plane-for-envoy-v2.md to 2019-02-11-building-a-kubernetes-edge-control-plane-for-envoy-v2.md
* Add extra coverage about use of Golang in Ambassador 0.50
* Minor typo fixes
* Minor typo fix, and merge fix with date
* Update 2019-02-11-building-a-kubernetes-edge-control-plane-for-envoy-v2.md
* Delete building-a-kubernetes-edge-control-plane-for-envoy-v2.md
* Update 2019-02-11-building-a-kubernetes-edge-control-plane-for-envoy-v2.md
* First pass on a blog post about CVE-2019-5736.
* Clarify that k8s is not the problem.
* Fix example of pinning to an image hash.
My mistake deftly caught by @zparnold.
Co-Authored-By: coderanger <noah@coderanger.net>
* Add links to the rest of the notices or releases.
* Add ways to get more info.
* RHEL link for those that don't selinux.
* Link to Rancher's back ports.
* Adding container state details in documentation
* Adding container state details to documentation
* Incorporating changes suggested in review by /ryanmcginnis
* First draft of the updates to the ReplicaSet Docs
To start with, I tried to cleanup the docs to adhere to the style guide https://kubernetes.io/docs/contribute/style/style-guide/. I then added some description of the ReplicaSet-Pod link via the owner reference field and behavior by it. I also made a clarification on the ReplicaSet demo where it was being redundant for the sake of demonstrating the different forms of usage. I consider this draft incomplete as I still lack knowledge of how the pod labels affect the behavior.
* Clearing up RC refs & explaining acquisition behavior
I'm beginning to address the cr by cleaning up references to the ReplicationController and making it clear that RCs are discouraged/old. I then expanded on the behavior of ReplicaSet in the presence of pods it can acquire but are not created directly by it.
* Mismatched link seems to have disappeared from preview
"As with all other Kubernetes API objects," etc... is present in the sibling concepts/workloads/controllers/ files, so I am hesitant to change that w/o changing the others, but I did abbreviate it.
"The `.spec.template` is the only required field of the `.spec`." is false, we also need the selector
Trying to address passive voice
Cleaned up Writing a ReplicaSet Manifest section
removed How to use a ReplicaSet section as it has redundant info from the examples and Alternatives section
Expanded examples a bit
Cleared up passive voice
* refactoring link to example yaml
* adding pod-rs test case
* Addressing Steve Perry's comments
Capitalize Pod throughout.
Link is not rendering correctly. Use () instead of [] for the path.
Ending with "for the creation" seems vague to me. Maybe this:
"...reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod template."
Suggestion: "is via the Pod's metadata.ownerReferences field." That way the reader won't jump to the incorrect conclusion that we're talking about the ReplicaSet's metadata.ownerReferences field.
with fields, including a selector that
and plans accordingly
Our style for headings is sentence case. So this heading would be "How a ReplicaSet works".
Several headings in this topic need to be converted to sentence case.
cleaned up frontend.yaml example
added example checking the Pod's owner reference being set to it's parent ReplicaSet
* Previous commit broke Pod example links due to casing
* Forgot 1 comment
Suggestion: In the ReplicaSet, .spec.template.metadata.labels must match spec.selector, or ...
* Addressing grammar/syntax errors
* Blog post for Poseidon-Firmament Scheduler
* Fixed some typos. Fixed some formatting. Added links.
* Update and rename 2019-02-04-poseidon-firmament-scheduler-announcement.md to 2019-02-06-poseidon-firmament-scheduler-announcement.md
* Made some changes to the Key Advantages section.
Since minikube v0.33.0 the default CNI config is not being provisioned
by default (https://github.com/kubernetes/minikube/pull/3441). Therefore,
we need to pass `--enable-default-cni` when starting minikube.
There is output of `kubeadm init` in create-cluster-kubeadm page.
But it is little old.
Some processes aren't included in it.
This update `kubeadm init` output to latest.
Since Kubernetes 1.10, the only supported CRI version is v1alpha2. However,
rktlet does not support that version and development seems stopped.
As there is no way to use rktlet with k8s >= 1.10, it's best to just remove
the rkt link from the "Install runtime" section of "Install kubeadm".
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
* kubeadm: add a caution about certs in HA document
* Update content/en/docs/setup/independent/high-availability.md
Co-Authored-By: neolit123 <neolit123@gmail.com>
If there is a combination of `systemctl` commands where in one you are
enabling it and in another you are starting it, that can be done in one
single command with an additional flag called `--now`. This commit
changes those two command steps in docs to one command.
The help of systemctl shows the following explanation of `--now`:
```
Start or stop unit in addition to enabling or disabling it
```
Signed-off-by: Suraj Deshmukh <surajd.service@gmail.com>
* Add `jsonpath` approach for apiserver query
* Refine the wording with the approach description
* Refine the command log
* Move the itemized number back
Added VMware Cloud PKS and Cloud Foundry Container Runtime to places within the document that are correctly represented for Cloud and on-primises offerings and tooling. I also properly alphabetized the list.
Signed-off-by: Kendrick Coleman <kendrickc@vmware.com>
The "Assigning Pods to Nodes" page did not mention nodeName, which, if
specified, takes priority over the methods discussed in the page. Add
description of nodeName and an example using it.
Address reviewer comments from @bsalamat and @liggitt, thanks!
* Fix docs home subnav link name
* change linkTitle to Home
* accept fix from master
* refactor docs home template
* bump
* test
* switch layout to basic
* swap in cards
* test card css
* add launch-cards and launch-card classes
* swap in content
* use different layout name to not affect user journeys
* revert file naming
* revert docsportal.html
* remove main, add kubeadm link
* documentation -> docs
* change kubeadm link
* Updated pick-right-solution.md with Docker Enterprise
Added Docker commercial and community products to the list of solutions for running Kubernetes including Docker Desktop and Docker Enterprise.
* Fix Docker Desktop entry in pick-right-solution.md
The words "Docker Desktop" was duplicated in the description under locally-hosted solutions.
* Updated pick-right-solution.md with Docker solutions
Added line wraps at 80 characters and changed containerizing to "deploying in containers" to make it more new-user friendly.
* Updated pick-right-solution.md
modified wrapping of first line to not break hyphenated word.
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)
* Added documentation about Poseidon-Firmament scheduler
* Fixed some style issues.
* Udpated the document as per the review comments.
* Fixed some typos and updated the document
* Updated the document as per the review comments.
* Updated the document as per review comments. Added config details.
* Updated the document as per the latest review comments. Fixed nits
* Made changes as per latest suggestions.
* Some more changes added.
* Updated as per suggestions.
* Changed the release process section.
* SIG Docs edits
Small edits to match style guidelines.
* add plus to feature state
* capitalization
* revert feature state shortcode
since this is a Kubernetes extension, not a direct feature, it shouldn't use the regular feature state tagging.
"Planet Scale" means a global scale which "全球规模" will be better for this description in chinese. "Designed on the same principles that allows Google to run billions of containers a week" to "基于允许 Google 每周运行数十亿个容器的原则进行设计", it's more natural in chinese.
* ko-trans: Fix broken page index for concepts/overview (#11533)
* ko-trans: Update outdated files in dev-1.13-ko.4 (#11544)
* 1. Translate naturally (#11759)
2. Fix markdown error
* ko-trans: Translate building-from-source.md (#11893)
* ko-trans: Translate building-from-source.md
* Address comments
* Update etcd.md (#11976)
* ko-trans: Translate ko/_index.html into Korean (#11937)
* ko-trans: Translate ko/_index.html into Korean.
* Reflect a translation comment. Translate ko/_index.html into Korean
* ko-trans: Translate online-training/overview.md (#11932)
* ko-trans: Translate node-conformance.md (#11907)
* ko-trans: Translate node-conformance.md
* Replace 명세 with 매니페스트.
* Address comments
* ko-trans: Translate tutorials/configuration (#11933)
* ko-trans: Translate `tutorials/configuration` directory
* Address comments
* ko-trans: content/ko/docs/reference/glossary/controller.md (#11994)
* ko-trans: Controller
ko-trans: Controller
* the feedback applied.
the feedback applied.
* minor edit
minor edit
* minor edit #2
minor edit #2
* ko-trans: reference/glossary/kube-apiserver.md (#12024)
ko-trans: reference/glossary/kube-apiserver.md
* Translate tutorials/stateless-application/ in Korean (#12008)
* Translate tutorials/stateless-application/ in Korean
* Apply comments
* Fix deployment related typos
* Translate content/ko/docs/concepts/architecture/nodes in Korean #11748 (#11850)
* Translate content/ko/docs/concepts/architecture/nodes in Korean #11748
* Translate content/ko/docs/concepts/architecture/nodes in Korean #11748
* Translate content/ko/docs/concepts/architecture/nodes in Korean #11748
* Translate concepts/workloads/pods/pod-lifecycle in Korean (#12054)
* Translate concepts/workloads/pods/pod-lifecycle in Korean
* apply review ko-translate concepts/.../pod-lifecycle
* ko-trans: kube-controller-manager.md (#12077)
ko-trans: docs/reference/glossary/kube-controller-manager.md
* fix Italic syntax markdown error (#12128)
* Translate tasks/_index.md in Korean (#12126)
* Translate tasks/_index.md in Korean
* Apply review for Translate tasks/_index.md in Korean
Apply comments for Translate tasks/_index.md in Korean
* Translate setup/_index.md in Korean (#12067)
* Translate setup/_index.md in Korean
* Update setup/_index.md for Korean term consistency
* ko-trans: docs/setup/custom-cloud/kops.md (#11904)
* ko-trans: concepts/overview/working-with-objects/names (#11758)
* ko-trans: /docs/concepts/overview/working-with-objects/namespaces.md (#11773)
* Translate setup/cri.md in Korean (#12174)
* Translate setup/cri.md in Korean
* Apply review, Translate setup/cri.md in Korean
* Translate tasks/tools/install-minikube in Korean (#12176)
* Translate tasks/tools/install-minikube in Korean
* Apply review,Trans tasks/tools/install-minikube in KO
* Update Hugo version and apply HTML minification to production builds
* Use full flag names for clarity
* Remove Hugo installation logic out of Travis config and into Makefile
* Add Hugo version checking script
* Fix Netlify config version
According to `content/en/docs/reference/access-authn-authz/bootstrap-tokens.md` bootstrap tokens are in state `beta` but here it's still listed as `alpha`
* Update assign-pod-node.md
Use `kubectl get nodes --show-labels` to show the labels will not show the compelte labels like this:
```
root@master:/home# kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 41h v1.13.1 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
server01 Ready <none> 41h v1.13.1 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,func=database,kubernetes.io/hostname=moon-server01
```
and the command `kubectl describe node "nodename" ` will show all labels the node have.
* Update assign-pod-node.md
* Update assign-pod-node.md
add a space before the new sentence
* adding feature state snip
Adding in the feature state to indicate when this feature was introduced.
* adding in "stable"
Didn't know it defaulted to alpha.
* Updated a link
The section was directing to Kubernetes Objects for more information about the Kubernetes APIs. I updated the link so it directs to the Kubernetes API page.
* Added a missing / to the link.
* Updated as per the comment.
The LimitedResource type has the field "MatchScopes" as a sibling to
the field "Resource," but the YAML document in the example showed the
"MatchScopes" field as a child of the top-level Configuration
type. Correct the example to match the actual schema.
While we're here, swap the order of the "scopeName" and "operator"
fields used in the YAML, to make it clearer in infix style that the
operator binds the scope name to a (possibly empty) set of values.
* Update storage-classes.md
Fixed the formatting issues that were incorrectly showing the variables as hyperlink texts that resulted in 404 errors
* Update storage-classes.md
Incorporated the changes
* Update storage-classes.md
removed the </strong tag that was not required.
* Update storage-classes.md
replaced <em> with `.
Alongwith the kubelet flag you can also use the `KubeletConfiguration`'s
`staticPodPath` to specify the path to pick up the static pod configs.
Signed-off-by: Suraj Deshmukh <surajd.service@gmail.com>
* [WIP] Add template for tool reference docs
- provide a template for generating tool reference docs.
- use in reference-docs/gen-compdocs/generators to create
consist looking markdown files for the tools.
* Fix lines
* remove test page
* Removed redundant sentence.
The intro line was repeated twice. Therefore, removed the one under the Synopsis section.
Updated the command from " " to ` ` based on the style guide.
* Updated master to control plane.
* patch-reset
We should reset IPVS tables do so manually when reset kubernetes cluster by kubeadm.
* Modify reset ipvs description
* Update create-cluster-kubeadm.md
- use "control plane" instead of "master".
- upgrade a kubelet on the CP node only after the CP was upgraded.
- also instruct the user to update to the latest patch version of 1.13.
* Add Minikube latest version shortcode and update installation doc
* Rework Minikube install instructions and remove unnecessary shortcode
* Re-add the --ignoreCache flag to make serve
I removed the instruction regarding the installation of docker (1.13.1) as listed in #11779 and updated the instructions for Docker CE (1.18.1) because the official Docker documents only have instructions for Docker CE and Docker EE as listed in https://github.com/docker/docker.github.io/blob/master/install/linux/docker-ce/ubuntu.md. It may not be a good idea to have instructions for Docker 1.13 in our documents considering that the Official Docker Install guide recommends uninstalling older versions.
* Add note about need for lxd init
As a first time user, I got a little lost, doing google searches for how to get lxd basically functional on my box.
There were a lot of hand edits and tweaks suggested on various pages, until I discovered that all I had to do is run "lxd init" and follow the prompts.
* Update local.md
I was at Kubecon last week, and a few times I encountered people who did not know that k8s == Kubernetes. Therefore, we should mention this abbreviation on the front page.
* Remove old kube-dns note
* ExternalName IP clarification
* Add minor edits for clarity
* corrections
Co-Authored-By: nikopen <42466421+nikopen@users.noreply.github.com>
* cAdvisor web UI port has been deprecated since v1.10. This patch update the description about it.
* Update resource-usage-monitoring.md
* Update resource-usage-monitoring.md
* Remove odd closing link bracket
In cases were you don't have hash in the links, it's breaking the link
See Also: #10775
* Move brckets from the wrong location
See Also: #10775
* OpenContrail -> Tungsten Fabric
OpenContrail has joined the Linux Foundation Networking Fund and rebranded as Tungsten Fabric to better reflect its open community engagement separate from its Juniper Network roots.
This edit updates the doc to reflect the name change and that Tungsten Fabric is a separate entity from Juniper's Contrail product.
* Include TF in the header
To further reinforce that Contrail and TF are different things.
"run" is deprecated and "create deployment" is preferred
so the english doc was updated in #11392
this pr reflects that change in the korean translation
* Blog post about Shanghai NCW. Submitting for website.
* Update 2018-12-05-new-contributor-shanghai.md
* Update 2018-12-05-new-contributor-shanghai.md
* Added required image credit to NCW Shanghai blog post, since image info doesn't display in the actual blog.
* Blog post about Shanghai NCW. Submitting for website.
* Update 2018-12-05-new-contributor-shanghai.md
* Update 2018-12-05-new-contributor-shanghai.md
* kubeadm GA blog post
* Change file name and add post metadata
* Update CSS for blog post tables
* More formatting and wording changes
* Change build process to allow for displaying future blog posts
* Add links to command documentation
* Change blog post date and address PR feedback
* More wording updates
* 1.13 blog post
* Update and rename 2018-12-03-kubernetes-1-13-release.md to 2018-12-03-kubernetes-1-13-release-announcement.md
* Update 2018-12-03-kubernetes-1-13-release-announcement.md
* Delete 2018-11-07-grpc-load-balancing-with-linkerd.md
* Update metadata.generation behaviour for custom resources (#10705)
* update docs promoting plugins to beta (#10796)
* docs update to promote TaintBasedEvictions to beta (#10765)
* First Korean l10n work for dev-1.13 (#10719)
* Update outdated l10n(ko) contents (#10689)
fixes#10686
* Translate concepts/overview/what-is-kubernetes in Korean (#10690)
* Translate concepts/overview/what-is-kubernetes in Korean
* Feedback from ClaudiaJKang
* Translate concepts/overview/components in Korean (#10882)
* Translate concepts/overview/components in Korean #10717
* Translate concepts/overview/components in Korean
* Translate concepts/overview/components in Korean
* Apply Korean glossary: 서비스 어카운트
* Translate concepts/overview/kubernetes-api in Korean (#10773)
* Translate concepts/overview/kubernetes-api in Korean
* Applied feedback from ianychoi
* kubeadm: update the configuration docs to v1beta1 (#10959)
* kubeadm: add small v1beta1 related updates (#10988)
* ADD content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md (#11031)
* ADD content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md
* ADD content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md
* Update content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md
Accepted
Co-Authored-By: YouthLab <tsui@highyouth.com>
* do not change 'master' or 'worker' nodes to '主从'
* Doc updates for volume scheduling GA (#10743)
* Doc updates for volume scheduling GA
* Make trivial change to kick build
* Document nodelease feature (#10699)
* advanced audit doc for ModeBlockingStrict (#10203)
* Rename EncryptionConfig to EncryptionConfiguration (#11080)
EncryptionConfig was renamed to EncryptedConfiguration and added to
the `apiserver.config.k8s.io` API group in Kubernetes 1.13.
The feature was previously in alpha and was not handling versions
properly, which lead to an originally unnoticed `v1` in the docs.
* content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md
* trsanlate create-cluster-kubeadm.md to chinese (#11041)
* trsanlate create-cluster-kubeadm.md to chinese
* Update create-cluster-kubeadm.md
* update the feature stage in v1.13 (#11307)
* update new feature gates to document (#11295)
* refresh controller role list on rbac description page (#11290)
* node labeling restriction docs (#10944)
* Update 1.13 docs for CSI GA (#10893)
* dynamic audit documentation (#9947)
* adds dynamic audit documentation
* Copyedit for clarity
See also inline question/s
* Fix feature state shortcode
* Update feature state
* changes wording for dynamic audit flag behavior
* Minor copyedit
* fix dynamic audit yaml
* adds api enablement command to dynamic audit docs
* change ordering dynamic audit appears in
* add references to dynamic audit in webhook backend
* reword dynamic audit reference
* updates stages field for audit sink object
* changes audit sink api definition; rewords policy
* kubeadm: remove kube-proxy workaround (#11162)
* zh-trans content/en/docs/setup/independent/install-kubeadm.md (#11338)
* zh-trans content/en/docs/setup/independent/install-kubeadm.md
* Update install-kubeadm.md
* Update dry run feature to beta (#11140)
* vSphere volume raw block support doc update (#10932)
* Add docs for Windows DNS configurations (#10036)
* Update docs for fields allowed at root of CRD schema (#9973)
* Add docs for Windows DNS configurations
* add device monitoring documentation (#9945)
* kubeadm: adds upgrade instructions for 1.13 (#11138)
* kubeadm: adds upgrade instructions for 1.13
Signed-off-by: Chuck Ha <ha.chuck@gmail.com>
* add minor copyedits
Addressed a couple of copyedit comments a bit more cleanly.
* kubeadm: add improvements to HA docs (#11094)
* kubeadm: add information and diagrams for HA topologies
* kubeadm: update HA doc with simplified steps
* kubeadm: update HA doc with simplified steps
* edit ha, add new topology topic, reorder by weight
* troubleshoot markdown
* fix more markdown, fix links
* more markdown
* more markdown
* more markdown
* changes after reviewer comments
* add steps about Weave
* update note about stacked topology
* kubeadm external etcd HA upgrade 1.13 (#11364)
* kubeadm external etcd HA upgrade 1.13
Signed-off-by: Ruben Orduz <rubenoz@gmail.com>
* Update stacked controlplane steps
* kubeadm cert documentation (#11093)
* kubeadm certificate API and CSR documentation
* copyedits
* fix typo
* PR for diff docs (#10789)
* Empty commit against dev-1.13 for diff documentation
* Complete Declarative maangement with diff commands
* Second Korean l10n work for dev-1.13. (#11030)
* Update outdated l10n(ko) contents (#10915)
* Translate main menu for l10n(ko) docs (#10916)
* Translate tasks/run-application/horizontal-pod-autoscale-walkthrough (#10980)
* Translate content/ko/docs/concepts/overview/working-with-objects/kubernetes-object in Korean #11104 (#11332)
* Pick-right-solution page translates into Korean. (#11340)
* ko-trans: add jd/..., sap/..., ebay/..., homeoffice/... (#11336)
* Translate concept/workloads/pods/pod-overview.md (#11092)
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: zerobig <38598117+zer0big@users.noreply.github.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: lIuDuI <1693291525@qq.com>
Co-authored-by: Woojin Na(Eddie) <cheapluv@gmail.com>
* Rename encryption-at-rest related objects (#11059)
EncryptionConfig was renamed to EncryptedConfiguration and added to
the `apiserver.config.k8s.io` API group in Kubernetes 1.13.
The feature was previously in alpha and was not handling versions
properly, which lead to an originally unnoticed `v1` in the docs.
Also, the `--experimental-encryption-provider-config` flag is now called
just `--encryption-provider-config`.
* Documenting FlexVolume Resize alpha feature. (#10097)
* CR webhook conversion documentation (#10986)
* CR Conversion
* Addressing comments
* Addressing more comments
* Addressing even more comments
* Addressing even^2 more comments
* Remove references to etcd2 in v1.13 since support has been removed (#11414)
* Remove etcd2 references as etcd2 is deprecated
Link back to the v1.12 version of the etcd3 doc for
the etcd2->etcd3 migration instructions.
I updated the kube-apiserver reference manually,
unsure if that is auto-generated somehow.
The federation-apiserver can still potentially
support etcd2 so I didn't touch that.
* Remove outdated {master,node}.yaml files
There are master/node yaml files that reference
etcd2.service that are likely highly out of date.
I couldn't find any docs that actually reference
these templates so I removed them
* Address review comments
* Final Korean l10n work for dev-1.13 (#11440)
* Update outdated l10n(ko) contents (#11425)
fixes#11424
* Remove references to etcd2 in content/ko (#11416)
* Resolve conflicts against master for /ko contents (#11438)
* Fix unopened caution shortcode
* kubeadm: update the reference docs for 1.13 (#10960)
* docs update to promote TaintBasedEvictions to beta (#10765)
* First Korean l10n work for dev-1.13 (#10719)
* Update outdated l10n(ko) contents (#10689)
fixes#10686
* Translate concepts/overview/what-is-kubernetes in Korean (#10690)
* Translate concepts/overview/what-is-kubernetes in Korean
* Feedback from ClaudiaJKang
* Translate concepts/overview/components in Korean (#10882)
* Translate concepts/overview/components in Korean #10717
* Translate concepts/overview/components in Korean
* Translate concepts/overview/components in Korean
* Apply Korean glossary: 서비스 어카운트
* Translate concepts/overview/kubernetes-api in Korean (#10773)
* Translate concepts/overview/kubernetes-api in Korean
* Applied feedback from ianychoi
* kubeadm: update the configuration docs to v1beta1 (#10959)
* kubeadm: add small v1beta1 related updates (#10988)
* update new feature gates to document (#11295)
* Update dry run feature to beta (#11140)
* kubeadm: add improvements to HA docs (#11094)
* kubeadm: add information and diagrams for HA topologies
* kubeadm: update HA doc with simplified steps
* kubeadm: update HA doc with simplified steps
* edit ha, add new topology topic, reorder by weight
* troubleshoot markdown
* fix more markdown, fix links
* more markdown
* more markdown
* more markdown
* changes after reviewer comments
* add steps about Weave
* update note about stacked topology
* kubeadm: update reference docs
- add section about working with phases under kubeadm-init.md
- update GA / beta status of features
- kubeadm alpha phase was moved to kubeadm init phase
- new commands were added under kubeadm alpha
- included new CoreDNS usage examples
* Generate components and tools reference
* Add generated federation API Reference (#11491)
* Add generated federation API Reference
* Add front matter to federation reference
* Remove whitespace from federation front matter
* Remove more whitespace from federation front matter
* Remove superfluous kubefed reference
* Add frontmatter to generated kubefed reference
* Fix kubefed reference page frontmatter
* Generate kubectl reference docs 1.13 (#11487)
* Generate kubectl reference docs 1.13
* Fix links in kubectl reference
* Add 1.13 API reference (#11489)
* Update config.toml (#11486)
* Update config.toml
Preparing for 1.13 release, updating the config.toml and dropping the 1.8 docs reference.
* update dot releases and docsbranch typo
* adding .Site. to Params.currentUrl (#11503)
see https://github.com/kubernetes/website/pull/11502 for context
* Add 1.13 Release notes (#11499)
2018-12-03 17:21:11 -08:00
2983 changed files with 316433 additions and 64190 deletions
sig-instrumentation: #GH: sig-instrumentation-pr-reviews; e.g. metrics, logging, events
- DirectXMan12
- x13n
- kawych
- brancz
- fabxc
- loburm
- piosz
- fgrzadkowski
sig-multicluster: #GH: sig-multicluster-pr-reviews; e.g. resiliency against availability zone outages; hybrid clouds; spanning multiple cloud providers; migration to public clouds
- madhusudancs
- marun
- jianhuiz
- shashidharatd
- nikhiljindal
- quinton-hoole
- mwielgus
- csbell
sig-network: #Team: Network; GH: sig-network-pr-reviews; e.g. Ingress, Network Policies, Services
- bowei
- caseydavenport
- danwinship
- dcbw
- dnardo
- freehan
- mrhohn
- nicksardo
- thockin
sig-node: #Team: Node; GH: sig-node-pr-reviews; e.g. Containers, Docker, Images, OS images, Pods, Registries
Herzlich willkommen! Dieses Repository enthält alle Assets, die zur Erstellung der [Kubernetes-Website und Dokumentation](https://kubernetes.io/) erforderlich sind. Wir freuen uns sehr, dass Sie dazu beitragen wollen!
## Beiträge zur Dokumentation
Sie können auf die Schaltfläche **Fork** im oberen rechten Bereich des Bildschirms klicken, um eine Kopie dieses Repositorys in Ihrem GitHub-Konto zu erstellen. Diese Kopie wird als *Fork* bezeichnet. Nehmen Sie die gewünschten Änderungen an Ihrem Fork vor. Wenn Sie bereit sind, diese Änderungen an uns zu senden, gehen Sie zu Ihrem Fork und erstellen Sie eine neue Pull-Anforderung, um uns darüber zu informieren.
Sobald Ihre Pull-Anfrage erstellt wurde, übernimmt ein Rezensent von Kubernetes die Verantwortung für klares, umsetzbares Feedback. Als Eigentümer des Pull-Request **liegt es in Ihrer Verantwortung Ihren Pull-Reqest enstsprechend des Feedbacks, dass Sie vom Kubernetes-Reviewer erhalten haben abzuändern.** Beachten Sie auch, dass Sie am Ende mehr als einen Rezensenten von Kubernetes erhalten, der Ihnen Feedback gibt, oder dass Sie Rückmeldungen von einem Rezensenten von Kubernetes erhalten, der sich von demjenigen unterscheidet, der ursprünglich für das Feedback zugewiesen wurde. In einigen Fällen kann es vorkommen, dass einer Ihrer Prüfer bei Bedarf eine technische Überprüfung von einem [Kubernetes Tech-Reviewer](https://github.com/kubernetes/website/wiki/tech-reviewers) anfordert. Reviewer geben ihr Bestes, um zeitnah Feedback zu geben, die Antwortzeiten können jedoch je nach den Umständen variieren.
Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter:
Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein spezielles [Docker](https://docker.com) Image auszuführen, das den statischen Site-Generator [Hugo](https://gohugo.io) enthält.
> Unter Windows benötigen Sie einige weitere Tools, die Sie mit [Chocolatey](https://chocolatey.org) installieren können.
`choco install make`
> Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Site-lokal-mit-Hugo-ausführen).
Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstellen Sie das Docker-Image `kubernetes-hugo` lokal:
```bash
make docker-image
```
Nachdem das Image erstellt wurde, können Sie die Site lokal ausführen:
```bash
make docker-serve
```
Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
## Die Site lokal mit Hugo ausführen
Hugo-Installationsanweisungen finden Sie in der [offiziellen Hugo-Dokumentation](https://gohugo.io/getting-started/installing/). Stellen Sie sicher, dass Sie die Hugo-Version installieren, die in der Umgebungsvariablen `HUGO_VERSION` in der Datei [`netlify.toml`](netlify.toml#L9) angegeben ist.
So führen Sie die Site lokal aus, wenn Sie Hugo installiert haben:
```bash
make serve
```
Dadurch wird der lokale Hugo-Server an Port 1313 gestartet. Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
## Community, Diskussion, Beteiligung und Unterstützung
Erfahren Sie auf der [Community-Seite](http://kubernetes.io/community/) wie Sie mit der Kubernetes-Community interagieren können.
Sie können die Betreuer dieses Projekts unter folgender Adresse erreichen:
Este repositorio contiene todos los recursos necesarios para construir el [sitio web de Kubernetes y su documentación](https://kubernetes.io/). ¡Estamos encantados de que quiera contribuir!
## Contribuyendo con la documentación
Puede hacer clic en el botón **Fork** situado en la esquina superior derecha de la pantalla para crear una copia de este repositorio en su cuenta de GitHub. A ese tipo de copia se le llama **Fork** (bifurcación) y le permite editar el contenido del repositorio en su copia personal. Realice los cambios que quiera en su **fork** y, cuando esté listo para enviarnos esos cambios, vaya a **fork** en repositorio en su GitHub y cree una nueva **pull request** para que tengamos constancia de la propuesta de cambios.
Una vez la **pull request** ha sido creada, un revisor de Kubernetes asumirá la responsabilidad de proporcionar comentarios claros y prácticos sobre como continuar. Como propietario de la PR, **es su responsabilidad modificar la pull request para abordar los comentarios proporcionados por el revisor de Kubernetes.** Tenga en cuenta que algunas veces puede terminar teniendo más de un revisor de Kubernetes participando en la revisión, por lo que es posible que reciba comentarios de más revisores a parte del asignado originalmente en la creación de la **pull request**. Además, en algunas ocasiones, es posible que uno de sus revisores solicite una revisión técnica por parte de un [revisor técnico de Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) si lo considera necesario.
Los revisores harán todo lo posible para proporcionar toda la información necesaria para que la **pull request** siga adelante en un tiempo razonable, pero este tiempo de respuesta puede variar según las circunstancias.
Para obtener más información sobre cómo contribuir a la documentación de Kubernetes, puede consultar:
* [Empezando a contribuir](https://kubernetes.io/docs/contribute/start/)
* [Visualizando sus cambios en su entorno local](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Guía de estilo de la documentación](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Traduciendo la documentación de Kubernetes](https://kubernetes.io/docs/contribute/localization/)
## Levantando el sitio web kubernetes.io en su entorno local con Docker
El método recomendado para levantar una copia local del sitio web kubernetes.io es utilizando la imagen de [Docker](https://docker.com) que incluye el generador de sitios estáticos [Hugo](https://gohugo.io).
> Para Windows, algunas otras herramientas como Make son necesarias. Puede instalarlas utilizando el gestor [Chocolatey](https://chocolatey.org). `choco install make` o siguiendo las instrucciones de [Make for Windows](http://gnuwin32.sourceforge.net/packages/make.htm).
> Si prefiere levantar el sitio web sin utilizar **Docker**, puede seguir las instrucciones disponibles en la sección [Levantando kubernetes.io en local con Hugo](#levantando-kubernetes.io-en-local-con-hugo).
Una vez tenga Docker [configurado en su máquina](https://www.docker.com/get-started), puede construir la imagen de Docker `kubernetes-hugo` localmente ejecutando el siguiente comando en la raíz del repositorio:
```bash
make docker-image
```
Una vez tenga la imagen construida, puede levantar el sitio web ejecutando:
```bash
make docker-serve
```
Abra su navegador y visite http://localhost:1313 para acceder a su copia local del sitio. A medida que vaya haciendo cambios en el código fuente, Hugo irá actualizando la página y forzará la actualización en el navegador.
## Levantando kubernetes.io en local con Hugo
Revise la [documentación oficial de Hugo](https://gohugo.io/getting-started/installing/) para obtener las instrucciones de instalación en su sistema operativo. Asegúrese de instalar la versión de Hugo especificada en la variable de entorno `HUGO_VERSION` del fichero [`netlify.toml`](netlify.toml#L9).
Para levantar el sitio localmente una vez Hugo está instalado en su sistema, puede ejecutar el siguiente comando:
```bash
make serve
```
Este comando levantará un servidor de Hugo en el puerto **1313** al que podrá acceder visitando http://localhost:1313 y dónde podrá visualizar su copia local del sitio web. A medida que vaya haciendo cambios en el código fuente, Hugo irá actualizando la página y forzará la actualización en el navegador.
## Comunidad, discusión, contribuir y soporte
Aprenda como participar en la comunidad de Kubernetes visitando la [página de comunidad](http://kubernetes.io/community/).
Puede ponerse en contacto con los mantenedores de este proyecto en:
Ce référentiel contient toutes les informations nécessaires à la construction du site web et de la documentation de Kubernetes.
Nous sommes très heureux que vous vouliez contribuer !
## Contribuer à la rédaction des docs
Vous pouvez cliquer sur le bouton **Fork** en haut à droite de l'écran pour créer une copie de ce dépôt dans votre compte GitHub.
Cette copie s'appelle un *fork*.
Faites tous les changements que vous voulez dans votre fork, et quand vous êtes prêt à nous envoyer ces changements, allez dans votre fork et créez une nouvelle pull request pour nous le faire savoir.
Une fois votre pull request créée, un examinateur de Kubernetes se chargera de vous fournir une revue claire et exploitable.
En tant que propriétaire de la pull request, **il est de votre responsabilité de modifier votre pull request pour tenir compte des commentaires qui vous ont été fournis par l'examinateur de Kubernetes.**
Notez également que vous pourriez vous retrouver avec plus d'un examinateur de Kubernetes pour vous fournir des commentaires ou vous pourriez finir par recevoir des commentaires d'un autre examinateur que celui qui vous a été initialement affecté pour vous fournir ces commentaires.
De plus, dans certains cas, l'un de vos examinateur peut demander un examen technique à un [examinateur technique de Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) au besoin.
Les examinateurs feront de leur mieux pour fournir une revue rapidement, mais le temps de réponse peut varier selon les circonstances.
Pour plus d'informations sur la contribution à la documentation Kubernetes, voir :
* [Commencez à contribuer](https://kubernetes.io/docs/contribute/start/)
* [Apperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Utilisation des modèles de page](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Traduction de la documentation Kubernetes](https://kubernetes.io/docs/contribute/localization/)
## Exécuter le site localement en utilisant Docker
La façon recommandée d'exécuter le site web Kubernetes localement est d'utiliser une image spécialisée [Docker](https://docker.com) qui inclut le générateur de site statique [Hugo](https://gohugo.io).
> Si vous êtes sous Windows, vous aurez besoin de quelques outils supplémentaires que vous pouvez installer avec [Chocolatey](https://chocolatey.org). `choco install install make`
> Si vous préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#running-the-site-locally-using-hugo) ci-dessous.
Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement:
```bash
make docker-image
```
Une fois l'image construite, vous pouvez exécuter le site localement :
```bash
make docker-serve
```
Ouvrez votre navigateur à l'adresse: http://localhost:1313 pour voir le site.
Lorsque vous apportez des modifications aux fichiers sources, Hugo met à jour le site et force le navigateur à rafraîchir la page.
## Exécuter le site localement en utilisant Hugo
Voir la [documentation officielle Hugo](https://gohugo.io/getting-started/installing/) pour les instructions d'installation Hugo.
Assurez-vous d'installer la version Hugo spécifiée par la variable d'environnement `HUGO_VERSION` dans le fichier [`netlify.toml`](netlify.toml#L9).
Pour exécuter le site localement lorsque vous avez Hugo installé :
```bash
make serve
```
Le serveur Hugo local démarrera sur le port 1313.
Ouvrez votre navigateur à l'adresse: http://localhost:1313 pour voir le site.
Lorsque vous apportez des modifications aux fichiers sources, Hugo met à jour le site et force le navigateur à rafraîchir la page.
## Communauté, discussion, contribution et assistance
Apprenez comment vous engager avec la communauté Kubernetes sur la [page communauté](http://kubernetes.io/community/).
Vous pouvez joindre les responsables de ce projet à l'adresse :
स्वागत हे! इस रिपॉजिटरी में [कुबरनेट्स वेबसाइट और दस्तावेज](https://kubernetes.io/) बनाने के लिए आवश्यक सभी संपत्तियां हैं। हम बहुत खुश हैं कि आप योगदान करना चाहते हैं!
## डॉक्स में योगदान देना
आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**
यह भी ध्यान दें कि आप एक से अधिक कुबरनेट्स समीक्षक आपको प्रतिक्रिया प्रदान कर सकते हैं या आप एक कुबरनेट्स समीक्षक से प्रतिक्रिया प्राप्त कर सकते हैं जो मूल रूप से आपको प्रतिक्रिया प्रदान करने के लिए दिए गए एक से भिन्न है। इसके अलावा, कुछ मामलों में, आपका एक समीक्षक जरूरत पड़ने पर [कुबेरनेट्स टेक समीक्षक](https://github.com/kubernetes/website/wiki/Tech-reviewers) से तकनीकी समीक्षा प्राप्त कर सकता है। समीक्षक समय पर प्रतिक्रिया देने के लिए पूरी कोशिश करेंगे, लेकिन परिस्थितियों के आधार पर प्रतिक्रिया समय अलग-अलग हो सकता है।
कुबरनेट्स प्रलेखन में योगदान देने के बारे में अधिक जानकारी के लिए, देखें:
* [योगदान देना शुरू करें](https://kubernetes.io/docs/contribute/start/)
* [परिवर्तनों को अंतिम चरण में लेजाएं](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
कुबरनेट्स वेबसाइट को स्थानीय रूप से चलाने के लिए अनुशंसित तरीका एक विशेष [डॉकर](https://docker.com) image को चलाना है, जिसमें [Hugo](https://gohugo.io) स्टेटिक साइट जनरेटर शामिल है।
> यदि आप विंडोज पर हैं, तो आपको कुछ और टूल्स की आवश्यकता होगी जिन्हें आप [Chocolatey](https://chocolatey.org) के साथ इंस्टॉल कर सकते हैं।
> यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे Hugo का उपयोग करके स्थानीय रूप से साइट चलाना देखें।
यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#running-the-site-locally-using-hugo) का तरीका देखें।
यदि आप [डॉकर](https://www.docker.com/get-started) चला रहे हैं, तो स्थानीय रूप से `कुबेरनेट्स-ह्यूगो` Docker image बनाएँ:
```bash
make docker-image
```
एक बार image बन जाने के बाद, आप साइट को स्थानीय रूप से चला सकते हैं:
```bash
make docker-serve
```
साइट देखने के लिए अपने browser को `http://localhost:1313` पर खोलें। जैसा कि आप source फ़ाइलों में परिवर्तन करते हैं, Hugo साइट को अपडेट करता है और browser को refresh करने पर मजबूर करता है।
## Hugo का उपयोग करते हुए स्थानीय रूप से साइट चलाना
Hugo निर्देशों के लिए [आधिकारिक Hugo प्रलेखन](https://gohugo.io/getting-started/installing/) देखें। [`Netlify.toml`](netlify.toml#L9) फ़ाइल में `HUGO_VERSION` environment variable द्वारा निर्दिष्ट Hugo version को install करना सुनिश्चित करें।
जब आप Hugo को install करते हैं तो स्थानीय रूप से साइट को चलाने के लिए:
```bash
make serve
```
यह पोर्ट `1313` पर Hugo सर्वर को शुरू करेगा। साइट देखने के लिए अपने browser को `http://localhost:1313` पर खोलें। जैसा कि आप source फ़ाइलों में परिवर्तन करते हैं, Hugo साइट को अपडेट करता है और एक browser को refresh करने पर मजबूर करता है।
## समुदाय, चर्चा, योगदान और समर्थन
[Community page](http://kubernetes.io/community/) पर कुबरनेट्स समुदाय के साथ जुड़ना सीखें।
कुबरनेट्स समुदाय में भागीदारी [कुबरनेट्स कोड ओफ़ कंडक्ट](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/hi.md) द्वारा शासित है.
## धन्यवाद!
कुबरनेट्स सामुदायिक भागीदारी पर पनपती है, और हम वास्तव में हमारी साइट और हमारे प्रलेखन में आपके योगदान की सराहना करते हैं!
कुबरनेट्स आपकी भागीदारी पर निर्भर है, और हम हमारी साइट और प्रलेखन में आपके योगदान का मान करते हैं!
Selamat datang! Repositori ini merupakan wadah bagi semua komponen yang dibutuhkan untuk membuat [dokumentasi Kubernetes](https://kubernetes.io/). Kami merasa sangat senang apabila kamu berminat untuk menjadi kontributor!
## Kontribusi pada dokumentasi
Pertama, kamu dapat menekan tombol **Fork** yang berada pada bagian atas layar, untuk menyalin repositori pada akun Github-mu. Salinan ini disebut sebagai **fork**. Kamu dapat menambahkan konten pada **fork** yang kamu miliki, setelah kamu merasa cukup untuk menambahkan konten yang kamu miliki dan ingin memberikan konten tersebut pada kami, kamu dapat melihat **fork** yang telah kamu buat dan membuat **pull request** untuk memberi tahu kami bahwa kamu ingin menambahkan konten yang telah kamu buat.
Setelah kamu membuat sebuah **pull request**, seorang **reviewer** akan memberikan masukan terhadap konten yang kamu sediakan serta beberapa hal yang dapat kamu lakukan apabila perbaikan diperlukan terhadap konten yang telah kamu sediakan. Sebagai seorang yang membuat **pull request**, **sudah menjadi kewajiban kamu untuk melakukan modifikasi terhadap konten yang kamu berikan sesuai dengan masukan yang diberikan oleh seorang reviewer Kubernetes**. Perlu kamu ketahui bahwa kamu dapat saja memiliki lebih dari satu orang **reviewer Kubernetes** atau dalam kasus kamu bisa saja mendapatkan **reviewer Kubernetes** yang berbeda dengan **reviewer Kubernetes** awal yang ditugaskan untuk memberikan masukan terhadap konten yang kamu sediakan. Selain itu, seorang **reviewer Kubernetes** bisa saja meminta masukan teknis dari [reviewer teknis Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) jika diperlukan.
Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat melihat tautan di bawah ini:
* [Petunjuk Melakukan Kontribusi](https://kubernetes.io/docs/contribute/start/)
* [Melakukan Tahap Staging pada Konten Dokumentasi yang telah Kamu Sediakan](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Petunjuk Menggunakan Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Petunjuk untuk Documentation Style](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Petunjuk untuk Melakukan Lokalisasi Dokumentasi Kubernetes](https://kubernetes.io/docs/contribute/localization/)
## Menjalankan Dokumentasi Kubernetes pada Mesin Lokal Kamu
Petunjuk yang disarankan untuk menjalankan Dokumentasi Kubernetes pada mesin lokal kamus adalah dengan menggunakan [Docker](https://docker.com) **image** yang memiliki **package** [Hugo](https://gohugo.io), **Hugo** sendiri merupakan generator website statis.
> Jika kamu menggunakan Windows, kamu mungkin membutuhkan beberapa langkah tambahan untuk melakukan instalasi perangkat lunak yang dibutuhkan. Instalasi ini dapat dilakukan dengan menggunakan [Chocolatey](https://chocolatey.org). `choco install make`
> Jika kamu ingin menjalankan **website** tanpa menggunakan **Docker**, kamu dapat melihat tautan berikut [Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo](#petunjuk-untuk-menjalankan-website-pada-mesin-lokal-denga-menggunakan-hugo) di bagian bawah.
Jika kamu sudah memiliki **Docker** [yang sudah dapat digunakan](https://www.docker.com/get-started), kamu dapat melakukan **build**`kubernetes-hugo`**Docker image** secara lokal:
```bash
make docker-image
```
Setelah **image** berhasil di-**build**, kamu dapat menjalankan website tersebut pada mesin lokal-mu:
```bash
make docker-serve
```
Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi. Selama kamu melakukan penambahan konten, **Hugo** akan secara otomatis melakukan perubahan terhadap laman dokumentasi apabila **browser** melakukan proses **refresh**.
## Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo
Kamu dapat melihat [dokumentasi resmi Hugo](https://gohugo.io/getting-started/installing/) untuk mengetahui langkah yang diperlukan untuk melakukan instalasi **Hugo**. Pastikan kamu melakukan instalasi versi **Hugo** sesuai dengan versi yang tersedia pada **environment variable**`HUGO_VERSION` pada **file**[`netlify.toml`](netlify.toml#L9).
Untuk menjalankan laman pada mesin lokal setelah instalasi **Hugo**, kamu dapat menjalankan perintah berikut:
```bash
make serve
```
Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi. Selama kamu melakukan penambahan konten, **Hugo** akan secara otomatis melakukan perubahan terhadap laman dokumentasi apabila **browser** melakukan proses **refresh**.
## Komunitas, Diskusi, Kontribusi, dan Bantuan
Kamu dapat belajar bagaimana tata cara untuk ikut terlibat dalam komunitas Kubernetes melalui [laman komunitas](http://kubernetes.io/community/).
Kamu dapat berinteraksi dengan **maintainers** project ini melalui:
환영합니다! 이 저장소는 쿠버네티스 웹사이트 및 문서화를 만드는 데 필요로 하는 모든 asset에 대한 공간을 제공합니다. 여러분이 기여를 원한다는 사실에 매우 기쁩니다!
## 문서에 기여하기
이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
여러분의 풀 리퀘스트가 생생된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다. 뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
`README.md` 번역 및 한국어 기여자를 위한 보다 자세한 가이드를 [한국어 README](README-ko.md) 페이지 혹은 [쿠버네티스 문서 한글화 가이드](https://kubernetes.io/ko/docs/contribute/localization_ko/)에서 살펴봅니다.
쿠버네티스 웹사이트를 로컬에서 실행하기 위한 추천하는 방식은 [Hugo](https://gohugo.io) 정적 사이트 생성기를 포함하는 특별한 [도커](https://docker.com) 이미지를 실행하는 것입니다.
> Windows에서 실행하는 경우, [Chocolatey](https://chocolatey.org)로 설치할 수 있는 명명 추가 도구를 필요로 할 것입니다. `choco install make`
> 도커를 사용하지 않고 웹사이트를 로컬에서 실행하기를 선호하는 경우에는, 아래 [Hugo를 사용한 로컬 사이트 실행하기](#hugo를-사용한-로컬-사이트-실행하기)를 살펴봅니다.
도커 [동작 및 실행](https://www.docker.com/get-started) 환경이 있는 경우, 로컬에서 `kubernetes-hugo` 도커 이미지를 빌드 합니다:
```bash
make docker-image
```
해당 이미지가 빌드된 이후, 사이트를 로컬에서 실행할 수 있습니다:
```bash
make docker-serve
```
브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
## Hugo를 사용한 로컬 사이트 실행하기
Hugo 설치 안내를 위해서는 [공식 Hugo 문서화](https://gohugo.io/getting-started/installing/)를 살펴봅니다. [`netlify.toml`](netlify.toml#L9) 파일에 있는 `HUGO_VERSION` 환경 변수에서 지정된 Hugo 버전이 설치되었는지를 확인합니다.
Hugo가 설치되었을 때 로컬에서 사이트를 실행하기 위해 (다음을 실행합니다):
```bash
make serve
```
이를 통해 로컬 Hugo 서버를 1313번 포트에 시작합니다. 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
## 감사합니다!
쿠버네티스는 커뮤니티 참여와 함께 생존하며, 우리는 사이트 및 문서화에 대한 여러분의 컨트리뷰션에 대해 정말 감사하게 생각합니다!
Bem vindos! Este repositório abriga todos os recursos necessários para criar o [site e documentação do Kubernetes](https://kubernetes.io/). Estamos muito satisfeitos por você querer contribuir!
## Contribuindo com os documentos
Você pode clicar no botão **Fork** na área superior direita da tela para criar uma cópia desse repositório na sua conta do GitHub. Esta cópia é chamada de *fork*. Faça as alterações desejadas no seu fork e, quando estiver pronto para enviar as alterações para nós, vá até o fork e crie uma nova solicitação de pull para nos informar sobre isso.
Depois que seu **pull request** for criada, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para abordar o feedback que foi fornecido a você pelo revisor do Kubernetes.** Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um revisor do Kubernetes que é diferente daquele originalmente designado para lhe fornecer feedback. Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor de tecnologia Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedback em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.
Para mais informações sobre como contribuir com a documentação do Kubernetes, consulte:
* [Comece a contribuir](https://kubernetes.io/docs/contribute/start/)
* [Preparando suas alterações na documentação](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Usando Modelos de Página](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Guia de Estilo da Documentação](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Localizando documentação do Kubernetes](https://kubernetes.io/docs/contribute/localization/)
Você pode contactar os mantenedores da localização em Português em:
* Felipe ([GitHub - @femrtnz](https://github.com/femrtnz))
A maneira recomendada de executar o site do Kubernetes localmente é executar uma imagem especializada do [Docker](https://docker.com) que inclui o gerador de site estático [Hugo](https://gohugo.io).
> Se você está rodando no Windows, você precisará de mais algumas ferramentas que você pode instalar com o [Chocolatey](https://chocolatey.org). `choco install make`
> Se você preferir executar o site localmente sem o Docker, consulte [Executando o site localmente usando o Hugo](#executando-o-site-localmente-usando-o-hugo) abaixo.
Se você tiver o Docker [em funcionamento](https://www.docker.com/get-started), crie a imagem do Docker do `kubernetes-hugo` localmente:
```bash
make docker-image
```
Depois que a imagem foi criada, você pode executar o site localmente:
```bash
make docker-serve
```
Abra seu navegador para http://localhost:1313 para visualizar o site. Conforme você faz alterações nos arquivos de origem, Hugo atualiza o site e força a atualização do navegador.
## Executando o site localmente usando o Hugo
Veja a [documentação oficial do Hugo](https://gohugo.io/getting-started/installing/) para instruções de instalação do Hugo. Certifique-se de instalar a versão do Hugo especificada pela variável de ambiente `HUGO_VERSION` no arquivo [`netlify.toml`](netlify.toml#L9).
Para executar o site localmente quando você tiver o Hugo instalado:
```bash
make serve
```
Isso iniciará o servidor Hugo local na porta 1313. Abra o navegador para http://localhost:1313 para visualizar o site. Conforme você faz alterações nos arquivos de origem, Hugo atualiza o site e força a atualização do navegador.
## Comunidade, discussão, contribuição e apoio
Aprenda a se envolver com a comunidade do Kubernetes na [página da comunidade](http://kubernetes.io/community/).
Você pode falar com os mantenedores deste projeto:
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.
As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.
Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.
Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static website generator.
Once the image has been built, you can run the website locally:
-->
一旦创建了镜像,您就可以在本地运行网站了:
```bash
make docker-serve
```
<!--
Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
To run the website locally when you have Hugo installed:
-->
安装 Hugo 后,在本地运行网站:
```bash
make serve
```
<!--
This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
-->
这将在 1313 端口上启动本地 Hugo 服务器。打开浏览器访问 http://localhost:1313 查看网站。当您对源文件进行更改时,Hugo 会更新网站并强制刷新浏览器。
<!--
## Community, discussion, contribution, and support
-->
## 社区、讨论、贡献和支持
<!--
Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
Welcome! This repository houses all of the assets required to build the Kuberneteswebsite and documentation. We're very pleased that you want to contribute!
Welcome! This repository houses all of the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!
## Contributing to the docs
You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.** Also note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one originally assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.** Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
For more information about contributing to the Kubernetes documentation, see:
@@ -16,13 +19,23 @@ For more information about contributing to the Kubernetes documentation, see:
The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static site generator.
## Running the website locally using Docker
The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static website generator.
> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
> If you'd prefer to run the website locally without Docker, see [Running the site locally using Hugo](#running-the-site-locally-using-hugo) below.
> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
@@ -30,26 +43,39 @@ If you have Docker [up and running](https://www.docker.com/get-started), build t
make docker-image
```
Once the image has been built, you can run the site locally:
Once the image has been built, you can run the website locally:
```bash
make docker-serve
```
Open up your browser to http://localhost:1313 to view the site. As you make changes to the source files, Hugo updates the site and forces a browser refresh.
Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
## Running the site locally using Hugo
## Running the website locally using Hugo
See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
To run the site locally when you have Hugo installed:
To run the website locally when you have Hugo installed:
```bash
make serve
```
This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the site. As you make changes to the source files, Hugo updates the site and forces a browser refresh.
This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
## Community, discussion, contribution, and support
Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
# param for displaying an announcement block on every page; see PR #16210
announcement=false
# announcement_message is only displayed when announcement = true; update with your specific message
announcement_message="The Kubernetes Documentation team would like your feedback! Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."
abstract: "Automatisierte Bereitstellung, Skalierung und Verwaltung von Containern"
cid: home
---
{{<deprecationwarning>}}
{{<blocks/sectionid="oceanNodes">}}
{{% blocks/feature image="flower" %}}
### [Kubernetes (K8s)]({{<relref"/docs/concepts/overview/what-is-kubernetes">}}) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.
Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google] (http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community.
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}
#### Planet Scale
Kubernetes basiert auf denselben Prinzipien, die es Google ermöglichen, Milliarden von Containern pro Woche zu betreiben.
{{% /blocks/feature %}}
{{% blocks/feature image="blocks" %}}
#### Never Outgrow
Unabhängig davon, ob Sie lokal testen oder ein globales Unternehmen betreiben, die Flexibilität von Kubernetes wächst mit Ihnen, um Ihre Anwendungen konsistent und einfach bereitzustellen, unabhängig von der Komplexität Ihrer Anforderungen.
{{% /blocks/feature %}}
{{% blocks/feature image="suitcase" %}}
#### Run Anywhere
Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor Ort, Hybrid oder Public Cloud zu nutzen. So können Sie Workloads mühelos dorthin verschieben, wo es Ihnen wichtig ist.
<ahref="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019"buttonid="desktopKCButton">KubeCon vom 18-21. November 2019 in San Diego</a>
<br>
<br>
<br>
<br>
<ahref="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/"buttonid="desktopKCButton">KubeCon vom 30 März-2 Apr. 2020 in Amsterdam</a>
<p>Lesen Sie die neuesten Nachrichten über Kubernetes und das Containeruniversum im Allgemeinen. Erhalten Sie druckfrisch die neuesten Tutorials und technische Anleitungen.</p>
<h3>Die Gewissheit, dass Kubernetes überall und für alle gut funktioniert.</h3>
<p>Verbinden Sie sich mit der Kubernetes-Community in unserem <ahref="http://slack.k8s.io/">Slack Kanal</a>, <ahref="https://discuss.kubernetes.io/">Diskussionsforum</a>, oder beteiligen Sie sich an der <ahref="https://groups.google.com/forum/#!forum/kubernetes-dev"> Kubernetes-dev-Google-Gruppe</a>. Eine wöchentlichesCommunity-Meeting findet per Videokonferenz statt, um den Stand der Dinge zu diskutieren, folgen Sie
<ahref="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">diesen Anweisungen</a> für Informationen wie Sie teilnehmen können.</p>
<p>Sie können Kubernetes auch auf der ganzen Welt über unsere
<ahref="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> und der
<p>Haben Sie ein besonderes Interesse daran, wie Kubernetes mit einer anderen Technologie arbeitet? Werfen Sie einen Blick auf unsere kontinuierlich wachsende
<ahref="https://git.k8s.io/community/sig-list.md">Listen von SIGs</a>, von AWS und Openstack bis hin zu Big Data und Skalierbarkeit, es gibt einen Platz für Sie, an dem Sie mitwirken können, und Anweisungen zur Gründung einer neuen SIG finden, wenn Ihr besonderes Interesse (noch) nicht abgedeckt ist.
</p>
<p>Als Mitglied der Kubernetes-Community sind Sie herzlich eingeladen, an allen SIG-Treffen teilzunehmen, die Sie interessieren. Eine Registrierung ist nicht erforderlich.</p>
</div>
<divclass="content">
<h3>Verhaltensregeln</h3>
<p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <ahref="code-of-conduct/">Verhaltenskodex</a>
in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
bitte an das <ahref="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a><ahref="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>. Ihre Anonymität wird geschützt.
</p>
</div>
</main>
</section>
<sectionid="talkToUs">
<main>
<h3>Talk to Us!</h3>
<h4>Wir würden uns freuen, von Ihnen zu hören, wie Sie Kubernetes verwenden<br>und was wir tun können, um es besser zu machen.</h4>
Im Abschnitt Konzepte erfahren Sie mehr über die Teile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Darstellung Ihres Clusters verwendet, und Sie erhalten ein tieferes Verständnis der Funktionsweise von Kubernetes.
{{% /capture %}}
{{% capture body %}}
## Überblick
Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben:
welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Containerimages sie verwenden, die Anzahl der Replikate, welche Netzwerk- und Festplattenressourcen Sie zur Verfügung stellen möchten, und vieles mehr. Sie legen den gewünschten Status fest, indem Sie Objekte mithilfe der Kubernetes-API erstellen, normalerweise über die Befehlszeilenschnittstelle `kubectl`. Sie können die Kubernetes-API auch direkt verwenden, um mit dem Cluster zu interagieren und den gewünschten Status festzulegen oder zu ändern.
Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
* Der **Kubernetes Master** bestehet aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind:[kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
* Jeder einzelne Node in Ihrem Cluster, welcher nicht der Master ist, führt zwei Prozesse aus:
* **[kubelet](/docs/admin/kubelet/)**, das mit dem Kubernetes Master kommuniziert.
* **[kube-proxy](/docs/admin/kube-proxy/)**, ein Netzwerk-Proxy, der die Netzwerkdienste von Kubernetes auf jedem Node darstellt.
## Kubernetes Objects
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: implementierte containerisierte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
Die grundlegenden Objekte von Kubernetes umfassen:
Darüber hinaus enthält Kubernetes eine Reihe von Abstraktionen auf höherer Ebene, die als Controller bezeichnet werden. Controller bauen auf den Basisobjekten auf und bieten zusätzliche Funktionen und Komfortfunktionen. Sie beinhalten:
Die verschiedenen Teile der Kubernetes-Steuerungsebene (Control Plane), wie der Kubernetes Master- und der Kubelet-Prozess, bestimmen, wie Kubernetes mit Ihrem Cluster kommuniziert. Das Control Plane führt ein Inventar aller Kubernetes-Objekte im System und führt fortlaufende Steuerkreise aus, um den Status dieser Objekte zu verwalten. Zu jeder Zeit reagieren die Steuerkreise des Control Plane auf Änderungen im Cluster und arbeiten daran, dass der tatsächliche Status aller Objekte im System mit dem gewünschten Status, den Sie definiert haben, übereinstimmt.
Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, geben Sie einen neuen gewünschten Status für das System an. Das Kubernetes Control Plane zeichnet die Objekterstellung auf und führt Ihre Anweisungen aus, indem es die erforderlichen Anwendungen startet und sie für auf den Cluster-Nodes plant--Dadurch wird der tatsächliche Status des Clusters an den gewünschten Status angepasst.
### Kubernetes Master
Der Kubernetes-Master ist für die Aufrechterhaltung des gewünschten Status für Ihren Cluster verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.
> Der "Master" bezieht sich auf eine Reihe von Prozessen, die den Clusterstatus verwalten. Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden um Verfügbarkeit und Redundanz zu erhöhen.
### Kubernetes Nodes
Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf denen Ihre Anwendungen und Cloud-Workflows ausgeführt werden. Der Kubernetes-Master steuert jeden Master. Sie werden selten direkt mit Nodes interagieren.
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
Die Absicht besteht darin, Benutzern die Möglichkeit zu geben, ihre Installation so anzupassen, dass die Netzwerkkonfiguration so abgesichert wird, dass der Cluster in einem nicht vertrauenswürdigen Netzwerk (oder mit vollständig öffentlichen IP-Adressen eines Cloud-Providers) ausgeführt werden kann.
{{% /capture %}}
{{% capture body %}}
## Cluster zum Master
Alle Kommunikationspfade vom Cluster zum Master enden beim Apiserver (keine der anderen Master-Komponenten ist dafür ausgelegt, Remote-Services verfügbar zu machen).
In einem typischen Setup ist der Apiserver so konfiguriert, dass er Remote-Verbindungen an einem sicheren HTTPS-Port (443) mit einer oder mehreren Formen der [Clientauthentifizierung](/docs/reference/access-authn-authz/authentication/) überwacht.
Eine oder mehrere Formene von [Autorisierung](/docs/reference/access-authn-authz/authorization/) sollte aktiviert sein, insbesondere wenn [anonyme Anfragen](/docs/reference/access-authn-authz/authentication/#anonymous-requests) oder [Service Account Tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) aktiviert sind.
Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfigurirert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
Beispielsweise bei einer gewöhnlichen GKE-Konfiguration enstprechen die dem kubelet zur Verfügung gestellten Client-Anmeldeinformationen eines Client-Zertifikats.
Lesen Sie über [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) zur automatisierten Bereitstellung von kubelet-Client-Zertifikaten.
Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziert wird.
Der `kubernetes`-Dienst (in allen Namespaces) ist mit einer virtuellen IP-Adresse konfiguriert, die (über den Kube-Proxy) an den HTTPS-Endpunkt auf dem Apiserver umgeleitet wird.
Die Master-Komponenten kommunizieren auch über den sicheren Port mit dem Cluster-Apiserver.
Der Standardbetriebsmodus für Verbindungen vom Cluster (Knoten und Pods, die auf den Knoten ausgeführt werden) zum Master ist daher standardmäßig gesichert und kann über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
## Master zum Cluster
Es gibt zwei primäre Kommunikationspfade vom Master (Apiserver) zum Cluster.
Der erste ist vom Apiserver bis zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
Der zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
### Apiserver zum kubelet
Die Verbindungen vom Apiserver zum Kubelet werden verwendet für:
* Abrufen von Protokollen für Pods.
* Verbinden (durch kubectl) mit laufenden Pods.
* Bereitstellung der Portweiterleitungsfunktion des kubelet.
Diese Verbindungen enden am HTTPS-Endpunkt des kubelet.
Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelet nicht, was die Verbindung von angreifbar für Man-in-the-Middle-Angriffe macht, und ist es ist daher **unsicher** wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelet verwendet wird.
Wenn dies nicht möglich ist, verwenden Sie [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
zwischen dem Apiserver und kubelet, falls erforderlich, um eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.
Ausserdem sollte, [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) sollte aktiviert sein, um die kubelet-API zu sichern.
### Apiserver zu Nodes, Pods und Services
Die Verbindungen vom Apiserver zu einem Node, Pod oder Dienst verwenden standardmäßig einfache HTTP-Verbindungen und werden daher weder authentifiziert noch verschlüsselt.
Sie können über eine sichere HTTPS-Verbindung ausgeführt werden, indem dem Node, dem Pod oder dem Servicenamen in der API-URL "https:" vorangestellt wird. Das vom HTTPS-Endpunkt bereitgestellte Zertifikat wird jedoch nicht überprüft, und es werden keine Clientanmeldeinformationen bereitgestellt. Die Verbindung wird zwar verschlüsselt, garantiert jedoch keine Integrität.
Diese Verbindungen **sind derzeit nicht sicher** innerhalb von nicht vertrauenswürdigen und/oder öffentlichen Netzen.
### SSH Tunnels
Kubernetes unterstützt SSH-Tunnel zum Schutz der Kommunikationspfade von Master -> Cluster.
In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Nodem im Cluster (Verbindung mit dem SSH-Server, der Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
Dieser Tunnel stellt sicher, dass der Datenverkehr nicht außerhalb des Netzwerks sichtbar ist, in dem die Knoten ausgeführt werden.
SSH-Tunnel sind derzeit nicht mehr unterstützt. Sie sollten sie also nicht verwenden, es sei denn, Sie wissen, was Sie tun. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node
kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält
die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
und wird von den Master-Komponenten verwaltet.
Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
Weitere Informationen finden Sie im Abschnitt Kubernetes Node in der Architekturdesign-Dokumentation.
{{% /capture %}}
{{% capture body %}}
## Node Status
Der Status eines Nodes enthält folgende Informationen:
* [Adressen](#adressen)
* [Zustand](#zustand)
* [Kapazität](#kapazität)
* [Info](#info)
Jeder Abschnitt wird folgend detailliert beschrieben.
### Adressen
Die Verwendung dieser Felder hängt von Ihrem Cloud-Anbieter oder der Bare-Metal-Konfiguration ab.
* HostName: Der vom Kernel des Nodes gemeldete Hostname. Kann mit dem kubelet-Parameter `--hostname-override` überschrieben werden.
* ExternalIP: In der Regel die IP-Adresse des Nodes, die extern geroutet werden kann (von außerhalb des Clusters verfügbar).
* InternalIP: In der Regel die IP-Adresse des Nodes, die nur innerhalb des Clusters routbar ist.
### Zustand
Das `conditions` Feld beschreibt den Zustand, aller `Running` Nodes.
| Node Condition | Beschreibung |
|----------------|-------------|
| `OutOfDisk` | `True` wenn auf dem Node nicht genügend freier Speicherplatz zum Hinzufügen neuer Pods vorhanden ist, andernfalls `False` |
| `Ready` | `True` wenn der Node in einem guten Zustand und bereit ist Pods aufzunehmen, `False` wenn der Node nicht in einem guten Zustand ist und nicht bereit ist Pods aufzunehmeb, und `Unknown` wenn der Node-Controller seit der letzten `node-monitor-grace-period` nichts von dem Node gehört hat (Die Standardeinstellung beträgt 40 Sekunden) |
| `MemoryPressure` | `True` wenn der verfügbare Speicher des Nodes niedrig ist; Andernfalls`False` |
| `PIDPressure` | `True` wenn zu viele Prozesse auf dem Node vorhanden sind; Andernfalls`False` |
| `DiskPressure` | `True` wenn die Festplattenkapazität niedrig ist. Andernfalls `False` |
| `NetworkUnavailable` | `True` wenn das Netzwerk für den Node nicht korrekt konfiguriert ist, andernfalls `False` |
Der Zustand eines Nodes wird als JSON-Objekt dargestellt. Die folgende Antwort beschreibt beispielsweise einen fehlerfreien Node.
```json
"conditions":[
{
"type":"Ready",
"status":"True"
}
]
```
Wenn der Status der `Ready`-Bedingung `Unknown` oder `False` länger als der `pod-eviction-timeout` bleibt, wird ein Parameter an den [kube-controller-manager](/docs/admin/kube-controller-manager/) übergeben und alle Pods auf dem Node werden vom Node Controller gelöscht.
Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**.
In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren.
Die Entscheidung, die Pods zu löschen, kann dem Kublet erst mitgeteilt werden, wenn die Kommunikation mit dem Apiserver wiederhergestellt ist.
In der Zwischenzeit können Pods, deren Löschen geplant ist, weiterhin auf dem unzugänglichen Node laufen.
In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.
Das Löschen des Kubernetes-Nodeobjekts bewirkt, dass alle auf dem Node ausgeführten Pod-Objekte gelöscht und deren Namen freigegeben werden.
In Version 1.12 wurde die Funktion `TaintNodesByCondition` als Beta-Version eingeführt, die es dem Node-Lebenszyklus-Controller ermöglicht, automatisch [Markierungen](/docs/concepts/configuration/taint-and-toleration/) (*taints* in Englisch) zu erstellen, die Bedingungen darstellen.
Ebenso ignoriert der Scheduler die Bedingungen, wenn er einen Node berücksichtigt; stattdessen betrachtet er die Markierungen (taints) des Nodes und die Toleranzen eines Pod.
Anwender können jetzt zwischen dem alten Scheduling-Modell und einem neuen, flexibleren Scheduling-Modell wählen.
Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant.
Aber ein Pod, die die Taints eines bestimmten Node toleriert, kann auf diesem Node geplant werden.
{{< caution >}}
Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit,
in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht.
Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl
der Pods erhöhen, die erfolgreich geplant, aber vom Kubelet abgelehnt werden.
{{< /caution >}}
### Kapazität
Beschreibt die auf dem Node verfügbaren Ressourcen: CPU, Speicher und die maximale
Anzahl der Pods, die auf dem Node ausgeführt werden können.
### Info
Allgemeine Informationen zum Node, z. B. Kernelversion, Kubernetes-Version
(kubelet- und kube-Proxy-Version), Docker-Version (falls verwendet), Betriebssystemname.
Die Informationen werden von Kubelet vom Node gesammelt.
## Management
Im Gegensatz zu [Pods](/docs/concepts/workloads/pods/pod/) und [Services](/docs/concepts/services-networking/service/),
ein Node wird nicht von Kubernetes erstellt: Er wird extern von Cloud-Anbietern wie Google Compute Engine erstellt oder ist in Ihrem Pool physischer oder virtueller Maschinen vorhanden.
Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt.
Nach der Erstellung überprüft Kubernetes, ob der Node gültig ist oder nicht.
Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
```json
{
"kind":"Node",
"apiVersion":"v1",
"metadata":{
"name":"10.240.79.157",
"labels":{
"name":"my-first-k8s-node"
}
}
}
```
Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
Wenn der Node gültig ist, d.h. wenn alle notwendigen Dienste ausgeführt werden, ist er berechtigt, einen Pod auszuführen.
Andernfalls wird er für alle Clusteraktivitäten ignoriert, bis er gültig wird.
{{< note >}}
Kubernetes behält das Objekt für den ungültigen Node und prüft ständig seine Gültigkeit.
Sie müssen das Node-Objekt explizit löschen, um diesen Prozess zu stoppen.
{{< /note >}}
Aktuell gibt es drei Komponenten, die mit dem Kubernetes Node-Interface interagieren: Node Controller, Kubelet und Kubectl.
### Node Controller
Der Node Controller ist eine Kubernetes-Master-Komponente, die verschiedene Aspekte von Nodes verwaltet.
Der Node Controller hat mehrere Rollen im Leben eines Nodes.
Der erste ist die Zuordnung eines CIDR-Blocks zu dem Node, wenn er registriert ist (sofern die CIDR-Zuweisung aktiviert ist).
Die zweite ist, die interne Node-Liste des Node Controllers mit der Liste der verfügbaren Computer des Cloud-Anbieters auf dem neuesten Stand zu halten.
Wenn ein Node in einer Cloud-Umgebung ausgeführt wird und sich in einem schlechten Zustand befindet, fragt der Node Controller den Cloud-Anbieter, ob die virtuelle Maschine für diesen Node noch verfügbar ist. Wenn nicht, löscht der Node Controller den Node aus seiner Node-Liste.
Der dritte ist die Überwachung des Zustands der Nodes. Der Node Controller ist dafür verantwortlich,
die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen).
Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-period` Sekunden.
In Versionen von Kubernetes vor 1.13 ist NodeStatus der Herzschlag des Nodes.
Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird.
Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt.
Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes).
Da Node Leases viel lastärmer sind als NodeStatus, macht diese Funktion den Node Herzschlag sowohl in Bezug auf Skalierbarkeit als auch auf die Leistung deutlich effizienter.
In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat).
Ab 1.4 betrachtet der Node-Controller den Zustand aller Nodes im Cluster, wenn er eine Entscheidung über die Enterfung eines Pods trifft.
In den meisten Fällen begrenzt der Node-Controller die Entfernungsrate auf `--node-eviction-rate` (Standard 0,1) pro Sekunde, was bedeutet, dass er die Pods nicht von mehr als einem Node pro 10 Sekunden entfernt.
Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird.
Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse).
Wenn der Anteil der ungesunden Nodes mindestens `--unhealthy-zone-threshold` (Standard 0,55) beträgt, wird die Entfernungsrate reduziert:
Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert.
Der Grund, warum diese Richtlinien pro Verfügbarkeitszone implementiert werden, liegt darin, dass eine Verfügbarkeitszone vom Master unerreichbar werden könnte, während die anderen verbunden bleiben. Wenn Ihr Cluster nicht mehrere Verfügbarkeitszonen von Cloud-Anbietern umfasst, gibt es nur eine Verfügbarkeitszone (den gesamten Cluster).
Ein wichtiger Grund für die Verteilung Ihrer Nodes auf Verfügbarkeitszonen ist, dass die Arbeitsbelastung auf gesunde Zonen verlagert werden kann, wenn eine ganze Zone ausfällt.
Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.
Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster).
In diesem Fall geht der Node-Controller davon aus, dass es ein Problem mit der Master-Konnektivität gibt und stoppt alle Entfernungen, bis die Verbindung wiederhergestellt ist.
Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren.
Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen.
Siehe [diese Dokumentation](/docs/concepts/configuration/taint-and-toleration/) für Details über `NoExecute` Taints und die Alpha-Funktion.
Ab Version 1.8 kann der Node-Controller für die Erzeugung von Taints, die Node Bedingungen darstellen, verantwortlich gemacht werden. Dies ist eine Alpha-Funktion der Version 1.8.
### Selbstregistrierung von Nodes
Wenn das Kubelet-Flag `--register-node` aktiv ist (Standard), versucht das Kubelet, sich beim API-Server zu registrieren. Dies ist das bevorzugte Muster, das von den meisten Distributionen verwendet wird.
Zur Selbstregistrierung wird das kubelet mit den folgenden Optionen gestartet:
-`--kubeconfig` - Pfad zu Anmeldeinformationen, um sich beim Apiserver zu authentifizieren.
-`--cloud-provider` - Wie man sich mit einem Cloud-Anbieter unterhält, um Metadaten über sich selbst zu lesen.
-`--register-node` - Automatisch beim API-Server registrieren.
-`--register-with-taints` - Registrieren Sie den Node mit der angegebenen Taints-Liste (Kommagetrennt `<key>=<value>:<effect>`). No-op wenn `register-node` false ist.
-`--node-ip` - IP-Adresse des Nodes.
-`--node-labels` - Labels, die bei der Registrierung des Nodes im Cluster hinzugefügt werden sollen (Beachten Sie die Richlinien des [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
-`--node-status-update-frequency` - Gibt an, wie oft kubelet den Nodestatus an den Master übermittelt.
Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) aktiviert sind,
dürfen kubelets nur ihre eigene Node-Ressource erstellen / ändern.
#### Manuelle Nodeverwaltung
Ein Cluster-Administrator kann Nodeobjekte erstellen und ändern.
Wenn der Administrator Nodeobjekte manuell erstellen möchte, setzen Sie das kubelet Flag `--register-node=false`.
Der Administrator kann Node-Ressourcen ändern (unabhängig von der Einstellung von `--register-node`).
Zu den Änderungen gehören das Setzen von Labels und das Markieren des Nodes.
Labels auf Nodes können in Verbindung mit node selectors auf Pods verwendet werden, um die Planung zu steuern, z.B. um einen Pod so zu beschränken, dass er nur auf einer Teilmenge der Nodes ausgeführt werden darf.
Das Markieren eines Nodes als nicht geplant, verhindert, dass neue Pods für diesen Node geplant werden. Dies hat jedoch keine Auswirkungen auf vorhandene Pods auf dem Node.
Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw.
Um beispielsweise einen Node als nicht geplant zu markieren, führen Sie den folgenden Befehl aus:
```shell
kubectl cordon $NODENAME
```
{{< note >}}
Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node.
Dies setzt voraus, dass Daemons auf dem Computer verbleiben, auch wenn während der Vorbereitung eines Neustarts keine Anwendungen mehr vorhanden sind.
{{< /note >}}
### Node Kapazität
Die Kapazität des Nodes (Anzahl der CPU und Speichermenge) ist Teil des Nodeobjekts.
Normalerweise registrieren sich Nodes selbst und melden ihre Kapazität beim Erstellen des Nodeobjekts.
Sofern Sie [Manuelle Nodeverwaltung](#Manuelle-Nodeverwaltung) betreiben, müssen Sie die Node Kapazität setzen, wenn Sie einen Node hinzufügen.
Der Kubernetes-Scheduler stellt sicher, dass für alle Pods auf einem Nodes genügend Ressourcen vorhanden sind.
Er prüft, dass die Summe der Requests von Containern auf dem Node nicht größer ist als die Kapazität des Nodes.
Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen.
Wenn Sie Ressourcen explizit für Nicht-Pod-Prozesse reservieren möchten, folgen Sie diesem Lernprogramm um [Ressourcen für Systemdaemons zu reservieren](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
## API-Objekt
Node ist eine Top-Level-Ressource in der Kubernetes-REST-API. Weitere Details zum API-Objekt finden Sie unter:
[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
In einem Cluster sind die Controller Manager Metriken unter `http://localhost:10252/metrics` auf dem Host verfügbar, auf dem der Controller Manager läuft.
Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.
In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen.
Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert.
{{% /capture %}}
{{% capture body %}}
## Proxies
Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes begegnen können:
1. Der [kubectl Proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- läuft auf dem Desktop eines Benutzers oder in einem Pod
- Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
- Client zu Proxy verwendet HTTP
- Proxy zu API Server verwendet HTTPS
- lokalisiert den API Server
- fügt Authentifizierungs-Header hinzu
1. Der [API Server Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- ist eine Bastion, die in den API Server eingebaut ist
- verbindet einen Benutzer außerhalb des Clusters mit Cluster IPs, die sonst möglicherweise nicht erreichbar wären
- läuft im API Server Prozess
- Client zu Proxy verwendet HTTPS (oder http, wenn API Server so konfiguriert ist)
- Proxy zum Ziel kann HTTP oder HTTPS verwenden, der Proxy wählt dies unter Verwendung der verfügbaren Informationen aus
- kann verwendet werden, um einen Knoten, Pod oder Service zu erreichen
- führt einen Lastausgleich durch um einen Service zu erreichen, wenn dieser verwendet wird
1. Der [kube Proxy](/docs/concepts/services-networking/service/#ips-and-vips):
- läuft auf jedem Knoten
- Proxy unterstüzt UDP, TCP und SCTP
- versteht kein HTTP
- stellt Lastausgleich zur Verfügung
- wird nur zum erreichen von Services verwendet
1. Ein Proxy/Load-balancer vor dem API Server:
- Existenz und Implementierung variieren von Cluster zu Cluster (z.B. nginx)
- sitzt zwischen allen Clients und einem oder mehreren API Servern
- fungiert als Load Balancer, wenn es mehrere API Server gibt
1. Cloud Load Balancer für externe Services:
- wird von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer)
- werden automatisch erstellt, wenn der Kubernetes Service den Typ `LoadBalancer` hat
- unterstützt normalerweiße nur UDP/TCP
- Die SCTP-Unterstützung hängt von der Load Balancer Implementierung des Cloud Providers ab
- die Implementierung variiert je nach Cloud Anbieter
Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten beiden Typen kümmern. Der Cluster Administrator stellt in der Regel sicher, dass die letztgenannten Typen korrekt eingerichtet sind.
## Anforderung an Umleitungen
Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet.
Stellen Sie auch sicher [einen Eintrag im Inhaltsverzeichnis](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) für Ihr neues Dokument zu erstellen.
{{< /note >}}
Diese Seite erklärt ...
{{% /capture %}}
{{% capture body %}}
## Verstehen ...
Kubernetes bietet ...
## Verwenden ...
Benutzen Sie ...
{{% /capture %}}
{{% capture whatsnext %}}
**[Optionaler Bereich]**
* Lernen Sie mehr über [ein neues Thema schreiben](/docs/home/contribute/write-new-topic/).
* Besuchen Sie [Seitenvorlagen verwenden - Konzeptvorlage](/docs/home/contribute/page-templates/#concept_template) wie Sie diese Vorlage verwenden.
In diesem Dokument werden die verschiedenen binären Komponenten beschrieben, die zur Bereitstellung eines funktionsfähigen Kubernetes-Clusters erforderlich sind.
{{% /capture %}}
{{% capture body %}}
## Master-Komponenten
Master-Komponenten stellen die Steuerungsebene des Clusters bereit. Master-Komponenten treffen globale Entscheidungen über den Cluster (z. B. Zeitplanung) und das Erkennen und Reagieren auf Clusterereignisse (Starten eines neuen Pods, wenn das `replicas`-Feld eines Replikationscontrollers nicht zufriedenstellend ist).
Master-Komponenten können auf jedem Computer im Cluster ausgeführt werden.
Der Einfachheit halber starten Setup-Skripts normalerweise alle Master-Komponenten auf demselben Computer, und es werden keine Benutzercontainer auf diesem Computer ausgeführt.
Lesen Sie [Cluster mit hoher Verfügbarkeit erstellen](/docs/admin/high-availability/) für ein Beispiel für ein Multi-Master-VM-Setup.
* Node Controller: Verantwortlich für das Erkennen und Reagieren, wenn Nodes ausfallen.
* Replication Controller: Verantwortlich für die Aufrechterhaltung der korrekten Anzahl von Pods für jedes Replikationscontrollerobjekt im System.
* Endpoints Controller: Füllt das Endpoints-Objekt aus (d.h. verbindet Services & Pods).
* Service Account & Token Controllers: Erstellt Standardkonten und API-Zugriffstoken für neue Namespaces.
### cloud-controller-manager
[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) führt Controller aus, die mit den entsprechenden Cloud-Anbietern interagieren.
Der cloud-controller-manager ist eine Alpha-Funktion, die in Kubernetes Version 1.6 eingeführt wurde.
cloud-controller-manager führt nur Cloud-Provider-spezifische Controller-Schleifen aus. Sie müssen diese Controller-Schleifen im Cube-Controller-Manager deaktivieren. Sie können die Controller-Schleifen deaktivieren, indem Sie beim Starten des kube-controller-manager das Flag `--cloud-provider` auf `external` setzen.
cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln.
In früheren Versionen war der Kerncode von Kubernetes für die Funktionalität von Cloud-Provider-spezifischem Code abhängig.
In zukünftigen Versionen sollte der für Cloud-Anbieter spezifische Code vom Cloud-Anbieter selbst verwaltet und mit dem Cloud-Controller-Manager verknüpft werden, während Kubernetes ausgeführt wird.
Die folgenden Controller haben Abhängigkeiten von Cloud-Anbietern:
* Node Controller: Zum Überprüfen, ob ein Node in der Cloud beim Cloud-Anbieter gelöscht wurde, nachdem er nicht mehr reagiert
* Route Controller: Zum Einrichten von Routen in der zugrunde liegenden Cloud-Infrastruktur
* Service Controller: Zum Erstellen, Aktualisieren und Löschen von Lastverteilern von Cloud-Anbietern
* Volume Controller: Zum Erstellen, Verbinden und Bereitstellen von Volumes und zur Interaktion mit dem Cloud-Provider zum Orchestrieren von Volumes
## Node-Komponenten
Node Komponenten werden auf jedem Knoten ausgeführt, halten laufende Pods aufrecht und stellen die Kubernetes-Laufzeitumgebung bereit.
[kube-proxy](/docs/admin/kube-proxy/) ermöglicht die Kubernetes Service-Abstraktion, indem die Netzwerkregeln auf dem Host beibehalten und die Verbindungsweiterleitung durchgeführt wird.
### Container Runtime
Die Containerlaufzeit ist die Software, die für das Ausführen von Containern verantwortlich ist.
Kubernetes unterstützt mehrere Laufzeiten: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) und jede Implementierung des [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
## Addons
Addons sind Pods und Dienste, die Clusterfunktionen implementieren. Die Pods können verwaltet werden
durch Deployments, ReplicationControllers, und so wieter.
Namespace-Addon-Objekte werden im Namespace `kube-system` erstellt.
Ausgewählte Addons werden unten beschrieben. Eine erweiterte Liste verfügbarer Addons finden Sie unter [Addons](/docs/concepts/cluster-administration/addons/).
### DNS
Während die anderen Addons nicht unbedingt erforderlich sind, sollte [cluster DNS](/docs/concepts/services-networking/dns-pod-service/) in allen Kubernetes-Cluster vorhanden sein, da viele Beispiele davon abhängen.
Cluster-DNS ist neben anderen DNS-Servern in Ihrer Umgebung ein DNS-Server, der DNS-Einträge für Kubernetes-Dienste bereitstellt.
Von Kubernetes gestartete Container schließen diesen DNS-Server automatisch in ihre DNS-Suchen ein.
### Web UI (Dashboard)
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) ist eine allgemeine, webbasierte Benutzeroberfläche für Kubernetes-Cluster. Benutzer können damit Anwendungen, die im Cluster ausgeführt werden, sowie den Cluster selbst verwalten und Fehler beheben.
### Container Resource Monitoring
[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) zeichnet generische Zeitreihenmessdaten zu Containern in einer zentralen Datenbank auf und stellt eine Benutzeroberfläche zum Durchsuchen dieser Daten bereit.
### Cluster-level Logging
Ein [Cluster-level logging](/docs/concepts/cluster-administration/logging/) Mechanismus ist für das Speichern von Containerprotokollen in einem zentralen Protokollspeicher mit Such- / Browsing-Schnittstelle verantwortlich.
Kubernetes ist eine portable, erweiterbare Open-Source-Plattform zur Verwaltung von
containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
Es hat einen großes, schnell wachsendes Ökosystem. Kubernetes Dienstleistungen, Support und Tools sind weit verbreitet.
Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten
Erfahrung auf, die Google mit der Ausführung von Produktions-Workloads in großem Maßstab hat, kombiniert mit den besten Ideen und Praktiken der Community.
## Warum brauche ich Kubernetes und was kann ich damit tun?
Kubernetes hat eine Reihe von Funktionen. Es kann gesehen werden als:
- eine Containerplattform
- eine Microservices-Plattform
- eine portable Cloud-Plattform
und vieles mehr.
Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur
im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität
von Infrastructure as a Service (IaaS) und ermöglicht die Portabilität zwischen Infrastrukturanbietern.
## Wie ist Kubernetes eine Plattform?
Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien,
die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden,
um die Entwicklungsgeschwindigkeit zu beschleunigen.
Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab.
Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools
konzipiert, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu erleichtern.
[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen
nach Belieben zu organisieren. [Anmerkungen](/docs/concepts/overview/working-with-objects/annotations/) ermöglichen es Benutzern,
Ressourcen mit benutzerdefinierten Informationen zu versehen, um ihre Arbeitsabläufe zu vereinfachen und eine einfache Möglichkeit
für Managementtools zu bieten, den Status von Kontrollpunkten zu ermitteln.
Darüber hinaus basiert die [Kubernetes-Steuerungsebene](/docs/concepts/overview/components/) auf den gleichen APIs,
die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigenen Controller, wie z.B.
[Scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), mit
ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
universellen [Kommandozeilen-Tool](/docs/user-guide/kubectl-overview/) angesprochen werden können.
Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.
## Was Kubernetes nicht ist
Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
Wahlmöglichkeiten und Flexibilität der Benutzer, wo es wichtig ist.
Kubernetes:
* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab,
eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless,
stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt
werden kann, sollte sie auf Kubernetes hervorragend laufen.
* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht.
Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch
Unternehmenskulturen und -präferenzen sowie technische Anforderungen bestimmt.
* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse),
Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder
Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
portable Mechanismen wie den Open Service Broker angesprochen werden.
* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
Es bietet eine deklarative API, die von beliebigen Formen deklarativer Spezifikationen angesprochen werden kann.
* Bietet keine umfassenden Systeme zur Maschinenkonfiguration, Wartung, Verwaltung oder Selbstheilung.
Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung
überflüssig macht. Die technische Definition von *Orchestrierung* ist die Ausführung eines
definierten Workflows: zuerst A, dann B, dann C. Im Gegensatz dazu besteht Kubernetes aus einer Reihe von unabhängigen,
komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben.
Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich.
Das Ergebnis ist ein System, das einfacher zu bedienen und leistungsfähiger, robuster, widerstandsfähiger und erweiterbar ist.
## Warum Container?
Sie suchen nach Gründen, warum Sie Container verwenden sollten?
Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe!
Jeder kann seinen Beitrag leisten, unabhängig davon ob Sie neu im Projekt sind oder schon lange dabei sind, und ob Sie sich als
Entwickler, Endbenutzer oder einfach jemanden, der es einfach nicht aushält, Tippfehler zu sehen sehen.
Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/).
Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gestaltungshandbuch](/docs/contribute/style/style-guide/).
{{% capture body %}}
## Arten von Mitwirkenden
- Ein _Member_ der Kubernetes Organisation, hat die [CLA unterzeichnet](/docs/contribute/start#sign-the-cla)
und etwas Zeit und Energie zum Projekt beigetragen.
Siehe [Community-Mitgliedschaft](https://github.com/kubernetes/community/blob/master/community-membership.md) für spezifische Kriterien bezüglich der Mitgliedschaft.
- Ein SIG Docs _Reviewer_ ist ein Mitglied der Kubernetes-Organisation, das Interesse an der Überprüfung von
Dokumentationsanfragen geäußert hat und von einem SIG Docs Approver zu der entsprechenden Github-Gruppe
und den `OWNERS`-Dateien im Github-Repository hinzugefügt wurde.
- Ein SIG Docs _approver_ ist ein Mitglied mit gutem Ansehen, das sich kontinuierlich für das Projekt engagiert hat.
Ein Approver kann Pull-Anfragen zusammenführen und Inhalte im Namen der Kubernetes-Organisation veröffentlichen.
Approver können SIG Docs auch in der größeren Kubernetes-Community vertreten. Einige der Aufgaben eines SIG Docs Approvers, wie z.B. die Koordination einer Freigabe, erfordern einen erheblichen Zeitaufwand.
## Möglichkeiten, einen Beitrag zu leisten
Diese Liste ist in Funktionen unterteilt, die jeder tun kann, die von Mitgliedern der Kubernetes-Organisation durchgeführt werden können, und Dinge, die ein höheres Maß an Zugriff und eine bessere Kenntnis der SIG Docs-Prozesse erfordern. Wenn Sie im Laufe der Zeit einen konstanten Beitrag leisten, können Sie einige der bereits getroffenen Tools und organisatorischen Entscheidungen nachvollziehen.
Dies ist keine vollständige Liste von Möglichkeiten, wie Sie zur Kubernetes-Dokumentation beitragen können, aber sie sollte Ihnen den Einstieg erleichtern.
- [Jeder](/docs/contribute/start/)
- Umsetzbare issues eröffnen
- [Member](/docs/contribute/start/)
- Vorhandene Dokumente verbessern
- Ideen zur Verbesserung in [Slack](http://slack.k8s.io/) oder der [SIG docs Mailingliste](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) einbringen
- Den Zugriff auf Dokumente verbessern
- Unverbindliches Feedback zu PRs verfassen
- Enen Blogbeitrag oder eine Fallstudie schreiben
- [Reviewer](/docs/contribute/intermediate/)
- Neue Funktionen dokumentieren
- Auswerten und Kategorisieren von Problemen
- PRs überprüfen
- Diagramme, Grafiken und einbettbare Screencasts / Videos erstellen
- Lokalisierung
- Als Vertreter von docs zu anderen Repos beitragen
- An Benutzer gerichtete Zeichenfolgen im Code bearbeiten
- Code-Kommentare verbessern, Godoc
- [Approver](/docs/contribute/advanced/)
- Veröffentlichen Sie den Inhalt von Members, indem Sie PRs genehmigen und zusammenführen
- Nehmen Sie als Docs-Vertreter an einem Kubernetes-Release-Team teil
- Verbesserungsvorschläge für den Style Guide
- Verbesserungsvorschläge für Dokumentprüfungen vorschlagen
- Vorschläge für Verbesserungen der Kubernetes-Website oder anderer Tools
<p>Erfahren Sie, wie Sie Kubernetes mit Konzept-, Tutorial- und Referenzdokumentation verwenden. Sie können sogar zur <a href="/editdocs/" data-auto-burger-exclude>mithelfen und zur Dokumentation beitragen</a>!</p>
overview: >
Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Das Open-Source Project wird von der Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>) gehosted.
cards:
- name: concepts
title: "Verstehen Sie die Grundlagen"
description: "Lernen Sie Kubernetes und seine grundlegenden Konzepte kennen."
button: "Konzepte lernen"
button_path: "/docs/concepts"
- name: tutorials
title: "Kubernetes ausprobieren"
description: "Folgen Sie den Tutorials, um zu erfahren, wie Sie Anwendungen in Kubernetes bereitstellen."
button: "Tutorials entdecken"
button_path: "/docs/tutorials"
- name: setup
title: "Richten Sie einen Cluster ein"
description: "Holen Sie sich Kubernetes basierend auf Ihren Ressourcen und Bedürfnissen."
button: "Kubernetes Einrichten"
button_path: "/docs/setup"
- name: tasks
title: "Erfahren Sie, wie Sie Kubernetes verwenden"
description: "Informieren Sie sich über häufig verwendete Aufgaben und deren Durchführung anhand einer kurzen Abfolge von Schritten."
button: "Tasks anzeigen"
button_path: "/docs/tasks"
- name: reference
title: Referenzinformationen nachschlagen
description: Durchsuchen Sie Terminologie, Befehlszeilensyntax, API-Ressourcentypen und Dokumentation zum Setup-Tool.
button: Referenz anzeigen
button_path: /docs/reference
- name: contribute
title: Tragen Sie zur Dokumentation bei
description: Jeder kann einen Beitrag leisten, unabhängig davon, ob Sie neu in dem Projekt oder schon lange dabei sind.
button: Zur Dokumentation beitragen
button_path: /docs/contribute
- name: download
title: Kubernetes Herunterladen
description: Wenn Sie Kubernetes installieren oder auf die neueste Version aktualisieren, lesen Sie die aktuellen Versionshinweise.
- name: about
title: Über die Dokumentation
description: Diese Website enthält Dokumentation zu den aktuellen und vorherigen 4 Versionen von Kubernetes.
* [kubectl](/docs/user-guide/kubectl-overview) - Haupt-CLI-Tool zum Ausführen von Befehlen und zum Verwalten von Kubernetes-Clustern.
* [JSONPath](/docs/user-guide/jsonpath/) - Syntax-Anleitung zur Verwendung von [JSONPath expressionen](http://goessner.net/articles/JsonPath/) mit kubectl.
* [kubeadm](/docs/admin/kubeadm/) - CLI-Tool zur einfachen Bereitstellung eines sicheren Kubernetes-Clusters.
* [kubefed](/docs/admin/kubefed/) - CLI-Tool zur Verwaltung Ihres Clusterverbunds.
## Konfigurationsreferenz
* [kubelet](/docs/admin/kubelet/) - Der primäre *Node-Agent*, der auf jedem Node ausgeführt wird. Das Kubelet betrachtet eine Reihe von PodSpecs und stellt sicher, dass die beschriebenen Container ordnungsgemäß ausgeführt werden.
* [kube-apiserver](/docs/admin/kube-apiserver/) - REST-API zur Überprüfung und Konfiguration von Daten für API-Objekte wie Pods, Services und Replikationscontroller.
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon, der die mit Kubernetes gelieferten zentralen Regelkreise einbettet.
* [kube-proxy](/docs/admin/kube-proxy/) - Kann einfache TCP/UDP-Stream-Weiterleitung oder Round-Robin-TCP/UDP-Weiterleitung über eine Reihe von Back-Ends durchführen.
* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler, der Verfügbarkeit, Leistung und Kapazität verwaltet.
* [federation-apiserver](/docs/admin/federation-apiserver/) - API-Server für Cluster Föderationen.
* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Daemon, der die zentralen Regelkreise einbindet, die mit der Kubernetes-Föderation ausgeliefert werden.
## Design Dokumentation
Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals).
Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.
aka:
tags:
- architecture
- storage
---
Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.
<!--more-->
Halten Sie immer einen Sicherungsplan für etcds Daten für Ihren Kubernetes-Cluster bereit. Ausführliche Informationen zu etcd finden Sie in der [etcd Dokumentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
aka:
tags:
- architecture
- fundamental
---
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
<!--more-->
Es ist für die horizontale Skalierung konzipiert, d. H. Es skaliert durch die Bereitstellung von mehr Instanzen. Mehr informationen finden Sie unter [Cluster mit hoher Verfügbarkeit erstellen](/docs/admin/high-availability/).
Komponente auf dem Master, auf dem Controller ausgeführt werden.
aka:
tags:
- architecture
- fundamental
---
Komponente auf dem Master, auf dem {{< glossary_tooltip text="controllers" term_id="controller" >}} ausgeführt werden.
<!--more-->
Logisch gesehen ist jeder {{< glossary_tooltip text="controller" term_id="controller" >}} ein separater Prozess, aber zur Vereinfachung der Komplexität werden sie alle zu einer einzigen Binärdatei zusammengefasst und in einem einzigen Prozess ausgeführt.
Komponente auf dem Master, die neu erstellte Pods überwacht, denen kein Node zugewiesen ist. Sie wählt den Node aus, auf dem sie ausgeführt werden sollen.
aka:
tags:
- architecture
---
Komponente auf dem Master, die neu erstellte Pods überwacht, denen kein Node zugewiesen ist. Sie wählt den Node aus, auf dem sie ausgeführt werden sollen.
<!--more-->
Zu den Faktoren, die bei Planungsentscheidungen berücksichtigt werden, zählen individuelle und kollektive Ressourcenanforderungen, Hardware- / Software- / Richtlinieneinschränkungen, Affinitäts- und Anti-Affinitätsspezifikationen, Datenlokalität, Interworkload-Interferenz und Deadlines.
Ein Agent, der auf jedem Node im Cluster ausgeführt wird. Er stellt sicher, dass Container in einem Pod ausgeführt werden.
aka:
tags:
- fundamental
- core-object
---
Ein Agent, der auf jedem Node im Cluster ausgeführt wird. Er stellt sicher, dass Container in einem Pod ausgeführt werden.
<!--more-->
Das Kubelet verwendet eine Reihe von PodSpecs, die über verschiedene Mechanismen bereitgestellt werden, und stellt sicher, dass die in diesen PodSpecs beschriebenen Container ordnungsgemäß ausgeführt werden. Das kubelet verwaltet keine Container, die nicht von Kubernetes erstellt wurden.
Siehe auch: [Kubectl Überblick](/docs/reference/kubectl/overview/) und [JsonPath Dokumentation](/docs/reference/kubectl/jsonpath).
Diese Seite ist eine Übersicht über den Befehl `kubectl`.
{{% /capture %}}
{{% capture body %}}
# kubectl - Spickzettel
## Kubectl Autovervollständigung
### BASH
```bash
source <(kubectl completion bash)# Wenn Sie autocomplete in bash in der aktuellen Shell einrichten, sollte zuerst das bash-completion-Paket installiert werden.
echo"source <(kubectl completion bash)" >> ~/.bashrc # Fügen Sie der Bash-Shell dauerhaft Autocomplete hinzu.
```
Sie können auch ein Abkürzungsalias für `kubectl` verwenden, weleches auch mit Vervollständigung funktioniert:
```bash
aliask=kubectl
complete -F __start_kubectl k
```
### ZSH
```bash
source <(kubectl completion zsh)# Richten Sie Autocomplete in zsh in der aktuellen Shell ein
echo"if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # Fügen Sie der Zsh-Shell dauerhaft Autocomplete hinzu
```
## Kubectl Kontext und Konfiguration
Legen Sie fest, welcher Kubernetes-Cluster mit `kubectl` kommuniziert und dessen Konfiguration ändert. Lesen Sie die Dokumentation [Authentifizierung mit kubeconfig über mehrere Cluster hinweg](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) für ausführliche Informationen zur Konfigurationsdatei.
`apply` verwaltet Anwendungen durch Dateien, die Kubernetes-Ressourcen definieren. Es erstellt und aktualisiert Ressourcen in einem Cluster durch Ausführen von `kubectl apply`. Dies ist die empfohlene Methode zur Verwaltung von Kubernetes-Anwendungen in der Produktion. Lesen Sie die ausführliche [Kubectl Dokumentation](https://kubectl.docs.kubernetes.io) für weitere Informationen.
## Objekte erstellen
Kubernetes Manifeste können in Json oder Yaml definiert werden. Die Dateierweiterungen `.yaml`,
kubectl get events --sort-by=.metadata.creationTimestamp
```
## Ressourcen aktualisieren
Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md) für weitere Informationen), verwenden Sie stattdessen `rollout`.
```bash
kubectl set image deployment/frontend www=image:v2 # Fortlaufende Aktualisierung der "www" Container der "Frontend"-Bereitstellung, Aktualisierung des Images
kubectl rollout undo deployment/frontend # Rollback zur vorherigen Bereitstellung
kubectl rollout status -w deployment/frontend # Beobachten Sie den fortlaufenden Aktualisierungsstatus der "Frontend"-Bereitstellung bis zum Abschluss.
# veraltet ab Version 1.11
kubectl rolling-update frontend-v1 -f frontend-v2.json # (veraltet) Fortlaufendes Update der Pods von Frontend-v1
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (veraltet) Ändern Sie den Namen der Ressource und aktualisieren Sie das Image
kubectl rolling-update frontend --image=image:v2 # (veraltet) Aktualisieren Sie das Pod-Image des Frontends
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (veraltet) Bricht das laufende Rollout ab
cat pod.json | kubectl replace -f - # Ersetzen Sie einen Pod basierend auf der in std übergebenen JSON
# Ersetzen, löschen und Ressource neu erstellen. Dies führt zu einer temprären Unerreichbarkeit des Dienstes.
kubectl replace --force -f ./pod.json
# Erstellen Sie einen Dienst für eien replizierten nginx Webserver, der an Port 80 und in den Containern an Port 8000 lauscht
Bearbeiten Sie eine beliebige API-Ressource in einem Editor.
```bash
kubectl edit svc/docker-registry # Bearbeiten Sie den Dienst docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Verwenden Sie einen alternativen Texteditor
```
## Ressourcen skalieren
```bash
kubectl scale --replicas=3 rs/foo # Skaliert ein Replikat mit dem Namen 'foo' auf 3
kubectl scale --replicas=3 -f foo.yaml # Skaliert eine in "foo.yaml" angegebene Ressource auf 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Wenn die aktuelle Konfiguration der Replikation von mysql 2 ist, skaliert mysql auf 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Skaliert mehrere Replikationscontroller
```
## Ressourcen löschen
```bash
kubectl delete -f ./pod.json # Löscht einen Pod mit dem in pod.json angegebenen Typ und Namen
kubectl delete pod,service baz foo # Löscht Pods und Services mit den gleichen Namen "baz" und "foo"
kubectl delete pods,services -l name=myLabel # Löscht Pods und Services mit dem Label name=myLabel
kubectl delete pods,services -l name=myLabel --include-uninitialized # Löscht Pods und Services, einschließlich nicht initialisierter, mit dem Label name=myLabel
kubectl -n my-ns delete po,svc --all # Löscht alle Pods und Dienste, einschließlich nicht initialisierter, im Namespace my-ns,
kubectl logs my-pod -c my-container --previous # Pod Container-Logdatei für eine vorherige Instantiierung eines Containers ausgeben (stdout, multi-container case)
Liste aller unterstützten Ressourcentypen mit ihren Kurzbezeichnungen, der [API-Gruppe](/docs/concepts/overview/kubernetes-api/#api-groups), unabhängig davon ob sie im Namespace liegen, und der [Art](/docs/concepts/overview/working-with-objects/kubernetes-objects):
```bash
kubectl api-resources
```
Andere Operationen zum Erkunden von API-Ressourcen:
```bash
kubectl api-resources --namespaced=true# Alle Ressourcen im Namespace
kubectl api-resources --namespaced=false# Alle nicht im Namespace befindlichen Ressourcen
kubectl api-resources -o name # Alle Ressourcen mit einfacher Ausgabe (nur der Ressourcenname)
kubectl api-resources -o wide # Alle Ressourcen mit erweiterter Ausgabe (aka "Wide")
kubectl api-resources --verbs=list,get # Alle Ressourcen, die "list" und "get" Verben unterstützen anfordern
kubectl api-resources --api-group=extensions # Alle Ressourcen in der API-Gruppe "extensions"
```
### Ausgabe formatieren
Um Details in einem bestimmten Format an Ihr Terminalfenster auszugeben, können Sie entweder das `-o` oder `--output` Flag zu einem unterstützten `kubectl` Befehl anhängens.
Ausgabeformat | Beschreibung
--------------| -----------
`-o=custom-columns=<spec>` | Ausgabe einer Tabelle mit einer durch Kommas getrennten Liste benutzerdefinierter Spalten
`-o=custom-columns-file=<dateiname>` | Drucken Sie eine Tabelle mit der benutzerdefinierten Spaltenvorlage in der `<dateiname>` Datei
`-o=json` | Ausgabe eines JSON-formatierten API-Objekts
`-o=jsonpath=<template>` | Ausgabe der in einem [jsonpath](/docs/reference/kubectl/jsonpath)-Ausdruck definierten Felder
`-o=jsonpath-file=<dateiname>` | Ausgabe der in einem [jsonpath](/docs/reference/kubectl/jsonpath)-Ausdruck definierten Felder in der `<dateiname>` Datei
`-o=name` | Ausgabe von nur dem Ressourcennamen und nichts anderes
`-o=wide` | Ausgabe im Klartextformat mit zusätzlichen Informationen. Bei Pods ist der Node-Name enthalten
`-o=yaml` | Gibt ein YAML-formatiertes API-Objekt aus
### Kubectl Ausgabe Ausführlichkeit und Debugging
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
Ausführlichkeit | Beschreibung
--------------| -----------
`--v=0` | Allgemein nützlich, damit dies für den Bediener IMMER sichtbar ist.
`--v=1` | Eine vernünftige Standardprotokollebene, wenn Sie keine Ausführlichkeit wünschen.
`--v=2` | Nützliche Informationen zum stabilen Status des Dienstes und wichtige Protokollnachrichten, die möglicherweise zu erheblichen Änderungen im System führen. Dies ist die empfohlene Standardprotokollebene für die meisten Systeme.
`--v=3` | Erweiterte Informationen zu Änderungen.
`--v=4` | Debug-Level-Ausführlichkeit.
`--v=6` | Angeforderte Ressourcen anzeigen
`--v=7` | HTTP-Anforderungsheader anzeigen
`--v=8` | HTTP-Anforderungsinhalt anzeigen
`--v=9` | HTTP-Anforderungsinhalt anzeigen, ohne den Inhalt zu kürzen.
{{% /capture %}}
{{% capture whatsnext %}}
* Lernen Sie mehr im [Überblick auf kubectl](/docs/reference/kubectl/overview/).
* Erkunden Sie [kubectl](/docs/reference/kubectl/kubectl/) Optionen.
* Und ebenfalls die [kubectl Nutzungskonventionen](/docs/reference/kubectl/conventions/) um zu verstehen, wie man es in wiederverwendbaren Skripten verwendet.
* Entdecken Sie mehr Community [kubectl Spickzettel](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem Kubernetes System helfen.
{{% /capture %}}
{{% capture body %}}
## Kubectl
[`kubectl`](/docs/tasks/tools/install-kubectl/) ist ein Kommandozeilenprogramm für Kubernetes. Es steuert den Kubernetes Clustermanager.
## Kubeadm
[`kubeadm`](/docs/setup/independent/install-kubeadm/) ist ein Kommandozeilenprogramm zur einfachen Bereitstellung eines sicheren Kubernetes-Clusters auf physischen oder Cloud-Servern oder virtuellen Maschinen (derzeit in alpha).
## Kubefed
[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) ist ein Kommandozeilenprogramm um Ihnen bei der Verwaltung Ihrer Verbundcluster zu helfen.
## Minikube
[`minikube`](/docs/tasks/tools/install-minikube/) ist ein Tool, das es Ihnen einfach macht, einen Kubernetes-Cluster mit einem einzigen Knoten lokal auf Ihrer Workstation für Entwicklungs- und Testzwecke auszuführen.
## Dashboard
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), die webbasierte Benutzeroberfläche von Kubernetes ermöglicht es Ihnen containerisierte Anwendungen in einem Kubernetes-Cluster bereitzustellen Fehler zu beheben und den Cluster und seine Ressourcen selbst zu verwalten.
## Helm
[`Kubernetes Helm`](https://github.com/kubernetes/helm) ist ein Tool zur Verwaltung von Paketen mit vorkonfigurierten Kubernetes-Ressourcen, auch bekannt als Kubernetes charts.
Verwenden Sie Helm um:
* Beliebte Software verpackt als Kubernetes charts zu finden und zu verwenden
* Ihre eigenen Applikationen als Kubernetes charts zu teilen
* Reproduzierbare Builds Ihrer Kubernetes Anwendungen zu erstellen
* Intelligenten Verwaltung von Ihren Kubernetes manifest files
* Verwalten von Versionen von Helm Paketen
## Kompose
[`Kompose`](https://github.com/kubernetes-incubator/kompose) ist ein Tool, das Docker Compose Benutzern hilft, nach Kubernetes zu wechseln.
Verwenden Sie Kompose um:
* Ein Docker Compose Datei in Kubernetes Objekte zu übersetzen
* Von Ihrer lokalen Docker Entwicklung auf eine Kubernetes verwaltete Entwicklung zu wechseln
* v1 oder v2 Docker Compose `yaml` Dateien oder [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) zu konvertieren
Auf dieser Seite finden Sie die Lösung, die Ihren Anforderungen am besten entspricht.
Die Entscheidung, wo Kubernetes ausgeführt wird, hängt davon ab, welche Ressourcen Sie zur Verfügung haben und wie viel Flexibilität Sie benötigen.
Sie können Kubernetes fast überall ausführen, von Ihrem Laptop über VMs bei einem Cloud-Anbieter bis hin zu Bare-Metal-Servern.
Sie können einen vollständig verwalteten Cluster einrichten, indem Sie einen einzelnen Befehl ausführen oder einen eigenen benutzerdefinierten Cluster auf Ihren Bare-Metal-Servern erstellen.
{{% /capture %}}
{{% capture body %}}
## Lösungen für lokale Maschinen
Eine lokale Lösung ist eine einfache Möglichkeit, mit Kubernetes anzufangen.
Sie können Kubernetes-Cluster erstellen und testen, ohne sich Gedanken über den Verbrauch von Cloud-Ressourcen und -Kontingenten machen zu müssen.
Sie sollten eine lokale Lösung auswählen, wenn Sie:
* Zum ausprobieren oder wenn Sie etwas über Kubernetes lernen möchten
* Cluster lokal entwickeln und testen
Wählen Sie eine [lokale Lösung](/de/docs/setup/) aus.
## Gehostete Lösungen
Gehostete Lösungen sind eine bequeme Möglichkeit, Kubernetes-Cluster zu erstellen und zu warten.
Sie verwalten und betreiben Ihre Cluster, so dass Sie dies nicht tun müssen.
Sie sollten eine gehostete Lösung auswählen, wenn Sie:
* Eine vollständig verwaltete Lösung wünschen
* Sie möchten sich auf die Entwicklung Ihrer Apps oder Dienste konzentrieren
* Sie haben kein dediziertes Site-Reliability-Engineering-Team (SRE), möchten jedoch eine hohe Verfügbarkeit
* Sie haben keine Ressourcen zum Hosten und Überwachen Ihrer Cluster
Wählen Sie eine [gehostete Lösung](/de/docs/setup/) aus.
## Schlüsselfertige Cloud-Lösungen
Mit diesen Lösungen können Sie Kubernetes-Cluster mit nur wenigen Befehlen erstellen. Sie werden aktiv entwickelt und verfügen über eine Community-Unterstützung.
Sie können auch auf einer Reihe von Cloud-IaaS-Anbietern gehostet werden, und bieten mehr Freiheit und Flexibilität für eine Gegenleistung.
Sie sollten eine schlüsselfertige Cloud-Lösung auswählen, wenn Sie:
* Mehr Kontrolle über Ihre Cluster haben möchten, als die gehosteten Lösungen zulassen
* Mehr operative Verantwortung übernehmen Möchten
Wählen Sie eine [schlüsselfertige Cloud-Lösung](/de/docs/setup/) aus.
## Schlüsselfertige On-Premises-Lösungen
Mit diesen Lösungen können Sie Kubernetes-Cluster mit nur wenigen Befehlen in Ihrem internen, sicheren Cloud-Netzwerk erstellen.
Sie sollten eine schlüsselfertige lokal betriebene Cloud-Lösung auswählen, wenn Sie:
* Cluster in Ihrem privaten Cloud-Netzwerk bereitstellen möchten
* Ein engagiertes SRE-Team haben
* Über die Ressourcen zum Hosten und Überwachen Ihrer Cluster verfügen
Wählen Sie eine [schlüsselfertige On-Premises-Lösung](/de/docs/setup/) aus.
## Individuelle Lösungen
Individuelle Lösungen geben Ihnen die größte Freiheit in Ihren Clustern, erfordern jedoch das meiste Know-how.
Diese Lösungen reichen von Bare-Metal-Anbietern bis hin zu Cloud-Anbietern mit unterschiedlichen Betriebssystemen.
Wählen Sie eine [individuelle Lösung](/de/docs/setup/) aus.
{{% /capture %}}
{{% capture whatsnext %}}
Gehen Sie zu [Auswählen der richtigen Lösung](/de/docs/setup/) für eine vollständige Liste der möglichen Lösungen.
Minikube ist ein Tool, mit dem Kubernetes lokal einfach ausgeführt werden kann. Minikube führt einen Kubernetes-Cluster mit einem einzigen Node in einer VM auf Ihrem Laptop aus, damit Anwender Kubernetes ausprobieren oder täglich damit entwickeln können.
{{% /capture %}}
{{% capture body %}}
## Minikube-Funktionen
* Minikube unterstützt Kubernetes-Funktionen wie:
* DNS
* NodePorts
* ConfigMaps and Secrets
* Dashboards
* Container Laufzeiumgebungen: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) und [containerd](https://github.com/containerd/containerd)
* Unterstützung von CNI (Container Network Interface)
* Ingress
## Installation
Lesen Sie [Minikube installieren](/docs/tasks/tools/install-minikube/) für Informationen zur Installation von Minikubes.
## Schnellstart
Folgend finden Sie eine kurze Demo zur Verwendung von Minikube.
Wenn Sie den VM-Treiber ändern möchten, fügen Sie das entsprechende `--vm-driver=xxx`-Flag zu `minikube start` hinzu.
Beachten Sie, dass die unten angegebene IP-Adresse dynamisch ist und sich ändern kann. Sie kann mit `minikube ip` abgerufen werden.
* none (Führt die Kubernetes-Komponenten auf dem Host und nicht in einer VM aus. Die Verwendung dieses Treibers erfordert Docker ([Docker installieren](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) und eine Linux-Umgebung)
```shell
minikube start
```
```
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
```
```shell
kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
Um [rkt](https://github.com/rkt/rkt) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
```shell
minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=rkt
```
Hierbei wird ein alternatives Minikube-ISO-Image verwendet, das sowohl rkt als auch Docker enthält, und CNI-Netzwerke ermöglichen.
### Treiber Plugins
Weitere Informationen zu unterstützten Treibern und zur Installation von Plugins finden Sie bei Bedarf unter [TREIBER](https://git.k8s.io/minikube/docs/drivers.md).
### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen
Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importortieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben.
Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den `docker-env`-Befehl in Ihrer Shell:
```shell
eval$(minikube docker-env)
```
Sie sollten nun Docker in der Befehlszeile Ihres Mac/Linux-Computers verwenden können, um mit dem Docker-Daemon in der Minikube-VM zu sprechen:
```shell
docker ps
```
In Centos 7 meldets Docker möglicherweise den folgenden Fehler:
```shell
Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
```
Das Update besteht darin, `/etc/sysconfig/docker` zu aktualisieren, um sicherzustellen, dass die Umgebungsänderungen von Minikube beachtet werden:
```shell
< DOCKER_CERT_PATH=/etc/docker
---
> if[ -z "${DOCKER_CERT_PATH}"];then
> DOCKER_CERT_PATH=/etc/docker
> fi
```
Denken Sie daran, `imagePullPolicy: Always` auszuschalten. Andernfalls verwendet Kubernetes keine lokal erstellten Images.
## Cluster verwalten
### Cluster starten
Mit dem Befehl `minikube start` können Sie Ihr Cluster starten.
Dieser Befehl erstellt und konfiguriert eine virtuelle Maschine, auf der ein Kubernetes-Cluster mit einem Knoten ausgeführt wird.
Ebenfalls konfiguriert dieser Befehl auch Ihre [kubectl](/docs/user-guide/kubectl-overview/) Installation zur Kommunikation mit diesem Cluster.
Wenn Sie sich hinter einem Web-Proxy befinden, müssen Sie diese Informationen mit dem Befehl `minikube start` übergeben:
Leider wird nur das Setzen der Umgebungsvariablen nicht funktionieren.
Minikube erstellt auch einen "Minikube"-Kontext und setzt ihn in kubectl auf den Standardwert.
Um später wieder zu diesem Kontext zurückzukehren, führen Sie den folgenden Befehl aus: `kubectl config use-context minikube`.
#### Angabe der Kubernetes-Version
Sie können die bestimmte Version von Kubernetes für Minikube angeben, indem Sie die Zeichenfolge `--kubernetes-version` an den Befehl` minikube start` anhängen.
Zum Verwenden der Version `v1.7.3` führen Sie beispielsweise Folgendes aus:
```
minikube start --kubernetes-version v1.7.3
```
### Kubernetes konfigurieren
Minikube verfügt über eine "Konfigurator"-Funktion, mit der Anwender die Kubernetes-Komponenten mit beliebigen Werten konfigurieren können.
Um diese Funktion zu verwenden, setzen Sie das `--extra-config`-Flag an den `minikube start` Befehl.
Dieses Flag wird wiederholt, sodass Sie es mehrere Male mit verschiedenen Werten übergeben können, um mehrere Optionen festzulegen.
Dieses Flag nimmt eine Zeichenkette der Form `component.key=value` an, wobei `component` eine der Zeichenketten aus der unteren Liste ist, `key` ein Wert in der Konfigurationsstruktur ist und `value` der einzustellende Wert ist.
Gültige Schlüssel finden Sie in der Dokumentation der Kubernetes `componentconfigs` für jede Komponente.
Nachstehend die Dokumentation für jede unterstützte Konfiguration:
Um die `MaxPods`-Einstellung im Kubelet auf 5 zu ändern, übergeben Sie dieses Flag: `--extra-config=kubelet.MaxPods=5`.
Diese Funktion unterstützt auch verschachtelte Strukturen. Um die `LeaderElection.LeaderElect` Einstellung zu `true` zu ändern, übergeben Sie im Scheduler dieses Flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
Um den `AuthorizationMode` auf dem `apiserver` zu `RBAC` zu ändern, verwenden Sie: `--extra-config=apiserver.authorization-mode=RBAC`.
### Einen Cluster stoppen
Mit dem Befehl `minikube stop` können Sie Ihr Cluster anhalten.
Mit diesem Befehl wird die Minikube Virtual Machine heruntergefahren, der Clusterstatus und die Clusterdaten bleiben jedoch erhalten.
Durch erneutes Starten des Clusters wird der vorherige Status wiederhergestellt.
### Cluster löschen
Der Befehl `minikube delete` kann zum Löschen Ihres Clusters verwendet werden.
Mit diesem Befehl wird die Minikube Virtual Machine heruntergefahren und gelöscht. Keine Daten oder Zustände bleiben erhalten.
## Mit einem Cluster interagieren
### Kubectl
Der `minikube start` Befehl erstellt einen [kubectl Kontext](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) genannt "minikube".
Dieser Kontext enthält die Konfiguration für die Kommunikation mit Ihrem Minikube-Cluster.
Minikube setzt diesen Kontext automatisch auf den Standardwert, aber wenn Sie in Zukunft wieder darauf zurückgreifen müssen, führen Sie den folgenden Befehl aus:
`kubectl config use-context minikube`,
Oder übergeben Sie den Kontext bei jedem Befehl wie folgt: `kubectl get pods --context=minikube`.
### Dashboard
Um Zugriff auf das [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) zu erhalten, führen Sie diesen Befehl in einer Shell aus, nachdem Sie Minikube gestartet haben, um die Adresse abzurufen:
```shell
minikube dashboard
```
### Services
Um auf einen Service zuzugreifen, der über einen NodePort verfügbar gemacht wird, führen Sie diesen Befehl in einer Shell aus, nachdem Sie Minikube gestartet haben, um die Adresse abzurufen:
```shell
minikube service [-n NAMESPACE][--url] NAME
```
## Netzwerk
Die Minikube-VM wird über eine Host-Only-IP-Adresse, die mit dem Befehl `minikube ip` abgerufen werden kann, für das Hostsystem verfügbar gemacht.
Auf alle Dienste des Typs `NodePort` kann über diese IP-Adresse und den NodePort zugegriffen werden.
Um den NodePort für Ihren Dienst zu ermitteln, können Sie einen `kubectl`-Befehl wie folgt verwenden:
`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
## Dauerhafte Volumen
Minikube unterstützt [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) des Typs `hostPath`.
Diese dauerhaften Volumen werden einem Verzeichnis in der Minikube-VM zugeordnet.
Die Minikube-VM wird in ein temporäres Dateisystem hochgefahren, sodass die meisten Verzeichnisse nicht nach Neustarts beibehalten werden (`minikube stop`).
Minikube ist jedoch so konfiguriert, dass Dateien beibehalten werden, die in den folgenden Host-Verzeichnissen gespeichert sind:
*`/data`
*`/var/lib/minikube`
*`/var/lib/docker`
Hier ist ein Beispiel einer PersistentVolume-Konfiguration, um Daten im Verzeichnis `/ data` beizubehalten:
```yaml
apiVersion:v1
kind:PersistentVolume
metadata:
name:pv0001
spec:
accessModes:
- ReadWriteOnce
capacity:
storage:5Gi
hostPath:
path:/data/pv0001/
```
## Hostordnerfreigabe
Einige Treiber werden einen Hostordner in der VM bereitstellen, sodass Sie Dateien problemlos zwischen VM und Host freigeben können. Diese sind momentan nicht konfigurierbar und unterscheiden sich für den Treiber und das Betriebssystem, das Sie verwenden.
{{< note >}}
Die Hostordnerfreigabe ist noch nicht im KVM-Treiber implementiert.
{{< /note >}}
| Treiber | Betriebssystem | Hostordner | VM |
| --- | --- | --- | --- |
| VirtualBox | Linux | /home | /hosthome |
| VirtualBox | macOS | /Users | /Users |
| VirtualBox | Windows | C://Users | /c/Users |
| VMware Fusion | macOS | /Users | /Users |
| Xhyve | macOS | /Users | /Users |
## Private Containerregistries
Um auf eine private Container Registry zuzugreifen, führen Sie die Schritte [auf dieser Seite aus](/docs/concepts/containers/images/).
Wir empfehlen die Verwendung von `ImagePullSecrets`, wenn Sie jedoch den Zugriff auf die Minikube-VM konfigurieren möchten, können Sie die Datei `.dockercfg` im Verzeichnis`/home/docker` oder die Datei `config.json` im Verzeichnis`/home/docker/.docker` ablegen.
## Add-ons
Damit Minikube benutzerdefinierte Addons ordnungsgemäß starten oder neu starten kann, platzieren Sie die Addons, die mit Minikube gestartet werden sollen, im Verzeichnis `~ /.minikube/addons`.
Addons in diesem Ordner werden in die Minikube-VM verschoben und jedes Mal gestartet, wenn Minikube gestartet oder neu gestartet wird.
## Minikube mit einem HTTP-Proxy verwenden
Minikube erstellt eine virtuelle Maschine, die Kubernetes und einen Docker-Dämon enthält.
Wenn Kubernetes versucht, Container mithilfe von Docker zu planen, erfordert der Docker-Daemon möglicherweise einen externen Netzwerkzugriff, um Container abzurufen.
Wenn Sie sich hinter einem HTTP-Proxy befinden, müssen Sie möglicherweise die Proxy-Einstellungen für Docker angeben.
Übergeben Sie dazu die erforderlichen Umgebungsvariablen während des `minikube start` als Flags.
Wenn die Adresse Ihrer virtuellen Maschine 192.168.99.100 lautet, besteht die Möglichkeit, dass Ihre Proxy-Einstellungen verhindern, dass `kubectl` sie direkt erreicht.
Um die Proxy-Konfiguration für diese IP-Adresse zu umgehen, sollten Sie Ihre no_proxy-Einstellungen ändern. Sie können dies mit dem folgenden Befehl tun:
```shell
exportno_proxy=$no_proxy,$(minikube ip)
```
## Bekannte Probleme
* Funktionen, die einen Cloud-Provider erfordern, funktionieren in Minikube nicht. Diese schließen ein:
* LoadBalancer
* Features, die mehrere Knoten erfordern. Diese schließen ein:
* Erweiterte Planungsrichtlinien
## Design
Minikube verwendet [libmachine](https://github.com/docker/machine/tree/master/libmachine) zur Bereitstellung von VMs, und [kubeadm](https://github.com/kubernetes/kubeadm) um einen Kubernetes-Cluster in Betrieb zu nehmen.
Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
## Zusätzliche Links
* **Ziele und Nichtziele**: Die Ziele und Nichtziele des Minikube-Projekts finden Sie in unserer [Roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
* **Entwicklungshandbuch**: Lesen Sie [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) für einen Überblick über das Senden von Pull-Requests.
* **Minikube bauen**: Anweisungen zum Erstellen/Testen von Minikube aus dem Quellcode finden Sie im [build Handbuch](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
* **Neue Abhängigkeit hinzufügen**: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der [Anleitung zum Hinzufügen von Abhängigkeiten](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md).
* **Neues Addon hinzufügen**: Anweisungen zum Hinzufügen eines neuen Addons für Minikube finden Sie im [Anleitung zum Hinzufügen eines Addons](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
* **MicroK8s**: Linux-Benutzer, die die Ausführung einer virtuellen Maschine vermeiden möchten, sollten [MicroK8s](https://microk8s.io/) als Alternative in Betracht ziehen.
## Community
Beiträge, Fragen und Kommentare werden begrüßt und ermutigt! Minikube-Entwickler finden Sie in [Slack](https://kubernetes.slack.com) im #minikube Kanal (Erhalten Sie [hier](http://slack.kubernetes.io/) eine Einladung). Wir haben ausserdem die [kubernetes-dev Google Groups-Mailingliste](https://groups.google.com/forum/#!forum/kubernetes-dev). Wenn Sie in der Liste posten, fügen Sie Ihrem Betreff bitte "minikube:" voran.
Sie können entweder eine Version aus dem Quellcode erstellen oder eine bereits kompilierte Version herunterladen.
Wenn Sie nicht vorhaben, Kubernetes selbst zu entwickeln, empfehlen wir die Verwendung eines vorkompilierten Builds der aktuellen Version, die Sie in den [Versionshinweisen](/docs/setup/release/notes/) finden.
Der Kubernetes-Quellcode kann aus dem [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repo der heruntergeladen werden.
{{% /capture %}}
{{% capture body %}}
## Aus dem Quellcode kompilieren
Wenn Sie einfach ein Release aus dem Quellcode erstellen, müssen Sie keine vollständige Golang-Umgebung einrichten, da alle Aktionen in einem Docker-Container stattfinden.
Mehr Informationen zum Release-Prozess finden Sie im kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) Verzeichnis.
Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt.
Eine Aufgabenseite zeigt, wie man eine einzelne Aufgabe ausführt, typischerweise durch eine kurze Abfolge von Schritten.
{{% /capture %}}
{{% capture body %}}
## Webbenutzeroberfläche (Dashboard)
Stellen Sie die Dashboard-Webbenutzeroberfläche bereit, und greifen Sie auf sie zu, um Sie bei der Verwaltung und Überwachung von Containeranwendungen in einem Kubernetes-Cluster zu unterstützen.
## Die kubectl-Befehlszeile verwenden
Installieren und konfigurieren Sie das `kubectl`-Befehlszeilentool, mit dem Kubernetes-Cluster direkt verwaltet werden.
## Pods und Container konfigurieren
Ausführen allgemeiner Konfigurationsaufgaben für Pods und Container.
## Anwendungen ausführen
Ausführen allgemeiner Aufgaben zur Anwendungsverwaltung, z. B. Aktualisierungen, Einfügen von Informationen in Pods und automatisches horizontales Skalieren der Pods.
## Jobs ausführen
Jobs mit Parallelverarbeitung ausführen.
## Auf Anwendungen in einem Cluster zugreifen
Konfigurieren Sie den Lastausgleich, die Portweiterleitung oder die Einrichtung von Firewall- oder DNS-Konfigurationen für den Zugriff auf Anwendungen in einem Cluster.
## Überwachung, Protokollierung und Fehlerbehebung
Richten Sie die Überwachung und Protokollierung ein, um einen Cluster zu behandeln oder eine Container-Anwendung zu debuggen.
## Zugriff auf die Kubernetes-API
Lernen Sie verschiedene Methoden kennen, um direkt auf die Kubernetes-API zuzugreifen.
## TLS verwenden
Konfigurieren Sie Ihre Anwendung so, dass sie der Cluster-Stammzertifizierungsstelle (Certificate Authority, CA) vertraut und diese verwendet.
## Cluster verwalten
Erfahren Sie allgemeine Aufgaben zum Verwalten eines Clusters.
## Föderation verwalten
Konfigurieren Sie Komponenten in einer Clusterföderation.
## Managing Stateful Applications
Ausführen allgemeiner Aufgaben zum Verwalten von Stateful-Anwendungen, einschließlich Skalieren, Löschen und Debuggen von StatefulSets.
## Cluster-Dämonen
Ausführen allgemeiner Aufgaben zum Verwalten eines DaemonSet, z. B. Durchführen eines fortlaufenden Updates.
## GPUs verwalten
Konfigurieren und planen Sie NVIDIA-GPUs für die Verwendung durch Nodes in einem Cluster als Ressource.
## Verwalten von HugePages
Konfigurieren und verwalten Sie `HugePages` als planbare Ressource in einem Cluster.
{{% /capture %}}
{{% capture whatsnext %}}
Wenn Sie eine Aufgabenseite schreiben möchten, finden Sie weitere Informationen unter [Erstellen einer Pull-Anfrage für Dokumentation](/docs/home/contribute/create-pull-request/).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.