CRI-O now uses a different location for their repositories which also
supports further distributions.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
* Adding reviewer for sig-docs-en-reviews
Adding reviewer for sig-docs-en-reviews
* Adding new entry following alphabetical sort order
Adding new entry following alphabetical sort order
* Consolidate words of caution about Pod network
* Tweak wording
- use tooltips
- fix a TODO hyperlink
- adopt style guidelines
* Revise prerequisites for kubeadm
* Rework page structure
- Replace some headings with anchor elements (preserving inbound links)
- Use a "discussion" section for the discussion part of the page.
- Make Feedback be a part of the What's Next section
- Skip mentioning Docker in a logging context; provide generic
signposting instead.
- Update overview
- Document limitations and fix link to HA topology
- Fixes for styling
* Redo network plugin info
* Use glossary tooltips to introduce terms
* Announce the contributor summit schedule
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Fix minor nits found during review
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Update content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md
Make the map URL easier to read.
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Add contributor summit image
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Update Korean glossary for l10n
* Update content/ko/docs/contribute/localization_ko.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Suggest adding a link in case the reader is not familiar with what "anonymous requests" means. This paragraph also includes a reference to "anonymous user," so I think the link is warranted. Thanks.
* Revise CertificateSigningRequest approval & rejection details
API clients can deny CSRs. Document this and tidy the page.
"There is currently not a mechanism for a signer implementation to report
its inability to sign a request." seemed misleading; clients can set
status.
* Tidy page
Co-Authored-By: Jordan Liggitt <jordan@liggitt.net>
Co-authored-by: Jordan Liggitt <jordan@liggitt.net>
* Update to match website style guide
* Use glossary shortcodes
* Overall tidying
* Drop mention of old (unsupported) releases
* Reword RBAC notes & warnings
* Write “role bindings” as two words
* Tweak RBAC guide wording
* Tweak RBAC out-of-the-box roles table
* Mention other authorizers
There are other authorizers than RBAC and ABAC; hint that these exist
and that the API server might run with these configured.
* Fix formatting of API discovery roles
Also add table caption
* Drop incorrect reference to cluster-status
* Drop vestigial RBAC warning
* Drop feature availability section
This section does not fit with the website style guide.
* State task version requirements
Follow website style guide for stating these.
* Clarify content-type and tracking of all objects
* Update content/en/docs/reference/using-api/api-concepts.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* SSA: Improve a couple of sentences
Co-authored-by: Kevin Wiesmueller <kwiesmueller@seibert-media.net>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
I followed the process for generating docs, but encountered and fixed some problems along the way due to incorrect commands in the documentation:
* Fixed incorrect go get source for `github.com/kubernetes-sigs/reference-docs`
* Fixed syntax error in shell commands by changing `$(GOPATH)` to `$GOPATH`
* Fixed wrong variable name, changed `WEB_ROOT` to `K8S_WEBROOT` to match what Makefile expects
* Correcting name of concept 'Container Enviorment Variables'
This page discusses the container environment and container environment variables are part of it. So removing a 'variable' word to make it more correct.
* Correcting references
Correcting references
* Correcting reference links
Correcting reference links
* Start updates for DaemonSet approach
* Rough first draft
* Remove old image assets
* Document how to fetch the correct version of kube-proxy
* Remove InstallNSSM script
It was merged into the PrepareNode script
* Update links to sig-windows-tools release files
Using the latest tag so we can continue to update things as needed
without needing to keep updating the docs
* Add upgrade tutorial for Windows kubeadm nodes
* Clarify which machine each command should be run from
* Add link from main tutorial, small edits
- Rename file / title
- Remove reviewers
* Remove IP management section
User can just rely on the defaults from kube-proxy and flannel now, or
change them in the same manner as on Linux
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* More review updates
* Switch to task template
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* More review feedback
* Adjust upgrading title
* Additional edits
* Move to kubeadm directory
* Remove stale link
This guide never had any real content about the pause image
* Add redirect from old url
* Fix weights
* Update Windows intro
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fix typo
* Add beta markers
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* adding cheatsheet.md
adding kubectl command to get containerIDs of all
initContainers for every Pod in the cluster
helps to identify stopped container which should not be removed,
when running manual cleanup of stopped containers on K8s cluster nodes
* adding more context for finding initContainer IDs
* removing reference to github issue
Signed-off-by: Anastas Dancha <anapsix@random.io>
* Expand list of places Kubernetes can run
As well as GKE, there are AKS, EKS, and more.
* Add page description
* Link to blog post about Borg
The blog post has (a better) link to Google's paper about Borg. Because
of the historical relevance of that paper and that blog article to the
history of Kubernetes, I think it's OK to link there.
Linking to the blog article provides a less academic introduction to the
history of Kubernetes, with the option to click through and learn things
in detail.
* Remove mentions of unsupported Kubernetes versions
No need to mention supported-since-this-version details for Kubernetes
releases that are now out of support.
* Warn about disabling preemption
* Tweak wording
* Add What's next section
* Tweak Pod priority troubleshooting advice
Reshape the advice about pod priority troubleshooting to explain
user-induced issues (and define expected behavior). If the reader
detects behavior that does not match the documentation, they have
observed a bug and can report that via the usual routes.
* Rewords notes on Pod priority vs. QoS
* Move warning into page body
Issue #17556
Problem:
Below Lines are incorrect
If you specify multiple nodeSelectorTerms associated with nodeAffinity types, then the pod can be scheduled onto a node if one of the nodeSelectorTerms is satisfied.
If you specify multiple matchExpressions associated with nodeSelectorTerms, then the pod can be scheduled onto a node only if all matchExpressions can be satisfied.
Proposed Solution:
They need to be corrected to below
If you specify multiple nodeSelectorTerms associated with nodeAffinity types, then the pod can be scheduled onto a node only if all nodeSelectorTerms can be satisfied.
If you specify multiple matchExpressions associated with nodeSelectorTerms, then the pod can be scheduled onto a node if one of the matchExpressions is satisfied.
* Fix markdown for sample output
Don't highlight this sample output as if it's Bourne shell code.
* Tweak capitalization
- Pod is an API object type
- Container exists in the Kubernetes API, but you can't:
kubectl get container
- Socket isn't an API object type
* Pin source to relevant release
Handle case where sample Golang server changes in master branch post
release.
* Tweak page wording
- Reword a heading in What's Next to explain the links
- explain context for a probe
Running the second part of filling the `kustomization.yaml` using `cat` an issue arrises where the command breaks due to the additional white spaces.
This could cause further issues for the reader might mistake the command as to replace the file content, and this will break the proper functioning of the cluster
* Reword to follow style guidelines
* Highlight commands as shell code
* Specify minimum version
This metadata alters the behavior of the {{< version-check >}}
shortcode.
* Downgrade warning to note
I don't see any adverse consequences if the reader is unaware that port
forwarding for UDP is not yet implemented.
Personally the explanation was quite difficult to understand without looking into the code.
I hope I managed to simplify it a bit and added an example how to add annotations to a
namespace so they can be consumed by the PodTolerationRestriction admission
controller.
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Revise tutorial prerequisites
- Set and use min-kubernetes-server-version metadata
- Combine existing prerequisite sections
* Switch to documentation IPv4 addresses
Use documentation IPv4 addresses as per
https://tools.ietf.org/html/rfc5737
* Tidy Source IP tutorial
* Migrate to definition list
Also reword some definitions
* Update what-is-kubernetes.md
The sub heading felt awkward as it was asking a question, but there was no question mark. As question marks in headings are not ideal in technical documentation anyway, I thought swapping the word order slightly made it sounds _slightly_ better.
* Update content/en/docs/concepts/overview/what-is-kubernetes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Reword API Server aggregation
* Document custom resources ahead of APIService
CustomResourceDefinition is the newer, shinier and often more
appropriate resource to help with cases where APIService was not a good
fit. Switch order to mention the custom resources page first, which
introduces both APIService and CustomResourceDefinition.
* config elasticsearch installed in minikube host
Link to how to config an elasticsearch server in minikube host machine.
* config elasticsearch installed in minikube host
Link to how to config an elasticsearch server in minikube host machine.
* Correcting deployment example
As 'kubectl run' command is deprecated, creating deployment with deployment manifest and apply command.
* Deployment manifest for snowflake example
Deployment manifest for snowflake example
It is not clear that the 'caBundle' field in the Mutating/Validating webhook object is used for client-side validation from the admission controller itself.
The comment which appears at the source code is much more clear --> https://github.com/kubernetes/api/blob/master/admissionregistration/v1beta1/types.go#L534-L537
My suggestion is to change the description to match the documentation which is IMO much more clear
* Update _index.md
Signpost readers from /docs/home/ to /training/ #19554
* Added the link to reroute users from /docs/home to /training
* Signposting for users added
* Updated _index.md
* [WIP] Update Topology Manager for 1.18
Move from Alpha to Beta.
Remove Known Limitation - fixed in 1.18.
* Nit: Update content/en/docs/tasks/administer-cluster/topology-manager.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Add section on feature gate with version guidance.
* Add Known Limitation on Memory/Hugepages
* Update content/en/docs/tasks/administer-cluster/topology-manager.md
Clean up wording of known limitations
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Edits to feature gate description based on review
* Up date feature gates table.
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* pod-overhead: updates for beta
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
* pod-overhead: update documentation for beta
Signed-off-by: Eric Ernst <eric@amperecomputing.com>
You can't specify more then one resources at one for explain. See error below:
$ kubectl explain pods,svc
the server doesn't have a resource type "pods,svc"
error: We accept only this format: explain RESOURCE
* Correcting all headings
All tasks of this page list down container images and not container itself. so changing all headings to make it correct.
* Correcting case
Correcting case
* Update dry-run docs.
* Promote server-side dry-run feature state to stable in 1.18
* Replace --dry-run with --dry-run=server|client|none accordingly
* Update server-side dry-run blog post
* Update content/en/docs/reference/using-api/api-concepts.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Address comments
* Add note at end of server-side dry-run blogpost
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Delete insecure external link.
Delete insecure external link. The website hasn't an HTTPS version.
Also, the project (https://github.com/kubernetes-retired/contrib/tree/master/node-perf-dash) will be archived 2 years ago.
* Update reserve-compute-resources.md
* Remove link to blog for the same reason.
* fixes troubleshooting-kubeadm references to taint node-role.kubernetes.io/master
Signed-off-by: Marshall Ford <inbox@marshallford.me>
* revert ja,zsh langs
Signed-off-by: Marshall Ford <inbox@marshallford.me>
Remove references to 169.254.20.10 as the default.
Update content/en/docs/tasks/administer-cluster/nodelocaldns.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Do a top-to-bottom review of "debug-services"
I frequently refer people to this doc, so I thought it would make sense
to review it. Overall ot was pretty up to date. I did a cleanup pass
and moved a few things around. Mostly cosmetic.
* Fix backticked resources in "debug-services"
* Fix code vs output blocks in "debug-services"
* Remove prompts from code blocks
* s/we/you/
* Apply feedback edits
* Add whats next section to PersistentVolume page
Add whats next section to PersistentVolume page
* Adding references to PersistentVolume page
Adding references to PersistentVolume page
* translating doc kubelet garbage collection
* code review corrections in the garbage collection doc
* Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Co-Authored-By: Diego W. Antunes <devlware@gmail.com>
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Co-Authored-By: Diego W. Antunes <devlware@gmail.com>
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Co-Authored-By: Diego W. Antunes <devlware@gmail.com>
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Co-Authored-By: Diego W. Antunes <devlware@gmail.com>
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Co-Authored-By: Diego W. Antunes <devlware@gmail.com>
Update content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md
Co-Authored-By: Diego W. Antunes <devlware@gmail.com>
Co-authored-by: Diego W. Antunes <devlware@gmail.com>
* Update content in intermediate.md
Replaced “If your feature is moving out of Alpha, make sure to remove it from that file.” with “If your feature is moving to Beta or to General Availability, update the feature gates file.”
* Revised update intermediate.md
Preserved the wrapping per Tim's suggestion
Adds an entry to the Concepts section that gives an overview of the feature
and builds upon the generated API documentation.
Also adds a Glossary entry for shuffle sharding.
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-Authored-By: Mike Spreitzer <mspreitz@us.ibm.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Mike Spreitzer <mspreitz@us.ibm.com>
Added <time> </time> HTML element to the date heading in blog post articles.
The opening <time> tag also was given a datetime attribute, with the value using another Hugo shortcode. Since these use Go time patterns; we included the following in the opening <time> tag datetime="{{ .Date.Format "2006-01-02" }}".
* Update to Outdated files in dev-1.17-ko.6 branch.
* Apply suggestions from code review
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
* create rabc.md file
Add rbac.md file, I found that there is no corresponding Chinese translation in the official website, so I translated rbac.md in Chinese, I hope it will be helpful, thanks
新增rabc.md文件，我发现官网中没有对应的中文翻译，所以我将官网中对应的rbac文档翻译成中文，希望有帮助，谢谢
* update rbac.md
Add comments to the original English text
* update rbac.md
中英文之间应留白处未留白；
中文仍有半角标点出现；
有些句子不符合汉语表达习惯；
有些英文原文需要多读几遍，以求正确理解。
* update rbac.md
review更新至代码行1940行
* update rbac.md
* update rbac.md
update zh-trans content/zh/docs/reference/access-authn-authz/rbac.md
* update rbac.md
replace line 1-4 with "---".
* update rbac.md
del 1,3 line
* update rbac.md
line 42, add a space .because of the API Overview's text display problem.
* update rbac.md
replace "角色（Role）" to “角色”
* update rbac.md
Permissive RBAC Permissions 'text format is error
* update rbac.md
translate the contents of the column
An error occurred when executing the original command. After comparison, it was found that there was a problem with the command on the Chinese document.
* Consolidate and redirect training
* Update static/_redirects
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Remove Udacity link
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Minor correction on safely drain node task
1. 'kubectl drain' command drains node and not a machine. So the machine word is replaced with node.
2. Also, add reference link to maintenance on a node task in what's next section
* Correcting link
Correcting link
* Update hugepages documentation
- described support for multiple huge page sizes
- described container isolation of the huge pages
* Add HugePageStorageMediumSize description
* update description for container isolation of hugepages
Signed-off-by: Byonggon Chun <bg.chun@samsung.com>
Co-authored-by: Byonggon Chun <bg.chun@samsung.com>
* Clarify At-Most-One Semantic For DaemonSet Update
Make it explicit, that at most one pod will run on each node while updating a daemonset. As mentioned here: https://github.com/kubernetes/kubernetes/issues/48841
* Clarify Update Strategy For DaemonSet Pods Only
* Use feature state for non-preempting PriorityClasses
* PreemptionPolicy requires NonPreemptingPriority feature gate
* Remove alpha qualifier from section title and decrease example heading level
* Use singular of PriorityClass in the heading
* Create bring-your-ideas-to-world-with-kubectl-plugins.md
First draft.
* Comment: lower case for kubectl plugins
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Comment: Link to docs on kubernetes.io
* Fix grammar in title
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Comments: Improve language and grammar. Reduce verbosity.
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* blog: add date for krew post
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com>
Co-authored-by: Bob Killen <killen.bob@gmail.com>
We prefixed the CHANGELOG path in k/k with `CHANGELOG/`, which should
reflect every part of the website as well.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
* Note CronJob timezone comes from system timezone
The timezone for the kube-controller-manager (or if that's broken apart,
the cronjob controller) determines when CronJobs are scheduled.
This reverts commit bad124b857.
* Expand details about CronJob timezone
* Adding reference to node concept page.
This page discuss about assigning pods to the node but missing reference to the node concept page. So for better navigation added this reference in what's next section
* Correcting syntax
Correcting syntax
* Adding glossary tooltip for 'node'
Adding glossary tooltip for 'node'
* Consolidate words of caution about Pod network
* Tweak wording
- use tooltips
- fix a TODO hyperlink
- adopt style guidelines
* Revise prerequisites for kubeadm
* Rework page structure
- Replace some headings with anchor elements (preserving inbound links)
- Use a "discussion" section for the discussion part of the page.
- Make Feedback be a part of the What's Next section
- Skip mentioning Docker in a logging context; provide generic
signposting instead.
- Update overview
- Document limitations and fix link to HA topology
- Fixes for styling
* Redo network plugin info
* Use glossary tooltips to introduce terms
* Announce the contributor summit schedule
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Fix minor nits found during review
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
* Update content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md
Make the map URL easier to read.
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Add contributor summit image
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Update Korean glossary for l10n
* Update content/ko/docs/contribute/localization_ko.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
This PR contains sync up between master and dev-1.18 and also reolsved merge conflicts occured during previous sync during previous sync up caused due to missed adding tide-method merge
Signed-off-by: vineeth <vineethpothulapati@outlook.com>
* Reduce ambiguity on nodePort
At first sight, nodePort looks a lot like service.Spec.NodePort, though it just means a port allocated from "--service-node-port-range". Replacing "nodePort" with "node port" to add some clarity.
* Update content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Add newlines to `none` VM driver docs
* Add note on `none` driver in minikube installation docs
Link to documentation describing possible security and data loss issues
* minikube: Add caution block to `none` vm driver
* Edit Debian-related minikube instructions
Update section on the `none` driver.
* cri-o version must match the k8 version
It's not clear from the doc that the cri-o version must match the k8 version as shown in the cri-o compatibility matrix.
* changed to note shortcode for cri-o compat matrix - fix author
* Fix link to cluster upgrade with kubeadm
* Improve kubeadm container runtime install steps
* Use tabs for Linux vs. non-Linux kubeadm CRI details
* Tweak wording
* Use dagger in place of double asterisk
(Double asterisks don't render as well, and also can confuse
Markdown-aware editors).
* Move link inside preceding tabs
Repeating the text makes life easier for readers.
A long time ago, we added a new shortcode `codenew` as a replacement of
the `code` shortcode. The intention was to consolidate all example
manifests to a single subdirectory, i.e. `content/<lang>/examples`. Now
this transition is almost over. We have only two instances where the old
`code` shortcode is referenced.
This PR makes the `policy.rego` file inlined content so that all
referenes to `code` are killed. We can safely drop the `code` shortcode.
If desired, we can rename the `codenew` shortcode to `code` in a
(series of) separate PR(s).
* Fixed outdated ECR credential debug message (#18631)
* Fixed outdated ECR credential debug message
The log message for troubleshooting kubelet auto fetching ECR credentils issue has been changed (noticed since 1.14), and the new message reads like this when verbose log level is set to 3:
- `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
- `aws_credentials.go:116] Got ECR credentials from ECR API for <Your ECR AWS Account ID>.dkr.ecr.us-east-1.amazonaws.com`
This is based on the kubelet source code:
https://github.com/kubernetes/kubernetes/blob/release-1.14/pkg/credentialprovider/aws/aws_credentials.go#L91
This PR is to fix this and to avoid confusion for more people who are troubleshooting the kubelet ECR issue.
* Update content/en/docs/concepts/containers/images.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Fix deployment name in docs/tasks/administer-cluster/dns-horizontal-autoscaling.md (#18772)
* ru/docs/tutorials/hello-minikube.md: sync with English translation. (#18687)
* content/ru/docs/concepts/_index.md: use English names for kinds. (#18613)
* Fix French typo in "when" section (#18786)
* First Japanese l10n work for release-1.16 (#18790)
* Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710)
* Translate concepts/services-networking/connect-applications-service/ into Japanese
* Apply review
* Translate content/ja/docs/tasks/_index.md into Japanese (#17789)
* add task index
* huge page
* ja-docs: Update kops Installation Steps (#17804)
* Update /ja/docs/tasks/tools/install-minikube/ (#17711)
* Update /ja/docs/tasks/tools/install-minikube/
* Apply review
* Apply review
* Update content/ja/docs/tasks/tools/install-minikube.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/tools/install-minikube.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160)
* copy from content/en/docs/tasks/configure-pod-container/ to ja
* translate assign-cpu-resource.md in Japanese
* Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update assign-cpu-resource.md
ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく
* fix translation
"Pod scheduling is based on requests." の箇所。
requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述
* Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794)
* ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848)
* ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848)
* little fix (#18135)
* update index (#18136)
* Update /ja/docs/setup/_index.md (#18139)
* Update /ja/docs/tasks/tools/install-kubectl/ (#18137)
* update /docs/ja/tasks/tools/install-kubectl/
* fix mongon
* apply reveiw
* Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141)
* Update feature agete
* tidy up feature gates list
* translate new lines
* table caption
* blank
* する -> します
* apply review
* fix broken link
* Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* update translation
* remove line
* Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* rollpack
* Update /ja/docs/concepts/services-networking/service/ (#18138)
* update /ja/docs/concepts/services-networking/service/
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/services-networking/service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* consider Endpoints as a Kubernetes resource
* full
* Update content/ja/docs/concepts/_index.md (#18145)
* Update concepts
* control plane
* apply review
* fix bold (#18165)
* Update /ja/docs/concepts/overview/components.md (#18153)
* update /ja/docs/concepts/overview/components.md
* some japanese docs are already there
* translate prepend
* apply upstream changes (#18278)
* Translate concepts/services-networking/ingress into Japanese #17741 (#18234)
* ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741)
* ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741)
* ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741)
* Update pod overview in Japanese (#18277)
* Update pod-overview
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* ノード
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/concepts/workloads/pods/pod-overview.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
* Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796)
* ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119)
* ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119)
* ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119)
* ja-trans:conetent/ja/casestudies/nav (#18450)
* Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395)
* Translate tasks/debug-application-cluster/debug-service/ in Japanese
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Change all `Pods` to `Pod` and `Endpoints` to `Endpoint`
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Updated content pointed out in review
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Apply suggestions from code review
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Apply suggestions from review
* Apply suggestions form review
* Apply suggestions from review
* Apply suggestions from review
* Apply suggestions from code review
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/debug-application-cluster/debug-service.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: inductor <kohei.ota@zozo.com>
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
* Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200)
* Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese
* Apply suggestions from code review between L1 an L120 by oke-py
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Apply suggestions from code review by oke-py
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update CustomResourceDefinition not to localize into Japanese
* Revert the link to customresourcedefinitions to English
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Apply suggestions from code review by oke-py and inductor
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Apply a suggestion from review by inductor
* Apply a suggestion from code review by oke-py
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: inductor <kohei.ota@zozo.com>
* Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173)
* copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja
* Translate tasks/configure-pod-container/quality-service-pod/ into Japanese
Guaranteed, Burstable, BestEffortは用語として存在するので訳さない
Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com>
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
* Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285)
* Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739)
* Translated kubectl cheet sheet.
* Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739)
* Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md
* Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md
* Modify translation for casestudies (#18767)
* modify terminology
* add ten
* update translation
* update
* update
* update
* fix typo (#18769)
* remove english comment (#18770)
* ja-trans:conetent/ja/casestudies/spotify (#18451)
* ja-trans: content/ja/case-studies/spotify
* Update content/ja/case-studies/spotify/index.html
Updated with the proposal from inductor
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Updated with inductor 's proposal
Co-Authored-By: inductor <kohei.ota@zozo.com>
* ja-trans: content/ja/case-studies/spotify
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
* Update content/ja/case-studies/spotify/index.html
Co-Authored-By: inductor <kohei.ota@zozo.com>
Co-authored-by: inductor <kohei.ota@zozo.com>
* Translate Japanese headers (#18776)
* translate headers
* add index for references
* Update content/ja/docs/setup/production-environment/tools/_index.md
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* translate controller
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
* ja-docs: translate install-kubeadm into Japanese (#18198)
* ja-docs: translate install-kubeadm into Japanese
* translate table title in install-kubeadm to Japanese
* update kubeadm install doc
* remove extra spaces
* fix translation miss
* translate url title into japanese
* fix translation miss
* remove line break in sentence and translate title
* remove extra line break
* remove extra line break
* fix translation miss
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com>
Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp>
Co-authored-by: Keita Akutsu <kakts.git@gmail.com>
Co-authored-by: Masa Taniguchi <maabou512@gmail.com>
Co-authored-by: Soto Sugita <sotoiwa@gmail.com>
Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com>
Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com>
Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com>
* delete zh SEE ALSO(51-54) (#18788)
* Added missing brackets in markdown (#18783)
* Fix broken links in api_changes doc (#18743)
* fix jump (#18781)
* fix redundant note (#18780)
* Fix typo: default-manager -> default-scheduler (#18709)
like #18649#18708
* fix issue #18738 (#18773)
Signed-off-by: Dominic Yin <yindongchao@inspur.com>
* Correct description of kubectl (#18172)
* Correct description of kubectl
Given that `kubectl` is not a [command line interface (CLI)](https://en.wikipedia.org/wiki/Command-line_interface), I suggest calling it what it is -- a control utility (ctl = control). The term "tool" is commonly used in place of "utility," including the `kubectl` docs.
A CLI presents the user with a command prompt at which the user can enter multiple command lines that a command-line interpreter interprets and processes. Think of `bash`, `emacs`, or a SQL shell. Since `kubectl` is not run in a shell, it is not a CLI.
Here are related docs that correctly refer to `kubectl` as a "command-line tool":
- https://kubernetes.io/docs/reference/tools/#kubectl
- https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-kubectl
- https://kubernetes.io/docs/tasks/tools/install-kubectl/
- https://kubernetes.io/docs/reference/kubectl/kubectl/
* Update content/en/docs/reference/kubectl/overview.md
Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com>
Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com>
* Add blog post: Reviewing 2019 in Docs (#18662)
Tiny fix
Feedback from onlydole
Add missing link
Incremental fixes
Revise Jim's job title
Update content/en/blog/_posts/2020-01-17-Docs-Review-2019.md
Co-Authored-By: Celeste Horgan <celeste@cncf.io>
Feedback from celeste, change date
* Update OWNERS_ALIASES (#18803)
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-authored-by: Bob Killen <killen.bob@gmail.com>
Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com>
* blog: introduce CSI support for ephemeral inline volumes (#16832)
* csi-ephemeral-inline-volumes: introduce CSI support for ephemeral inline volumes
This was alpha in Kubernetes 1.15 and became beta in 1.16. Several CSI
drivers already support it (soon...).
* csi-ephemeral-inline-volumes: bump date and address feedback (NodeUnpublishVolume)
* csi-ephemeral-inline-volumes: add examples and next steps
* csi-ephemeral-inline-volumes: rename file, minor edits
* csi-ephemeral-inline-volumes: include Docker example
* Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md (#18062)
* Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
* Update and rename 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
* Update 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
* Update and rename 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-22-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md
Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com>
* Revert "Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)" (#18805)
This reverts commit 2c4545e105.
* add blog k8s on mips (#18795)
* add blog k8s on mips
* modify english title to chinese
* modify some error
* Remove user-journeys legacy content #18615 (#18779)
* Use monospace for HostFolder and VM in the French Minikube setup guide. (#18749)
* Add French version of persistent volume page concept page (#18706)
* Add French version of persistent volume page concept page
* Fix
* Fix
* Fix
* Fix
* sync content/zh/docs/reference/issues-security/ en zh (#18727)
* update zh-translation: /docs/concepts/storage/volume-snapshots.md (#18650)
* Clean up user journeys content for zh (#18815)
* Followup fixes for: Add resource version section to api-concepts (#18069)
* Followup fixes for: Add resource version section to api-concepts documentation
* Apply feedback
* Apply feedback
* Switch paragraph to active voice
* Add Community and Code of Conduct for ID (#18828)
* Add additional ways to contribute part to update zh doc (#18762)
* Add additional ways to contribute part to update zh doc
* Add original English text
* Update content/zh/docs/contribute/_index.md
Co-Authored-By: chentanjun <tanjunchen20@gmail.com>
Co-authored-by: chentanjun <tanjunchen20@gmail.com>
* Clean up extensions/v1beta1 in docs (#18839)
* fix an example path (#18848)
* Translating network plugins (#17184)
* Fix for a typo (#18822)
* tą instalację -> tę instalację / (https://sjp.pwn.pl/poradnia/haslo/te-czy-ta;1598.html) (#18801)
* Fix typo in Scalability section (#18866)
The phrase `very larger` is not valid, it is supposed to be either `very
large` or `larger`. Propose to have it `very large`.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Add Polish translation of Contribute index page (#18775)
Co-Authored-By: Michał Sochoń <kaszpir@gmail.com>
Co-authored-by: Michał Sochoń <kaszpir@gmail.com>
* Clean up extensions/v1beta1 in docs (#18838)
* Add Indonesian Manage Compute Resources page (#18468)
* Add Indonesian Manage Compute Resources page
* Updates to id Manage Compute Resources page
* Add DaemonSet docs ID localization (#18632)
Signed-off-by: giovanism <giovanism@outlook.co.id>
* Fix typo in en/docs/contribute/style/content-guilde.md (#18862)
* partial fix for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted #18411 (#18875)
* See Also removed file 31
* see also removed file 32
* see also removed file 33
* see also removed file 34
* see also removed file 35
* Modify pod.md (#18818)
website/content/ko/docs/concepts/workloads/pods/pod.md
23 line
쿠버네티스는는 -> 쿠버네티스는
modify
* remove $ following the style guide (#18855)
* Add Hyperlink to Kubernetes API (#18852)
* Drive by copy edit of blog post (#18881)
* Medium copy edit.
* more fixes
* Translate Events Calendar (#18860)
* Adding Bahasa Indonesia translation for Device Plugin page #18676 (#18676)
Co-Authored-By: Gede Wahyu Adi Pramana <tokekbesi@gmail.com>
Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com>
* change escaped chars to markdown (#18858)
Helps to keep doc clean for long term
* Fix header layout on Safari (#18888)
* Fix references to sig-docs-l10n-admins (#18661)
* Add French deployment concept page (#18516)
* Add French deployment concept page
* Fix
* Fix
* Fix
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fix
* Fix
* Fix
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/fr/docs/concepts/workloads/controllers/deployment.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Fix ZH security aliases (#18895)
* disable simplytunde as an approver due to inactivity. (#18899)
Always welcome to come back if able to become active
again
Signed-off-by: Brad Topol <btopol@us.ibm.com>
* install container runtimes without prompts (#18893)
In Kubernetes docs, all of the packages that are required to set up the
Kubernetes are installed without requiring any prompts through
the package manager (like apt or yum) except for the container runtimes.
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
So, it would be better to have these installations with prompts (yes) disabled.
* Fix small typos (#18886)
* Fix small typos
Small typos noticed and fixed in:
- configure-upgrade-etcd.md
- reconfigure-kubelet.md
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Rephrase a paragraph on etcd upgrade
en\docs\tasks\administer-cluster\configure-upgrade-etcd.md
Following a suggestion in #18886, I've rephrased a sentence on etcd
upgrade prerequisites.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Clean up extensions/v1beta1 in docs (#18841)
* Update _index.md (#18825)
* Run minikube docker-env in a shell-independent way (#18823)
* doc: correct pv status for pv protection example. (#18816)
* Small editorial fixes in glossary entries (#18807)
* Small editorial fixes in glossary entries
* Revert the wording in the glossary term for proxy
* fix doc conflict regarding postStart (#18806)
* kubeadm: improvements to the cert management documentation (#18397)
- move the sections about custom certificates and external CA
to the kubeadm-certs page
- minor cleanups to the kubeadm-certs page, including updated output
for the check-expiration command
- link the implementation details page to the new locations
for custom certs and external CA
* fix doc conflict regarding postStart
* Grammar (#18785)
* grammar: 'to' distributes over 'or'
* grammar: reword
per app.grammarly.com
* grammar: simplify
from app.grammarly.com
* spelling: etc.
* feat: add ephermeral container approach inside pod debug page. (#18754)
* doc: add pod security policy reference link to document. (#18729)
* doc: add pod security policy reference link to document.
* doc: add what's next for pod-security-policy ref.
* Revise version requirements (#18688)
Assume that the reader is running a version of Kubernetes that supports
the Secret resource.
* en: Remove kubectl duplicate example (#18656)
With #16974 and the removal of --include-uninitialized flag, the
second
and third examples of kubectl delete become equal, thus leading to
duplication and being confusing. Suggest to remove the duplicate and
replace it with another example in the future if needed.
Observed in v1.16 and v1.17 documentation.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Fix typo for tasks/access-kubernetes-api/configure-aggregation-layer.md (#18652)
* Unify runtime references (#18493)
- Use the glossary to correctly reference runtimes
- Updated runtime class documentation for CRI-O
- Removed rktlet from runtimes since its EOL
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
* Clean up admission controller deprecation example (#18399)
* sync zh-trans content/zh/docs/concepts/workloads/pods/ephemeral-containers.md (#18883)
* Remove redundant information when deploy flannel on kubernetes include windows node (#18272)
* sync zh-trans content/zh/docs/concepts/workloads/pods/pod-overview.md (#18882)
* partial fix for for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted (#18879)
* see also removed from file 36
* see also removed from file 37
* see also removed from file 38
* see also removed from file 39
* see also removed from file 40
* update zh content/zh/docs/contribute/style/write-new-topic.md (#18859)
* sync zh-trans /docs/concepts/_index.md and /docs/concepts/example-concept-template.md (#18863)
* See also removed file 56 & 57 (#18912)
* see also removed file 56
* see also removed file 57
* Third Korean L10n Work For Release 1.17 (#18915)
* Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668)
* Update to Outdated files in dev-1.17-ko.3 branch. (#18580)
* Translate content/ko/docs/concepts/services-networking/service in Korean (#18195)
* Translate docs/tasks/access-application-cluster/port-forward-access-application-cluster.md in Korean (#18721)
* Translate controllers/garbage-collection.md in Korean. (#18595)
Co-Authored-by: Seokho Son <shsongist@gmail.com>
Co-Authored-by: Lawrence Kay <lkay9495@hotmail.com>
Co-Authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-Authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
* clean up makefile, config (#18517)
Added target for createversiondirs (shell script) in Makefile.
updates for tagged release
regenerate api ref, rm Makefile_temp
add parens to pip check
* Improve Russian translation of Home page (#17841)
* Improve Russian translation of Home page
* Update i18n/ru.toml
Co-Authored-By: Slava Semushin <slava.semushin@gmail.com>
* Update content/ru/_index.html
Co-Authored-By: Slava Semushin <slava.semushin@gmail.com>
* Update content/ru/_index.html
Co-Authored-By: Slava Semushin <slava.semushin@gmail.com>
Co-authored-by: Slava Semushin <slava.semushin@gmail.com>
* update ref link for v1.16 (#18837)
Related to issue #18820.
remove links to prev API refs
* Cleanup user journeys related configs and scripts (#18814)
* See also removed file 81 to 85 (#18909)
* see also removed file 81
* see also removed file 82
* see also removed file 83
* see also removed file 84
* see also removed file 85
* See also removed file 65 to 70 (#18908)
* see also removed file 65
* see also removed file 66
* see also removed file 67
* see also removed file 68
* see also removed file 69
* see also removed file 70
* Translate Task index page into Polish (#18876)
Co-Authored-By: Karol Pucyński <kpucynski@gmail.com>
Co-Authored-By: Michał Sochoń <kaszpir@gmail.com>
Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com>
Co-authored-by: Michał Sochoń <kaszpir@gmail.com>
* Document dry-run authorization requirements (#18235)
* Document dry-run write access requirement.
- Add section on dry-run authorization
- Refer to dry-run authorization for diff
- Consistently hyphenate dry-run
* Update content/en/docs/reference/using-api/api-concepts.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* reword storage release note to match the change in k/k PR #87090 (#18921)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18868)
* See also removed file 60 to 63 (#18907)
* see also removed file 60
* see also removed file 61
* see also removed file 62
* see also removed file 63
* See also removed file 91 to 95 (#18910)
* see also removed file 91
* see also removed file 93
* see also removed file 94
* see also removed file 95
* content/zh/docs/concepts/workloads/pods/podpreset.md (#18870)
* fix: fixed eating initial 2 spaces inside code. (#18914)
* Update Calico section of kubeadm install guide (#18821)
* Update Calico section of kubeadm install guide
* Address review feedback
* See also removed file 96 to 100 (#18911)
* see also removed file 96
* see also removed file 97
* see also removed file 98
* see also removed file 99
* see also removed file 100
* repair zh docs in kubeadm (#18949)
* repair zh docs about kubeadm (#18950)
* Update apparmor.md (#18951)
* Update basic-stateful-set.md (#18952)
* Add missing hyperlink for pod-overhead (#18936)
* Update service.md (#18480)
make article reads more smoothly
* zh-trans update content/zh/docs/concepts/workloads/controllers/deploy… (#18657)
* zh-trans update content/zh/docs/concepts/workloads/controllers/deployment.md
* zh-trans update content\zh\docs\concepts\workloads\controllers\deployment.md
* Update source-ip documentation (#18760)
* sync zh-trans /docs/concepts/workloads/pods/pod.md (#18880)
* sync zh-trans /docs/concepts/workloads/controllers/cron-jobs.md and /docs/concepts/workloads/controllers/daemonset.md (#18864)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18867)
* Add a French version of Secret concept page (#18604)
* Add a French version of Secret concept page
* Fix
* Fix
* Update content/fr/docs/concepts/configuration/secret.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fix
* Update content/fr/docs/concepts/configuration/secret.md
Co-Authored-By: Aurélien Perrier <aperrier@universe.sh>
* Fix
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Aurélien Perrier <aperrier@universe.sh>
* (refactor): Corrections (grammatical) in service.md file (#18944)
* Update service.md
* Fixed the invaild changes
Signed-off-by: Udit Gaurav <uditgaurav@gmail.com>
* Update container-runtimes.md (#18608)
for debian install of docker, also install gnupg2 for apt-key add to work
* Fix that dual-stack does not require Kubenet specifically (#18924)
* Fix that dual-stack does not require Kubenet specifically
Rather it requires a network plugin that supports dual-stack, and
others are available, including Calico.
* Update content/en/docs/tasks/network/validate-dual-stack.md
Added link to doc about network plugins
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Revert "Configurable Scaling for the HPA (#18157)" (#18963)
This reverts commit 5dbfaafe1a.
* Update horizontal-pod-autoscale-walkthrough.md (#18960)
Update command for creating php-apache deployment due to the following warning: `kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.`
* doc: add link for type=LoadBalancer service in tutorial. (#18916)
* Typo fix (#18830)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/statefulset.md (#18869)
* Revise pull request template (#18744)
* Revise pull request template
* Reference compiled docs in PR template
Refer readers to https://k8s.io/contribute/start/
This keeps the template short, and it lets Hugo use templating for
the current version.
* Update certificates.md (#18970)
* Add web-ui-dashboard to French (#17974)
* Add web-ui-dashboard to French
* Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fix
* Fix
* Fix
* Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
* Fix
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Added a translated code of conduct (#18981)
* Added a translated code of conduct
* fixed some minor mistakes and capitalization
* Moved to informal speech
* Translate the contribute advanced page to French (#13425)
* Translate the contribute advanced page to French
* Corrections
* Correction
* Correction
* Correction
* Correction
* Correction
* Fix typo in hello-minikube.md (#18991)
* Add note for LB behaviour for cordoned nodes. (#18784)
* Add note for LB behaviour for cordoned nodes.
See also https://github.com/kubernetes/kubernetes/issues/65013
This is a reasonably common pitfall: `kubectl cordon <all nodes>` will also drop all LB traffic to the cluster, but this is not documented anywhere but in issues, when found it is usually already too late.
* Update with feedback
* Add KIND as the options for spinning up a test kubernetes environment (#17860)
* fix typo in /ja/docs/concepts/workloads/pods/init-containers (#18997)
* hide some original comments in translate docs (#18986)
* hide original comment
* hide some original comments
* Fix code of conduct title (#19006)
* Added a note about built-in priority-classes (#18979)
* Added a note about build-in priority-classes
* Update content/en/docs/concepts/configuration/pod-priority-preemption.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Add description for TTL (#19001)
* Fix whitespace on deployment page (#18990)
* Add details to the API deprecations blog post (#19014)
* Document list/map/structType and listMapKeys (#18977)
These markers where introduced to describe topology of lists, maps,
structs - primarily in support of server-side apply.
Secondarily, a small typo fix:)
* Remove "Unschedulable" pod condition type from the pod lifecycle docs (#18956)
The pod lifecycle documentation erroneously indicated `Unschedulable` as a possible `type` of pod condition. That's not true. Only four condition types exist. The `Unschedulable` value is not a type, but one of the possible reasons of the `PodScheduled` condition type.
* Revise “Encrypting Secret Data at Rest” (#18810)
* Drop reference to old Kubernetes versions
At the time of writing, Kubernetes v1.13 is the oldest supported
version, and encryption-at-rest is no longer alpha.
* Tidy whitespace
* Add table caption
* Set metadata for required Kubernetes version
* maintain the current relative path when switching to other site versions (#18871)
* Update kubectl create configmap section (#18885)
* Add common examples to Service Topology documentation (#18712)
* service topology: add missing 'enabling service topology' page
Signed-off-by: Andrew Sy Kim <kiman@vmware.com>
* service topology: add common examples
Signed-off-by: Andrew Sy Kim <kiman@vmware.com>
* updating contrib for ref docs (#18787)
more cleanup
* fix translate docs format (#19018)
* Update nodes.md (#19019)
* Translate Contribute index page into Russian (#19022)
* Added german translation for Addons page (#19010)
* Added german translation for Addons page
* Smaller adjustments
* removed a english leftover-sentence
* consistent spelling of "Add-Ons"
* Removed english entry for CoreDNS
* Update content/de/docs/concepts/cluster-administration/addons.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Translated a heading
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* (fix) Removed `-n test` from `kubectl get pv` command (#18877)
- PV are cluster scoped rather than namespaced scope
- So, there is no need to list it by namespace
Signed-off-by: Aman Gupta <aman.gupta@mayadata.io>
* Link to setup page about Kind (#18996)
Link from /docs/setup/ to /docs/setup/learning-environment/kind/ now
that the target page exists.
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#18808)
* Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-Authored-By: Bob Killen <killen.bob@gmail.com>
* Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
* Update and rename Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md to 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md
Co-authored-by: Bob Killen <killen.bob@gmail.com>
Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com>
* Revise glossary entry for Device Plugin (#16291)
* Document control plane monitoring (#17578)
* Document control plane monitoring
* Update content/en/docs/concepts/cluster-administration/monitoring.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/concepts/cluster-administration/monitoring.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Merge controller-metrics.md into monitoring.md
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Document none driver compatibility with non docker runtime. (#17952)
* Refined unclear sentence on 3rd party dependencies (#18015)
* Refined unclear sentence on 3rd party dependencies
I reworded the sentence on third party dependencies a bit in order to make it more sound
* Update content/en/docs/concepts/security/overview.md
Sounds much better
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Improve network policies concept (#18091)
* Adopt website style guidelines
* Tweak wording
Co-Authored-By: cmluciano <cmluciano@cruznet.org>
* Make sample NetworkPolicies downloadable
Co-authored-by: cmluciano <cmluciano@cruznet.org>
* clean up secret generators (#18320)
* Use built-in version check & metadata (#18542)
* Reword kubelet live reconfiguration task (#18629)
- Revise version requirements
- Use glossary tooltips in summary
- Use sentence case for headings
- Write kubelet in lowercase where appropriate
- Add “What's next” section
* fix: add dns search record limit note. (#18913)
* Remove duplicate content: Roles & Responsibilities (#18920)
* Remove duplicate content: Roles & Responsibilities
Signed-off-by: Celeste <celeste@cncf.io>
Address feedback
Signed-off-by: Celeste <celeste@cncf.io>
* Apply suggestions from review
Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com>
* Link to contribution guidelines
Signed-off-by: Celeste Horgan <celeste@cncf.io>
* Address PR feedback
Signed-off-by: Celeste Horgan <celeste@cncf.io>
Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com>
* Fix of pull request #18960 (#18974)
* Fix of pull request #18960
* Add yaml configuration file snippets
* Remove redundant code snippet for command
* Update cheatsheet.md (#18975)
* Update cheatsheet.md
"List all pods in the namespace, with more details" command corrected by adding --all-namespaces
* Update content/en/docs/reference/kubectl/cheatsheet.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Correct description of Knitter CNI plugin (#18983)
* Add Elastic metricbeat to examples of DaemonSets and rename logstash (#19024)
* Add Elastic metricbeat to examples of DaemonSets
The URL points to the docs related to how to configure metricbeat on k8s
* Filebeat is the next thing
* Separated commands from output (#19023)
* Update KubeCon URLs (#19027)
The URLs had changed (and were being redirected). Also, added parameters to better identify the traffic source.
* remove see also and close issue (#19032)
* sync zh-trans content/zh/docs/concepts/workloads/controllers/garbage-collection.md (#18865)
* zh trans /docs/reference/access-authn-authz/extensible-admission-controllers.md (#18856)
* Update zh/docs/concepts/services-networking/dns-pod-service.md#pods (#18992)
* Adding contribution best practice in contribute docs (#18059)
* Add kubectl patch example with quotes on Windows (#18853)
* Add kubectl patch example with quotes on Windows
When running the `kubectl patch` example, on Windows systems you get an
error when passing the patch request in single quotes. Passing it in
double quotes with the inner ones escaped produced the desired behavior
as is in the example given for Linux systems. I've added a small note
for Windows users to have that in mind.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Use Hugo note shortcode
Windows note is placed inside a
[shortcode](https://kubernetes.io/docs/contribute/style/style-guide/#shortcodes)
to be consistent with the style guide.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Remove shell Markdown syntax
I've removed the shell syntax from the Windows example and have changed
the description to be the same as the one used in
[jsonpath](https://kubernetes.io/docs/reference/kubectl/jsonpath/)
document to be more consistent. The jsonpath example uses cmd syntax,
though it is note inside a note shortcode, therefore I've opted out of
using any syntax as it seems to break rendering inside the shortcode.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Add cmd markdown syntax and fix order list
I've tested this locally with `make docker-serve` on my Linux machine
and finally things are looking better, I've managed to address these two
issues:
- the Windows example is now inside `note` shortcode and also the cmd
syntax renders correctly on the page
- the list of steps broke after the first one, I've indented a paragraph
and now the steps are in the expected order
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Remove command prompt from example
According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included when showing an example. This commit removes it for consistency with the style guide.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* cleanup /docs/concepts/workloads/pods/pod-lifecycle/ (#19009)
* update nodes.md (#18987)
将“用量低”更改为“可用量低”，避免歧义
* Remove command prompt from Windows example (#18906)
* Remove command prompt from Windows example
According to the [style
guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt),
the command prompt should not be included in the examples. Removing the
Windows command prompt from the jsonpath example.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Put Windows example inside note shortcode
I'm putting the Windows example in a Hug note shortcode to be consistent
with the rest of the documentation.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Updated CHANGELOG-11 link (#19036)
* update command used to create deployment (#19005)
The previous one was showing a deprecation warning when used.
* Update Korean localization guide (#19004)
rev1-Update Korean localization guide
* docs: fix broken etcd's official documents link (#19021)
* Update automated-tasks-with-cron-jobs.md (#19043)
Co-authored-by: Xin Chen <xchen@opq.com.au>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: lemon <lemonli@users.noreply.github.com>
Co-authored-by: Slava Semushin <slava.semushin@gmail.com>
Co-authored-by: Olivier Cloirec <5033885+clook@users.noreply.github.com>
Co-authored-by: inductor <kohei.ota@zozo.com>
Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com>
Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com>
Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp>
Co-authored-by: Keita Akutsu <kakts.git@gmail.com>
Co-authored-by: Masa Taniguchi <maabou512@gmail.com>
Co-authored-by: Soto Sugita <sotoiwa@gmail.com>
Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com>
Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com>
Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com>
Co-authored-by: hato wang <26351545+wyyxd2017@users.noreply.github.com>
Co-authored-by: xieyanker <xjsisnice@gmail.com>
Co-authored-by: zhouya0 <50729202+zhouya0@users.noreply.github.com>
Co-authored-by: littleboy <zhaoze01@inspur.com>
Co-authored-by: camper42 <camper.xlii@gmail.com>
Co-authored-by: Dominic Yin <hi@ydcool.me>
Co-authored-by: Steve Bang <stevebang@gmail.com>
Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com>
Co-authored-by: Ryan McGinnis <ryanmcginnis@users.noreply.github.com>
Co-authored-by: Shunde Zhang <shunde.p.zhang@gmail.com>
Co-authored-by: Bob Killen <killen.bob@gmail.com>
Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com>
Co-authored-by: Patrick Ohly <patrick.ohly@intel.com>
Co-authored-by: Eugenio Marzo <eugenio.marzo@yahoo.it>
Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com>
Co-authored-by: TimYin <shiguangyin@inspur.com>
Co-authored-by: Shivang Goswami <shivang.goswami@infosys.com>
Co-authored-by: Fabian Baumanis <fabian.baumanis@gmx.de>
Co-authored-by: Rémy Léone <remy.leone@gmail.com>
Co-authored-by: chentanjun <tanjunchen20@gmail.com>
Co-authored-by: helight <helight@helight.info>
Co-authored-by: Jie Shen <drfish.me@gmail.com>
Co-authored-by: Joe Betz <jpbetz@google.com>
Co-authored-by: Danni Setiawan <danninov@users.noreply.github.com>
Co-authored-by: GoodGameZoo <gaoguangze111@gmail.com>
Co-authored-by: makocchi <makocchi@gmail.com>
Co-authored-by: babang <prabangkoro@users.noreply.github.com>
Co-authored-by: Sharjeel Aziz <sharjeel.aziz@gmail.com>
Co-authored-by: Wojtek Cichoń <wojtek.cichon@protonmail.com>
Co-authored-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
Co-authored-by: Maciej Filocha <12587791+mfilocha@users.noreply.github.com>
Co-authored-by: Michał Sochoń <kaszpir@gmail.com>
Co-authored-by: Yudi A Phanama <11147376+phanama@users.noreply.github.com>
Co-authored-by: Giovan Isa Musthofa <giovanism@outlook.co.id>
Co-authored-by: Park Sung Taek <tjdxor8223@gmail.com>
Co-authored-by: Kyle Smith <kylessmith@protonmail.com>
Co-authored-by: craigbox <craig.box@gmail.com>
Co-authored-by: Afrizal Fikri <laser.survivor@gmail.com>
Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com>
Co-authored-by: Anshu Prateek <333902+anshprat@users.noreply.github.com>
Co-authored-by: Sergei Zyubin <sergei@crate.io>
Co-authored-by: Christoph Blecker <admin@toph.ca>
Co-authored-by: Brad Topol <btopol@us.ibm.com>
Co-authored-by: Venkata Harshavardhan Reddy Allu <venkataharshavardhan_ven@srmuniv.edu.in>
Co-authored-by: KYamani <yamani.kamel@gmail.com>
Co-authored-by: Trishank Karthik Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com>
Co-authored-by: Jacky Wu <Colstuwjx@gmail.com>
Co-authored-by: Gerasimos Dimitriadis <gedimitr@gmail.com>
Co-authored-by: Rajat Toshniwal <rnt.rajat@gmail.com>
Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
Co-authored-by: Sascha Grunert <sgrunert@suse.com>
Co-authored-by: wawa <xiaozhang0210@hotmail.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Karen Bradshaw <kbhawkey@gmail.com>
Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com>
Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com>
Co-authored-by: Julian V. Modesto <julianvmodesto@gmail.com>
Co-authored-by: Jeremy L. Morris <jeremylevanmorris@gmail.com>
Co-authored-by: Casey Davenport <caseydavenport@users.noreply.github.com>
Co-authored-by: zhanwang <zhanw15@gmail.com>
Co-authored-by: wwgfhf <51694849+wwgfhf@users.noreply.github.com>
Co-authored-by: harleyliao <357857613@qq.com>
Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com>
Co-authored-by: Aurélien Perrier <aperrier@universe.sh>
Co-authored-by: UDIT GAURAV <35391335+uditgaurav@users.noreply.github.com>
Co-authored-by: Rene Luria <rene@luria.ch>
Co-authored-by: Neil Jerram <neiljerram@gmail.com>
Co-authored-by: Arjun <arjunrn@users.noreply.github.com>
Co-authored-by: Katarzyna Kańska <katarzyna.m.kanska@gmail.com>
Co-authored-by: Laurens Versluis <lfdversluis@users.noreply.github.com>
Co-authored-by: Ray76 <rayfoo55@gmail.com>
Co-authored-by: Alexander Zimmermann <7714821+alexzimmer96@users.noreply.github.com>
Co-authored-by: Christian Meter <cmeter@googlemail.com>
Co-authored-by: MMeent <boekewurm@gmail.com>
Co-authored-by: RA489 <rohit.anand@india.nec.com>
Co-authored-by: Akira Tanimura <autopp.inc@gmail.com>
Co-authored-by: Patouche <Patouche@users.noreply.github.com>
Co-authored-by: Jordan Liggitt <jordan@liggitt.net>
Co-authored-by: Maria Ntalla <maria.ntalla@gmail.com>
Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Co-authored-by: John Morrissey <jwm@horde.net>
Co-authored-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
Co-authored-by: ngsw <ngsw@ngsw.jp>
Co-authored-by: Aman Gupta <aman.gupta@mayadata.io>
Co-authored-by: Marek Siarkowicz <marek.siarkowicz@protonmail.com>
Co-authored-by: tom1299 <tom1299@users.noreply.github.com>
Co-authored-by: cmluciano <cmluciano@cruznet.org>
Co-authored-by: Celeste Horgan <celeste@cncf.io>
Co-authored-by: Prasad Honavar <prasadhonavar@gmail.com>
Co-authored-by: Sam <sammcj@users.noreply.github.com>
Co-authored-by: Victor Martinez <victormartinezrubio@gmail.com>
Co-authored-by: Dan Kohn <dan@linuxfoundation.org>
Co-authored-by: vishakha <54327666+vishakhanihore@users.noreply.github.com>
Co-authored-by: liyinda246 <liyinda0000@163.com>
Co-authored-by: Kabir Kwatra <kabir@kwatra.me>
Co-authored-by: Armand Grillet <2117580+armandgrillet@users.noreply.github.com>
Co-authored-by: Junwoo Ji <jydrogen@gmail.com>
Co-authored-by: rm <rajib.jolite@gmail.com>
* Remove command prompt from Windows example
According to the [style
guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt),
the command prompt should not be included in the examples. Removing the
Windows command prompt from the jsonpath example.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Put Windows example inside note shortcode
I'm putting the Windows example in a Hug note shortcode to be consistent
with the rest of the documentation.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Add kubectl patch example with quotes on Windows
When running the `kubectl patch` example, on Windows systems you get an
error when passing the patch request in single quotes. Passing it in
double quotes with the inner ones escaped produced the desired behavior
as is in the example given for Linux systems. I've added a small note
for Windows users to have that in mind.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Use Hugo note shortcode
Windows note is placed inside a
[shortcode](https://kubernetes.io/docs/contribute/style/style-guide/#shortcodes)
to be consistent with the style guide.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Remove shell Markdown syntax
I've removed the shell syntax from the Windows example and have changed
the description to be the same as the one used in
[jsonpath](https://kubernetes.io/docs/reference/kubectl/jsonpath/)
document to be more consistent. The jsonpath example uses cmd syntax,
though it is note inside a note shortcode, therefore I've opted out of
using any syntax as it seems to break rendering inside the shortcode.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Add cmd markdown syntax and fix order list
I've tested this locally with `make docker-serve` on my Linux machine
and finally things are looking better, I've managed to address these two
issues:
- the Windows example is now inside `note` shortcode and also the cmd
syntax renders correctly on the page
- the list of steps broke after the first one, I've indented a paragraph
and now the steps are in the expected order
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Remove command prompt from example
According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included when showing an example. This commit removes it for consistency with the style guide.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Add Elastic metricbeat to examples of DaemonSets
The URL points to the docs related to how to configure metricbeat on k8s
* Filebeat is the next thing
* Update cheatsheet.md
"List all pods in the namespace, with more details" command corrected by adding --all-namespaces
* Update content/en/docs/reference/kubectl/cheatsheet.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
- Revise version requirements
- Use glossary tooltips in summary
- Use sentence case for headings
- Write kubelet in lowercase where appropriate
- Add “What's next” section
* Refined unclear sentence on 3rd party dependencies
I reworded the sentence on third party dependencies a bit in order to make it more sound
* Update content/en/docs/concepts/security/overview.md
Sounds much better
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Added german translation for Addons page
* Smaller adjustments
* removed a english leftover-sentence
* consistent spelling of "Add-Ons"
* Removed english entry for CoreDNS
* Update content/de/docs/concepts/cluster-administration/addons.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Translated a heading
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* service topology: add missing 'enabling service topology' page
Signed-off-by: Andrew Sy Kim <kiman@vmware.com>
* service topology: add common examples
Signed-off-by: Andrew Sy Kim <kiman@vmware.com>
* Drop reference to old Kubernetes versions
At the time of writing, Kubernetes v1.13 is the oldest supported
version, and encryption-at-rest is no longer alpha.
* Tidy whitespace
* Add table caption
* Set metadata for required Kubernetes version
The pod lifecycle documentation erroneously indicated `Unschedulable` as a possible `type` of pod condition. That's not true. Only four condition types exist. The `Unschedulable` value is not a type, but one of the possible reasons of the `PodScheduled` condition type.
These markers where introduced to describe topology of lists, maps,
structs - primarily in support of server-side apply.
Secondarily, a small typo fix:)
* Added a note about build-in priority-classes
* Update content/en/docs/concepts/configuration/pod-priority-preemption.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Add note for LB behaviour for cordoned nodes.
See also https://github.com/kubernetes/kubernetes/issues/65013
This is a reasonably common pitfall: `kubectl cordon <all nodes>` will also drop all LB traffic to the cluster, but this is not documented anywhere but in issues, when found it is usually already too late.
* Update with feedback
* Revise pull request template
* Reference compiled docs in PR template
Refer readers to https://k8s.io/contribute/start/
This keeps the template short, and it lets Hugo use templating for
the current version.
Update command for creating php-apache deployment due to the following warning: `kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.`
* Fix that dual-stack does not require Kubenet specifically
Rather it requires a network plugin that supports dual-stack, and
others are available, including Calico.
* Update content/en/docs/tasks/network/validate-dual-stack.md
Added link to doc about network plugins
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* see also removed file 65
* see also removed file 66
* see also removed file 67
* see also removed file 68
* see also removed file 69
* see also removed file 70
* see also removed from file 36
* see also removed from file 37
* see also removed from file 38
* see also removed from file 39
* see also removed from file 40
- Use the glossary to correctly reference runtimes
- Updated runtime class documentation for CRI-O
- Removed rktlet from runtimes since its EOL
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
With #16974 and the removal of --include-uninitialized flag, the
second
and third examples of kubectl delete become equal, thus leading to
duplication and being confusing. Suggest to remove the duplicate and
replace it with another example in the future if needed.
Observed in v1.16 and v1.17 documentation.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* kubeadm: improvements to the cert management documentation (#18397)
- move the sections about custom certificates and external CA
to the kubeadm-certs page
- minor cleanups to the kubeadm-certs page, including updated output
for the check-expiration command
- link the implementation details page to the new locations
for custom certs and external CA
* fix doc conflict regarding postStart
* Fix small typos
Small typos noticed and fixed in:
- configure-upgrade-etcd.md
- reconfigure-kubelet.md
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Rephrase a paragraph on etcd upgrade
en\docs\tasks\administer-cluster\configure-upgrade-etcd.md
Following a suggestion in #18886, I've rephrased a sentence on etcd
upgrade prerequisites.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
In Kubernetes docs, all of the packages that are required to set up the
Kubernetes are installed without requiring any prompts through
the package manager (like apt or yum) except for the container runtimes.
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
So, it would be better to have these installations with prompts (yes) disabled.
The phrase `very larger` is not valid, it is supposed to be either `very
large` or `larger`. Propose to have it `very large`.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Add additional ways to contribute part to update zh doc
* Add original English text
* Update content/zh/docs/contribute/_index.md
Co-Authored-By: chentanjun <tanjunchen20@gmail.com>
Co-authored-by: chentanjun <tanjunchen20@gmail.com>
* csi-ephemeral-inline-volumes: introduce CSI support for ephemeral inline volumes
This was alpha in Kubernetes 1.15 and became beta in 1.16. Several CSI
drivers already support it (soon...).
* csi-ephemeral-inline-volumes: bump date and address feedback (NodeUnpublishVolume)
* csi-ephemeral-inline-volumes: add examples and next steps
* csi-ephemeral-inline-volumes: rename file, minor edits
* csi-ephemeral-inline-volumes: include Docker example
Tiny fix
Feedback from onlydole
Add missing link
Incremental fixes
Revise Jim's job title
Update content/en/blog/_posts/2020-01-17-Docs-Review-2019.md
Co-Authored-By: Celeste Horgan <celeste@cncf.io>
Feedback from celeste, change date
* Fixed outdated ECR credential debug message
The log message for troubleshooting kubelet auto fetching ECR credentils issue has been changed (noticed since 1.14), and the new message reads like this when verbose log level is set to 3:
- `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
- `aws_credentials.go:116] Got ECR credentials from ECR API for <Your ECR AWS Account ID>.dkr.ecr.us-east-1.amazonaws.com`
This is based on the kubelet source code:
https://github.com/kubernetes/kubernetes/blob/release-1.14/pkg/credentialprovider/aws/aws_credentials.go#L91
This PR is to fix this and to avoid confusion for more people who are troubleshooting the kubelet ECR issue.
* Update content/en/docs/concepts/containers/images.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
On the page, it says `as you .KUBECONFIG` whereas it is meant `as your
.KUBECONFIG`. Minor annoyance, but still benefits fixing. One char PR.
Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com>
* Added a new section on Azure CNI
Azure provides a CNI for native integration of Kubernetes Pods in a Virtual Network. I have added a short description of this CNI and provided links to important documentation
* Update networking.md
* Made updates based on comments
This is much closer to what you are recommending. Please take a look
The kubeadm survey for 1.13:
https://docs.google.com/forms/d/1A855D054FZfdvNbx6mAa54tcZ204GmPCIhxe1UrXKd8/edit#responses
The kubeadm survey for 1.13:
https://docs.google.com/forms/d/1A855D054FZfdvNbx6mAa54tcZ204GmPCIhxe1UrXKd8/edit#responses
Revealed the top 3 plugins in terms of popularity are:
Flannel
Calico
WeaveNet
The kubeadm maintainers are in contact with the maintainers
of these plugins and can provide support and updates to this guide.
The rest of the plugins in the guide are unmaintained, by the kubeadm team!
Some plugins are not in the CNCF landscape, or maintained by the kubeadm team, but still
present in the guide.
Remove the following non-CNCF / unmaintained plugins:
AWS VPC
Romana
Juniper*
Canal (it is an alternative to Calico and already explained in the
Calico guide)
Add note that users can still defer to this page for more options and a more complete list:
https://kubernetes.io/docs/concepts/cluster-administration/networking/Revealed the top 3 plugins in terms of popularity are:
- Flannel
- Calico
- WeaveNet
The kubeadm maintainers are in contact with the maintainers
of these plugins and can provide support and updates to this guide.
Some plugins are not in the CNCF landscape, but still
covered in this page:
https://kubernetes.io/docs/concepts/cluster-administration/networking/
Remove the following non-CNCF plugins:
- AWS VPC
- Romana
- Juniper*
- Canal (it is an alternative to Calico and already explained in the
Calico guide)
Add note that users can still defer to this page for more options:
https://kubernetes.io/docs/concepts/cluster-administration/networking/
* Use Control Plane instead of Master
* improve image. The SVG was not matching the PNG, so I basically had to re-create it from scratch. I kept the visual similarities as mush as possible
* remove tautological phrase
* fix glossary references as well
* improve cluster glossary to move from Master to Control Plane
* improve english form
As I will be part of kubernetes 1.18 docs release team. Approve permissions will help me in approving the 1.18 docs enhnacemnts.
Signed-off-by: vineeth <vineethpothulapati@outlook.com>
* Fix pod status phases + more
A number of improvements introduced in the glossary entry for Pod Lifecycle
* Completed / CrashLoopBackOff were removed from the list of pod status phases
* The link to PodStatus in the generated kubernetes api was parametrized regarding version
* Minor editorial changes
* Rework Pod Lifecycle entry to better describe term
The term definition was reworked after the review comments from
kbhawkey
* Looping over logs of all jobs using a single command
Using the label constuct `-l` to loop over output of all jobs (or pods) using a single command
* Update content/en/docs/tasks/job/parallel-processing-expansion.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Add descriptions of CPU and Memory metrics
* Update content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* address comments
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Update kubernetes-api.md
Updated the docs to reflect a change that has already been made in v1.14 instead of going to be made in v1.14 with us being at v1.16 now.
* Update content/en/docs/concepts/overview/kubernetes-api.md
Co-Authored-By: Barnabas Makonda <6409210+makoscafee@users.noreply.github.com>
Co-authored-by: Barnabas Makonda <6409210+makoscafee@users.noreply.github.com>
* Update scheduling-hugepages.md
Correcting the yaml file contents, verified the pod deployment
* Update content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
DNS debugging documentation is using a busybox image as example.
This image has different known issues with the way it resolves
the DNS names in k8s, creating confusion with users that try to
follow the docs.
The e2e tests use a custom small image ~4.3MB for DNS testing
with all the necessary tools. Also, the fact that this image is
being used for the k8s e2e testing guarantees it's compatibility.
Initial commit for Polish localization
* Translation style reviewed and improved by:
Michał Sochoń <kaszpir@gmail.com>
Karol Pucyński <kpucynski@gmail.com>
with contribution from Wojciech Kocjan <wojciech@kocjan.org>
* Kubernetes slogan translated by Karol Pucyński
* Corectness of non-language-specific content reviewed and improved by:
Tim Bannister <tim@scalefactory.com>
* Add tooltip for addons in Hello Minikube page
* Update glossary title and add more descriptive info
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Extend Cilium CNI plugin description
Mention that it works on top of other CNI plugins due to the CNI
chaining [1].
[1]: http://docs.cilium.io/en/v1.6/gettingstarted/cni-chaining/
Signed-off-by: Martynas Pumputis <m@lambda.lt>
* Update Cilium installation steps for kubeadm
- Use the latest v1.6 Cilium.
- By default, Cilium no longer needs/deploys ETCD store.
Signed-off-by: Martynas Pumputis <m@lambda.lt>
* Update Cilium NetworkPolicy guide
- Update minikube min version requirement.
- Use Cilium v1.6.
- Remove the etcd store bits, as Cilium v1.6 no longer depend on
it by default.
Signed-off-by: Martynas Pumputis <m@lambda.lt>
* Update Cilium installation steps for kubeadm
- How to run without kube-proxy.
Signed-off-by: Martynas Pumputis <m@lambda.lt>
Co-authored-by: Martynas Pumputis <m@lambda.lt>
* Exchanged developers with containers
The meaning of original sentence: "Coordinating ports across multiple **developers** is very difficult to do at scale..." is not really obvious. From what I understand from the context of this page, the term **containers** would make more sense, because the context in this paragraph is on containers and ports rather than developers.
* Clarify terms developer and container
Rephrased statement on port coordination to make
it claerer that the ports are part of the
containers provided by developers or teams.
* Update content/en/docs/concepts/services-networking/connect-applications-service.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* content/ru/docs/tutorials/hello-minikube.md: minor improvements.
* Update Hello Minikube tutorial to use Metrics Service and not Heapster
Co-authored-by: Ben Hall <ben@benhall.me.uk>
Co-authored-by: Ben Hall <Ben@Benhall.me.uk>
changes for #14526 had either a stray "for a" or missed "service" as in "for a service".
Since it's quite lengthy and "for a service" is unnecessary in service.md, I opted to removed it.
* Specify minimum Kubernetes version for Job tasks
Ask for v1.8 because CronJob went beta in v1.8 and some of the Job pages
reference CronJob.
* Drop version check from Job / CronJob task pages.
Assume that readers have Kubernetes v1.8 or newer.
* Added Azure Application Gateway Ingress Controller
Added Azure AppGW Ingress Controller (AGIC) to the list of additional controllers now that it has gone GA.
* Update content/en/docs/concepts/services-networking/ingress-controllers.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
- Update to Outdated files in dev-1.17-ko.2 branch. (#18236)
- Update path of referenced links in translated documents - 1.17 (#18282)
- Use original text for a code (#18358)
- Updates to documents that do not reflect the original text - 1.17 (#18270)
- Translate services-networking/dual-stack.md in Korean. (#18251)
- Update cluster-large.md (#18232)
- Translate services-networking/network-policies.md in Korean. (#18269)
- Modify reference links for translated documents added from previous branches. (#18432)
- Translate docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md in Korean (#18484)
Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: Jmnote <opcore@gmail.com>
Co-Authored-By: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr>
Co-authored-by: Jmnote <opcore@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
* Improve CronJob page
This PR adds a note about the special constraint on CronJob names. The
contstraint is not captured in the API specification or anywhere else to
my knownledge.
* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
English version:
The fourth example selects all resources without a label with key `partition`; no values are checked.
Chinese version:
第三个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。
Fix version:
第四个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。
As I will be part of kubernetes 1.18 docs release team. Approve permissions will help me in approving the 1.18 docs enhnacemnts.
Signed-off-by: vineeth <vineethpothulapati@outlook.com>
When a localization user uses diff_l10n_branches.py,
the directory of content on 'Proposed Solution' is fixed.
Thus, this commit changes the directory name according to the l10n language.
I noticed this https://www.base64encode.org/ Tool is not working in the safari browser, So I added alternative tool that I found is working on safari and another browser.
Please Check Link that I added :)
Thanks
I searched for obvious replacements using Google, but did not see any.
(I don't want to hyperlink to blog posts, as blogs don't come with any
commitment for someone to keep them current).
The earlier E2E blog post touch on some of these aspects, but was more
focused on writing a custom test suite. Using the existing tests
unchanged may be simpler and sufficient. Because it is not that
well-known yet, a blog post seems useful.
* Add Contribute index page for Indonesian localization
* Update Indonesian Contribute index
* Fix indonesian contribute docs path
* Changes to id contribute docs wordings
- Changed noun to verb in content/id/docs/home/_index.md
- Sync wordings in content/id/docs/contribute/_index.md with content/id/docs/home/_index.md
- Wording improvement for content/id/docs/contribute/_index.md
* Fix a typo in id contribute index
* Add Indonesian Translation for Security Overview
* Updates to Security Overview Indonesian translation
Signed-off-by: Yudi A Phanama <yudiandreanp@gmail.com>
- move the sections about custom certificates and external CA
to the kubeadm-certs page
- minor cleanups to the kubeadm-certs page, including updated output
for the check-expiration command
- link the implementation details page to the new locations
for custom certs and external CA
* Update cluster health check command for newer etcd
Existing docs assume the older (v3.2) etcdctl `health-check` command but with a 3.4.3 cluster (which is what kubeadm creates in the static manifest now), that subcommand is no longer supported and returns 404 errors like:
```
root@etcd-1:~# docker run --rm -it --net host -v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl --cert-file /etc/kubernetes/pki/etcd/peer.crt --key-file /etc/kubernetes/pki/etcd/peer.key --ca-file /etc/kubernetes/pki/etcd/ca.crt --endpoints https://10.170.68.181:2379 cluster-health
cluster may be unhealthy: failed to list members
Error: unexpected status code 404
```
* PR review changes
* Adding helm3 command
helm3 doesn't have name flag hence above command fails when user is using helm3(which is latest in its kind)
* adding tab for Helm3 and defaulting it
* addressing comments
In 203391835d, an explicit anchor '#noderestriction' was added to the
NodeRestriction section of the Admission Controllers reference document,
which caused the link to the '#NodeRestriction' anchor in the Node
Authorization document to break and lead to the top of the Admission
Controllers document instead of to the NodeRestriction section further
down the page. This change fixes the link to point to the intended
section instead of to the whole page in general.
* adding de docs for images
* Removing lines I cannot make sense off right now :
* Update images.md
* Update images.md
Fixed two typos
Changed a word, meaning was not good enough
* Update images.md
Fixed missing word
Fixed Syntax
* Update images.md
Added missing „t“
* Fixes according to comments
* proposed fix according to comment
* Blog post links (hugo issue)
This commit aims to fix multiple occurrences of issue introduced before
switching blog engine to hugo, after which no blog links with "." was
working.
It's include a huge ammount of links with kubernetes version in it.
This commit also include one or two additional link fixes found while
making changes in attempt to solve current situation.
* Additional fix for Chinese website blog post.
* Update master-node-communication.md
Fixing Typo, adding small linguistic changes.
* Update master-node-communication.md
* Update master-node-communication.md
Added some missing words
Deleted doubled words
Changed to „ß“ from „ss“
Added „bestimmte Artikel (Der...) for better readability, was not in school. since a longer time, but this seems right.
* Update master-node-communication.md
Fixed the "zu absichern"
Fixed "erste" and "zweite" it's written that way in the newer version of German orthography
* Modified link between Korean documents. (#18072)
* Translate services-networking/connect-applications-service.md in Korean. (#18087)
* Translate services-networking/service-topology.md in Korean. (#18096)
* Update to outdated files in the dev-1.17-ko.1 (#18070)
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
This fixes an issue with some text in the SVG diagram not rendering properly on MacOS/Safari. Sspecifically, the "Data Plane" labels were not being properly rendered.
Before/after images (TBD)
* Clarify port selection section
Avoids situation where a beginner is directed to enter the wrong port and has to backtrack and reread.
* Update content/en/docs/tutorials/hello-minikube.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update documentation to reflect Go 1.13 dependency for Kubernetes 1.17+
* Rephrased required Golang version
* Updated french translation to match English Golang version
Without this change, the instruction to "get familiar with" the Pods
concept directs the user to the pods section of the User Guide, which
actually redirects to the "Run a Stateless Application Using a
Deployment" task, which is not strictly about Pods. This change fixes
the link to point to the Pods Overview in the Concepts section, which
makes more sense in this context.
* feat: graduate TaintNodesByCondition to GA (#17073)
* Promote StartupProbe to beta (enabled by default). (#17164)
* Watch bookmarks to GA (#17026)
* feat: graduate ScheduleDaemonSetPods to GA (#17350)
* Update Docker installation instructions (#17405)
* Use exact version numbers for installing Docker in Ubuntu (#17428)
* Move CSIMigration and CSIMigrationGCE to Beta in Kubernetes v1.17 (#17478)
* Promote NodeLease feature to GA (#17189)
* Update docs for csi topology ga (#17408)
* Update RunAsUsername to beta (#17460)
* doc:Update RunAsUsername to beta
* doc: update samples - kubernetes.io/os is no longer beta
* Updating based on review feedback
* Promote Node-specific volume limits to GA (#17432)
* Promote PodShareProcessNamespace to stable (#17192)
* Promote PodShareProcessNamespace to stable
* Add for_k8s_version to feature-state label
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Readd version-check to shareProcessNamespace task
* Update service load balancer finalizer doc for GA (#17438)
* Update Topology Manager docs (#17451)
* Added information on how device plugins can take advantage
of Topology Manager
* Updated the Topology Manager documentation to include additionalinformation and update some out of date sections
* Fix broken Topology Manager link (#17746)
Part of What's Next Device Plugin section
* Update CRD defaulting docs for GA (#17450)
* Add documentation for VolumeSnapshot Beta (#17233)
* Updating EndpointSlice documentation for beta release in 1.17 (#17411)
* (docs/dualstack): v1.17 updates (#17457)
* Add placehold doc updates for dualstack in 1.17
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Add Downward API and /etc/hosts Pod IP validation
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* remove addressed known issue via k/k pr 85246
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Remove known issue and add flag as part of k/k 79993
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* remove follow up placeholders
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Update verbiage
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Make IP addressing consistent throughout the task
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Update to status.podIPs
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Update content/en/docs/tasks/network/validate-dual-stack.md
Use set instead of env
Co-Authored-By: Khaled Henidak (Kal) <khnidk@outlook.com>
* add topology.kubernetes.io/zone, topology.kubernetes.io/region and node.kubernetes.io/instance-type labels to docs (#17498)
Signed-off-by: Andrew Sy Kim <kiman@vmware.com>
* Service topology alpha documentation (#17459)
* Update list of feature flags for in-tree plugins migrated to CSI (#17533)
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update Node concept for TaintNodesByCondition going GA (#17577)
* feat: graduate ResourceQuotaScopeSelectors to GA in 1.17 (#17554)
* kubeadm: update the upgrade documentation for 1.17 (#17587)
* doc: Simplify Windows deployments with RuntimeClass (#16697)
* doc: Simplify Windows deployments with RuntimeClass
* Updating on review feedback
* doc: Adding windows-build label from enhancement 1301
* update doc for kubelet option --reserved-cpus (#17648)
* feat: update TaintNodesByCondition in feature gates table (#17377)
* Update docs for v1 resource quota configuration (#17547)
* AdmissionConfiguration v1 (#17548)
* Update WebhookAdmissionConfiguration examples (#17549)
* Update AWS EBS Migration Feature state (#16126)
* Add resource version section to api-concepts documentation (#16910)
* Add Resource Version semantics section to api concepts
* Clarify risks of going back in time, add details about compaction and watch cache sizes
* Apply suggestions from liggitt
Co-Authored-By: Jordan Liggitt <jordan@liggitt.net>
* remove pesudocode, apply feedback
* Fix typo
* Clarify equality rules
* Cleanup kubectl generators docs (#17609)
* Write ReplicationController without a space
* Drop mentioning unsupported cluster versions
* Fix capitalization for “API group”
* Tweak wording
* Avoid using deprecated generator in example
* add Antrea description in dev-1.17 (#17919)
* Promote VolumeSubpathEnvExpansion to GA
* Reference Documentation for the Kubernetes API for 1.17 (#18019)
* Update feature-gates.md (#18033)
* Reference Documentation for kubectl Commands for 1.17 (#18017)
* Update for v1.17 (#18034)
* Update config.toml(release-1.17) for 1.17 (#18031)
* feature: v1.17 release blog
* Updated to match style guide
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Updated to match style guide
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Add link to 1.17 webinar
* Stop using H1
* feature: v1.17 release features
* Update in accordance with style guide
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* feature: v1.17 release features
* Update to reflect styleguide
* Update to reflect style guide
* Fix Code Examples
* Make "Create Volume From Snapshot" a heading
Signed-off-by: Karen Chu <karen.chu@microsoft.com>
* Remove TODO
* init cloud controller doc
* solve 349928135
* update r349928835
* update r349929569
* update r349930047
* update r321969236
* trans to hostname
* update based on reviews from truonghn1992
* fix several typo issues, add tooltips, replace some words back to the original terms
* init taint doc
* fix header Vendor Implementations
* fix directory name
* temporary remove term_id of node and toleration
* solve r350014277
* fix title
* update glossaris: cri,deployment,docker,kube-proxy,kubelet, label, node, pod, selector, service
* add container, rename label to match the label id
* fix typo
* fix a few typo and update based on r324616216
* update dependencies
term
* changed based on review 326584572
* fix typo
This is an attempt to remove 5 broken links that appeared on Japanese
documentation as result of copy/paste from English (inherited structure)
but not inherited redirections.
I tried to alarm about this issue at slack-AT[sig-docs](https://kubernetes.slack.com/archives/C1J0BPD2M/p1574528693286000), and decide to move
ahead with solution.
* Document correction for PDB
The word "may" should be replaced with "will". I do not see any reason for the ambiguity here.
* Updated as per review comments
* Updated as per review comments
* Revert "Remove dead links to old getting started guides (#17889)"
This reverts commit d6285eaac4.
* Revert "Fix a command in kubectl cheatsheet (#17888)"
This reverts commit e03f4b258c.
* specify components requiring feature gate
currently, TTLafterfinished feature gate is a flag that can be passed to kube-apiserver, kube-scheduler and kube-controller-manager. The current description doesn't state what components to pass the flag to.
* specify components requiring feature gate
After installing `cri-o`, we must run `systemctl daemon-reload` before
trying to run `systemctl start crio`. Otherwise, `systemd` doesn't know
about the crio configuration.
Similar instructions already exist for installing docker - this diff
adds these instructions for crio.
* Add Gardener Project Update blog post
* Update and rename 2019-11-10-gardener-project-update.md to 2019-11-27-gardener-project-update.md
* Update and rename 2019-11-27-gardener-project-update.md to 2019-12-02-gardener-project-update.md
* update style guide for styling component names
- Attempt to outline style conventions for components
and component tools
- Interested in comments and feedback
* update style examples
* style edits
- removed code style for components not cmd tools
- added style suggestion for namespaces
- cleaned up a few stray spaces
* Update kustomization.md
fix 404 urls in kustomization.md
* Update content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* update kustomization.md to be more stable
* Minor heading update according to the guideline
Fixed title of the document to use title case as described in the community guidelines.
* Capitalization fixes.
* Update commands/command output to reflect the current version
In explanation of init container, doc says 'Initializing' pod
condition. However according to doc of pod condition[1], it should be
'Initialized'.
This commit fixes this misspell of Indonesian doc.
This misspell is verified by PR #17329 which fixes English doc.
[1]
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions
* Fixed the incorrect parameter of specifying the CRI endpoint for kubelet
Corrected the parameter of '--container-runtime-path-endpoint' with '--container-runtime-endpoint'
* Corrected Default CNs
Fixed the incorrect Default CNs for apiserver-etcd-client.crt and apiserver-kubelet-client.crt
* init cloud controller doc
* solve 349928135
* update r349928835
* update r349929569
* update r349930047
* update r321969236
* trans to hostname
* update based on reviews from truonghn1992
* fix several typo issues, add tooltips, replace some words back to the original terms
* init taint doc
* fix header Vendor Implementations
* fix directory name
* temporary remove term_id of node and toleration
* solve r350014277
* fix title
* init cloud controller doc
* solve 349928135
* update r349928835
* update r349929569
* update r349930047
* update r321969236
* trans to hostname
* update based on reviews from truonghn1992
* fix several typo issues, add tooltips, replace some words back to the original terms
* init taint doc
* fix header Vendor Implementations
* fix directory name
* temporary remove term_id of node and toleration
* solve r350014277
* Tweak kubectl plugins page
- drop text about kubectl plugin beta status etc
- fix output formatted as shell
- address the reader as “you”
- other tweaks
* Update links & details for Krew
* Update kubectl-plugins.md
* incorrect command for sort-by
kubectl get pods -n test --sort-by=.spec.capacity.storage, is incorrect for pod as pods will not have capacity.storage under .spec, rather it should be for PersistentVolume.
So change the command
kubectl get pv -n test --sort-by=.spec.capacity.storage
* Update cheatsheet.md
* Refernce link added for Flex and CSI volume
Added reference link of Flex and CSI volume under `Components of the CCM` section.
* Update content/en/docs/concepts/architecture/cloud-controller.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Minor heading update according to the guideline
Fixed title of the document to use title case as described in the community guidelines.
* Capitalization fixes.
* Update files outdated Korean docs in dev-1.16-ko.5 (#17537)
* Update Korean glossary (#17619)
* Translate services-networking/endpoint-slices.md in Korean (#17631)
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <gochist@gmail.com>
Co-Authored-By: Wook-Jin, Lee <minjin00@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
* Adding vi document for create-cluster
Signed-off-by: Dao Cong Tien <tiendc@vn.fujitsu.com>
* Update cluster-intro.html
* Update cluster-intro.html
* Update cluster-intro.html
My guess is that we added some names at the very begining of Chinese
localization to seed the repo. However, getting PR reviews assigned to
these gentleman could be confusing or even annoying before they have
secured a Chinese certificate.
`https://openservicebrokerapi.org/` contains information such as `what are service brokers?`, how they work, building services for Kubernetes using `Open Service Broker API` etc.
`Object Metadata` section is misleading, as the Concept's overview is covering what master and non-master nodes are and list of objects. But there is no discussion on `Object Metadata` till the end and all of sudden there is Object Metadata section with no background introduction or definition, and just a reference to `Annotations` which is confusing if you read the content from the beginning. So it would be better to remove this as it is covered later here `https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/`.
* Issue-17562 default DNS cluster addon service's name fix
* Clarified the cluster addon is CoreDNS with application name KubeDNS and corrected the links to enable CoreDNS instead of kube-dns. Also reverted the changes made in ID & ZH languages. Need help there
* Update content/en/docs/concepts/services-networking/connect-applications-service.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Struggling to find the time for a while. Will come back when agenda frees up a little, but feel free to remove entirely from the list if you need/want to.
* Documentation corrected
The description for the `command` section was wrong. Same is corrected.
* Update content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com>
* Remove instructions to copy Etcd CA key in HA
No need to copy etcd CA key when manually copying certs from first master node to nodes joining the control plane.
* ca.key still needed for stacked ETCD
Added note to quote/unquote the copying instructions depending on Etcd configuration
After PVCProtection was deprecated in kubernetes/website@be48fb38e9 was
removed task used to describe concept of it. Link wasn't removed
everywhere (this PR removes it) and was living in site documentation
since then.
In Addition from tasks.yaml removed link pvc-protection articles
(also not exists).
Affected URL
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
Cert Manager mention was removed in kubernetes/website@8781518d as part of
the merge conflict resolving.
* Links to cert manager placed back (so we wouldn't see again
`[cert-manager][cert-manager]` in article text).
* In addition link to cert manager documentation is updated to official
website (its still readthedocs but, its official by stand of team behind
of the cert-manager)
Fix for the deprecation warning when executing the command:
```bash
$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
kubectl run --generator=cronjob/v1beta1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
```
* Tidy feature gate metadata
* Tweak feature gate headings
Use sentence case where appropriate
* Add feature gate explanation for GA
* Add what's next section to feature gate page
* Signpost readers to explanation of feature gate stages
* Modify terminated-pod-gc-threshold explanation in Japanese (#15272)
* Correct the word "controller" to the correct notation in Japanese
Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com>
* Remove unnecessary space
* Typo, should be extension's instead of extensions
In `Extension Patterns` section, `extensions points` should be `extension's points` as it's trying to say `points` belonging to a particular `extension`.
* Update content/en/docs/concepts/extend-kubernetes/extend-cluster.md
Changed as per tengqm suggestion.
Co-Authored-By: Qiming <tengqim@cn.ibm.com>
* Translate workloads/controllers/ttlafterfinished.md in Korean. (#17241)
* Update Korean l10n guide (#17402)
* Translate tasks/manage-kubernetes-objects/kustomization in Korean (#17225)
* Update file outdated korean docs in dev-1.16-ko.4 (#17235)
* Translate concepts/workloads/pods/ephemeral-containers.md in Korean. (#16630)
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
Co-Authored-By: June Yi <gochist@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
* Remove 'experimental' from high-availability, and '.' from etcd bullet
s/controller-managing/controller-manager
s/Apiserver/API server
s/Assuming/Assumes
* Update content/en/docs/tasks/debug-application-cluster/debug-cluster.md
Co-Authored-By: Stephen Augustus <justaugustus@users.noreply.github.com>
* Update content/en/docs/tasks/debug-application-cluster/debug-cluster.md
Co-Authored-By: Stephen Augustus <justaugustus@users.noreply.github.com>
* Update content/en/docs/tasks/debug-application-cluster/debug-cluster.md
Co-Authored-By: Stephen Augustus <justaugustus@users.noreply.github.com>
* Add new case study stylesheet
We will be adding a bunch of new case studies with an updated design (a lot of it is just simplified). I created this new file, and for the new case studies we will add
this updated code at the top from now on:
---
case_study_styles: true
cid: caseStudies
css: /css/new_case_studies.css
---
So just replacing the old css file with this one. Let me know if that is not going to work the way I think it will, thank you!
* update name
* update file name
* Update deployment.md
Modified kubectl get deployment command outputs to adapt them to the new output format introduced in v1.11
* Update deployment.md
Fix a typo
* New contributor blog post
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
* New Contributor blog post
Incorporated review feedback
* New Contributor blog post
Changed publication date to 11/6.
Fixed numbering in Citations section.
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
* New Contributor blog post
Fixed issue with header 9 diplay
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
* Update and rename grokkin-the-docs.md to 2019-11-05-grokkin-the-docs.md
Sometimes, pods like `coredns` only run on the master nodes. If there is a problem with upgrading the master node (e.g. if it is interrupted) those pods will not keep running - and other pods will have problems with connections.
Draining the master node will switch those pods to other nodes before the upgrade-process.
There are many YAML manifests sneaking into the `zh/docs/` directory.
These files should go to the `zh/examples` directory instead. Having
these "garbage" files (not referenced anywhere) is creating confusion
for the release meister when merging branches. For example, some YAML
files found in the 'master' branch are no longer there in the
release-1.16 branch. It is tedious, if possible at all, to solve all
this kind of conflicts during a rebase.
The PR cleanses the zh/docs directory for all dangling YAML files.
In doc of kubeadm installation, there are commands which wont work
without sudo regarding to Ubuntu/Debian instruction. However, other
docs related to kubeadm under
content/en/docs/setup/production-environment have commands with sudo.
This commit fixes this inconsistency.
* Removed multiple main tags from home page
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Removed multiple occurances of main in case-studies page
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Replaced css for main tag with .main-section class
Signed-off-by: ChaitanyaKaranam <karanam.krishna.25@gmail.com>
* Added main landmark role for all the pages
Signed-off-by: ChaitanyaKaranam <karanam.krishna.25@gmail.com>
* Force checks.
request-checks: true
Update file outdated korean docs in dev-1.16-ko.3. (#16876)
Translate concepts/architecture/controller.md in Korean (#16889)
Change the full link in the document to an inline link. (#17059)
Add English-Korean translation glossary (#16664)
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
In doc on Declarative Management of K8s object, there is explanation
of 'Default field values of K8s object set by K8s apiserver'.
In this explanation, there is examples of resource of K8s object.
And in this example, there is notes on what field value is set by
apiserver by default. But there is lack of a word in one of these
notes. This commit fixes it.
* adding details for all official client libraries .
there are six official client libraries for kubernetes. Added details and example for each language .Fix for issue #16906
* few typos and syntax mistakes resolved
* Update access-cluster-api.md
* removing extra code from haskell client
* favor svg over png for logos on case studies page
* added svgs for all case studies
* favor svg over png for logos on case studies page
* added svgs for all case studies
* duplicating the jd logo so both are svg
* switch to svgs in the case studies block on the homepage
* Document: how to install/distribute plugins with Krew
Context: Krew (https://sigs.k8s.io/krew) is a Kubernetes SIG CLI sub-project
that's been available for over a year. It is considered to be the de-facto tool
to discover and install kubectl plugins.
This patch details:
- how to use Krew to discover/install plugins
- how to distribute a kubectl plugin (with traditional package managers or
using Krew).
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Address PR comments
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
Add further details about the difference between the
two feature gate tables. The additional information and
table titles should help authors when creating or
updating the table entries.
Rearrange the order of the kubeadm init phase subcommand documentation
to match that in which the commands are executed in kubeadm init. This
change doesn't introduce any changes to actual content of the
documentation and only modifies the order in which it is presented.
- renamed docs/reference/kubernetes-api/index.md
- added weight to files in docs/reference/kubernetes-api
- attempt to clean up labels-annotations-taints.md
- updated _redirects file
Adding What's next section to the 'configuring service account' page which was missing earlier. Also, moved informative statement about document to 'Note' section
* Modifying adding label to node steps
Existing steps does not show what labels the node has before adding a new label. So I have changed the command to list out node along with their labels before adding any new label. This will help first-time readers to understand existing labels and then how we can add a new label and display it.
* Update content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
When the second path is attached to `example-ingress` for `/v2` it doesn't work because the first path captures all paths. Solution is the make the `/` capture everything except `/v2` (also captures `/v2/<anything else>`)
* Change the full link in the document to an inline link.
grep -r "https \: \ / \ / kubernetes \ .io" content/en/docs
Changed to inline link except the following list.
- URLs are mentioned directly in the body
- release note
- url to blog
- url to community
- Url to be redirected
* Apply suggestions from code review
Co-Authored-By: June Yi <june.yi@samsung.com>
The former is the official spelling, but both spellings have been
used throughout the docs. This commit replaces the occurrences of
the unofficial spelling with the official one.
-Update to use argparse.ArgumentParser() for command line args
-Use tempfile library to create tmp work directory
-Remove shutil.rmtree because it was throwing permission errors and
not deleting the directory. Also no longer needed after switching
to tempfile.
-Enchance error handling
-Add check for Go installation
-Enhance check for PyYAML installation
-Change deprecated PyYAML load function to full_load
-Add comments at top of file
-Modify to comply with PEP8
-Update kubernetes-components.md with software versions to match script
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
* Update patch release manager to patch release team in skew support policy.
* Adding link for additional patch-release information to version skew policy.
Update kubernetes-components.md with software versions.
Move content from README to kubernetes-components to avoid duplication.
Be listed in the `kubernetes/website/data/reference.yml` file
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
108.59.85.141 is a genuine IPv4 address; at the time of writing it's
assigned to Google LLC / Google Cloud Platform. Use a documentation IPv4
address instead.
* fix for issue #16629
this is a fix for issue #16629 .
* Update content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Add info about logging into shell before removing /mnt/data
details
----------
- rm -rf should be run after logging into the node shell
* Re-use text from start of the task with small tweaks
* Update file outdated korean docs in dev-1.16-ko.2. (#16614)
* Translate docs/templates/feature-state-*.txt in Korean (#16613)
* Translate pod-topology-spread-constraints in Korean (#16654)
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
* kubeadm: include a couple of workarounds in kubeadm-certs.md
- add warning about --certificate-renewal=false bug.
- add warning about disable kubelet cert rotation on "init" nodes.
* Update content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Fixing port related description
This tutorial has a step to use randomly generated port number but it was not mentioned that it can be different when the user tries this example. so to remove ambiguity, I have added a proper description. Please have a look at #16810
* Incorporating review comments
Incorporating review comments
There are two fixes in this change. First, the yaml is left justified in order to ease copying. Secondly, the selector field is added to the deployment.
Improved indentation
Apply suggestions from code review
Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com>
Removing bullets points
Same have been added inline as per suggestions
Removed trailing space
* Rename architecture section
"Kubernetes" goes without saying. This section is mainly talking about
cluster architecture, so make the title match that.
* Introduce “cluster” before Cluster Architecture section
Make sure the reader can learn what a cluster is before they read about
elements of cluster architecture.
In the current example, single quotes are used, but the union operator can be confusing.
Incorrect：
`kubectl get pod -o=jsonpath='{.items[*]['metadata.name','spec.nodeName']}'`
Correct:
`kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"`
* Fixes for broken links
+ these fixes mostly covers forgotten scheme (like https: or mailto:)
+ fix for markdown parsing, which trigger to generate broken html (see 2019-03-20 post)
* Added new lines so list wouldn't looks like a mess
Update CRI-O links from Kubernetes incubator to the official CRI-O
homepage. Most links were already updated, but there were a few
stragglers in minikube documentation and old blog posts.
* Fixed accessibility issues in home page
Signed-off-by: ChaitanyaKaranam <karanam.krishna.25@gmail.com>
* Fixed accessibility issues for docs/home page
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Fixed accessibility issues for /partners page
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Fixed accessibility issues for /community page
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Update layouts/partials/header.html
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update layouts/partials/footer-scripts.html
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update layouts/index.html
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/partners/_index.html
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/community/_index.html
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Added missing quotes
* Added landmark roles for search bar and footer
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Changed images alt text
Changed alt text from 'kubernetes community' to 'Kubernetes Conference Gallery'
* Removed verb from iframe title
Signed-off-by: chaitanyakaranam <chaitanya.karanam@yahoo.com>
* Change alt text for GitHub image
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Few alt text changes
* Modified alt text
In Google Chrome this property is not taken into account, while in
Mozilla Firefox and Safari it is. The property makes the code
snippets difficult to read.
* Initiate
* Continue translation raw
* Change some into english
* Change few typographies
* trigger build
* Apply suggestions from code review
Co-Authored-By: Irvi Aini <7439590+irvifa@users.noreply.github.com>
* Modify #16415, #16417 korean docs. (#16467)
* Modify #16364 and links in korean docs. (#16508)
* Translate concepts/workloads/controllers/statefulset.md in Korean (#16443)
* Update outdated content in dev-1.16-ko.1 (#16502)
* Translate concepts/workloads/controllers/daemonset.md in Korean (#16477)
* Translate concepts/services-networking/dns-pod-service in Korean (#16299)
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: SoHye Choi <wergreat10@naver.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
when copying/pasting the command to install the Kubernetes on Mac OS using zsh, the command results in the following error,
`The specified key does not exist.`. This is usually because of the `\` that zsh automatically inserts into the command. The best practice is to use double-quotes and this is also the standard method according to https://google.github.io/styleguide/shell.xml?showone=Quoting#Quoting
* Added logo change for blog site
Currently on blog site logo is not being changed when a page is scrolled down and therefore disappears. This fixes it
* Update _base.sass
changed email for CLA
* initial commit
* promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484)
* 1. Sync release-1.15 into master
2. Sync with en version
* 1. Add the lost yaml file.
* Update he cluster administration folder of concepts
1. Sync with 1.14 branch
2. Sync with en version
* Add yaml files which are used
* 1. Sync the configuration folder from 1.14 version
2. Sync the configuration folder files with en version
3. Changed some files structure for easily review
4. Add glossary folder for fixup build error
* 1. Sync the storage folder from 1.14 version
2. Sync the storage folder files with 1.16 version en document
3. Changed some files structure for easily review
* 1. Sync the service-networking folder from 1.14 version
2. Sync the service-networking folder files with 1.16 version en document
3. Changed some files structure for easily review
4. Add the necessary documents
5. Add the runtime-class file
* Fix incorrect advice about creating a secret
The existing command does not use code style as required by the style
guide and it is incorrect as rendered. Also, there's an easier way to do
this.
* Add reviewer suggested improvement for secret escaping
Adding sftim's suggestion phrasing explanation of escaping shell special characters.
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Make secret escaping instructions consistent
* initial commit
* promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484)
* 1. Sync release-1.15 into master
2. Sync with en version
* 1. Add the lost yaml file.
* Update he cluster administration folder of concepts
1. Sync with 1.14 branch
2. Sync with en version
* Add yaml files which are used
* 1. Sync the configuration folder from 1.14 version
2. Sync the configuration folder files with en version
3. Changed some files structure for easily review
4. Add glossary folder for fixup build error
* 1. Sync the storage folder from 1.14 version
2. Sync the storage folder files with 1.16 version en document
3. Changed some files structure for easily review
There is a "Kubernetes Dashboard project" in "about" at ".github/ISSUE_TEMPLATE/support.md"
This commit changes "Kubernetes Dashboard project" with "Kubernetes Website project".
`kubectl config view -o jsonpath='{.users[].name}' ` in the doc doesn't get the list of users as described in the comment actually.
To get the list of users, the json path should be `'{.users[].name}' `
Enhance to emphasize that triagers should add a priority to each
issue.
Add Learn about Prow section
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
Add references to the Content guide where the Style guide was
mentioned.
Update the Contribute page (_index.md)
Make Style and Content linkable everywhere
Changed bullet list to numbered list in Content Guide to make referring
to sections easier.
Reverted change to bullet list - beyond scope of this PR
Signed-off-by: Aimee Ukasick <aimeeu.opensource@gmail.com>
* initial commit
* promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484)
* 1. Sync release-1.15 into master
2. Sync with en version
* 1. Add the lost yaml file.
* Update he cluster administration folder of concepts
1. Sync with 1.14 branch
2. Sync with en version
* Add yaml files which are used
* 1. Sync the configuration folder from 1.14 version
2. Sync the configuration folder files with en version
3. Changed some files structure for easily review
4. Add glossary folder for fixup build error
The `*.profile` file referenced do not need to be provided in a separate
file. Making them separate files is preventing hugo from correctly
building the site.
* initial commit
* promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484)
* 1. Sync release-1.15 into master
2. Sync with en version
* 1. Add the lost yaml file.
* Update he cluster administration folder of concepts
1. Sync with 1.14 branch
2. Sync with en version
* Add yaml files which are used
* initial commit
* promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484)
* 1. Sync release-1.15 into master
2. Sync with en version
* 1. Add the lost yaml file.
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.
* initial commit for IPv4/IPv6 dual stack docs
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Remove warning, Add What's next section
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Add Service section
Add Provising a dual stack Kubernetes cluster section
Add Ecosystem tooling section
Update prerequisites
Update flags
Update supported features
Move validation to task
Add Service validation
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Remove ecosystem tooling
Remove provisioning tools
Add backtics to ipFamily values
Update loadbalancer section
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Fix feature gate link typo
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update to dual-stack
Add default use-case to Service validation
Add note to default Service behaviour
Add default Service example
Update egress routing description
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Update api-server to the API server
Fix small typo based on feedback
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Add for_k8s_version feature state
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Update service IP address verbiage to be more concise
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Move to tasks/network
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Move dual-stack under services-networking
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Remove dual-stack from glossary
Add codenew blocks
Split command from output
Renamed pod name
Created subheading to validate node and pod addressing
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Verbiage update based on review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com>
* Apply suggestions from code review
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* storage: CSI inline volumes in beta
* storage: remove historic information for CSI inline volumes
As pointed out during review, this information is better captured in
the feature gates reference page.
* Added documentation to support Topology Manager feature in Kubelet.
* Added new document outlining feature
* Updated feature-gates.md to include feature gate for feature
* Update kubelet.md to include kubelet flags for feature
* Added Topology Manager reference to relevant pages
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* Update Topology Manager Policies section
* Add comprehensive CRD versioning flow to documentation
* Break down CRD versioning upgrade processes into steps, apply review feedback
* Reference doc section about custom resource storage migration in workflow documentation
* Add step to find any clients still on old version during CRD version migration
* Fix indentation in list in conversion end-to-end flow doc
* Fix spacing before lists in docs about conversion webhooks
* Fix two typos
Also, I've snuck in a trivial update for the ShareProcessNamespace
feature gate, adding an "Until" version which had been omitted.
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
Create a concepts page, link to it from scheduler concept page,
update feature gates reference and describe briefly in the
runtime-class page.
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
* added step on pulling down sig-windows-tools to windows guide.
* First draft of KubeCluster.ps1 Windows setup instructions
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* Update content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
Co-Authored-By: Tim Bannister <tim@scalefactory.com>
* added pre-reqs for overlay and moved troubleshooting section
* cosmetic changes and updated kubecluster.ps1 .gifs
* updated deployment steps and networking fix-ups in the Windows user guide
* Documenting how to use EvenPodsSpread feature
* address comments
* address comments
* address sftim's comments
* move to folder workloads/pods
* address comments
* move yamls to examples folder and reference back in the document
* Link from scheduling to topology spread constraints
- minor fix for control-plane-flags
- cleanup tables from "kubeadm maturity" in create-cluster
- update install guide for container linux guide in install-kubeadm
- minor fixes in self-hosting
Recently, the RunAsUserName feature has been added, allowing users to
run Windows containers with custom usernames, different from the image
default usernames.
Adds documentation regarding its prerequisites, feature gate, usage,
restrictions, and samples.
The addition of the flag "---control-plane-endpoint" for
"kubeadm init" removes the requirement for creating a config file
for the stacked etcd setup.
The config is still required for stacked etcd setup.
@@ -28,7 +28,7 @@ El método recomendado para levantar una copia local del sitio web kubernetes.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).
> 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-kubernetesio-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:
@@ -33,7 +33,7 @@ La façon recommandée d'exécuter le site web Kubernetes localement est d'utili
> 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 préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#exécuter-le-site-localement-en-utilisant-hugo) ci-dessous.
Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement:
@@ -9,7 +9,7 @@ Selamat datang! Repositori ini merupakan wadah bagi semua komponen yang dibutuhk
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.
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:
@@ -21,11 +21,11 @@ Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat
## 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.
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 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-dengan-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:
@@ -44,7 +44,7 @@ Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi.
## 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).
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:
Benvenuto! Questo repository contiene tutte le informazioni necessarie per creare la [documentazione e il sito web di Kubernetes](https://kubernetes.io/). Siamo onorati che tu voglia contribuire!
## Come contribuire alla documentazione
Puoi premere il pulsante **Fork** in alto nella parte destra dello schermo per creare una copia di questo repository sotto la tua utenza di GitHub. Questa copia è chiamata un *fork*. Puoi fare tutte le modifiche che vuoi nel tuo fork, e quando sei pronto a mandarci i cambiamenti, vai sulla pagina del tuo fork e crea una nuova pull request per farcelo sapere.
Una volta che hai creato la pull request, un reviewer (revisore) Kubernetes la prenderà in carico per fornire un feedback chiaro e concretamente attuabile. Come owner della pull request, **è tua responsabilità modificare la tua pull request per rispondere al feedback che ti è stato fornito dal reviewer Kubernetes**. Inoltre, tieni presente che potresti ricevere feedback da più di un Reviewer di Kubernetes, incluse quindi persone diverse da quella che ti ha fornito il primo feedback. In alcuni casi, uno dei tuoi reviewer potrebbe richiedere una revisione tecnica da un [technical reviewer di Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessario. I reviewer faranno del loro meglio per fornire feedback in modo tempestivo, ma i tempi di risposta possono variare in base alle circostanze.
Per maggiori informazioni su come contribuire alla documentazione Kubernetes, vedi:
* [Cominciare a contribuire](https://kubernetes.io/docs/contribute/start/)
* [Vedere le modifiche localmente](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Utilizzare i template delle pagine](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Guida Stilistica per la documentazione di Kubernetes](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Tradurre la documentazione di Kubernetes](https://kubernetes.io/docs/contribute/localization/)
## Eseguire il sito Web localmente usando Docker
Il modo consigliato per eseguire localmente il sito Web Kubernetes prevede l'utilizzo di un'immagine [Docker](https://docker.com) inclusa nel sito e configurata con tutti i software necessari, a partire dal generatore di siti web statici [Hugo](https://gohugo.io).
> Se stai utilizzando Windows, avrai bisogno di alcuni strumenti aggiuntivi che puoi installare con [Chocolatey](https://chocolatey.org). `choco install make`
> Se preferisci eseguire il sito Web localmente senza Docker, vedi [Eseguire il sito Web localmente utilizzando Hugo](#eseguire-il-sito-web-localmente-utilizzando-hugo) di seguito.
Se hai Docker [attivo e funzionante](https://www.docker.com/get-started), crea l'immagine Docker `kubernetes-hugo` localmente:
```bash
make docker-image
```
Dopo aver creato l'immagine, è possibile eseguire il sito Web localmente:
```bash
make docker-serve
```
Apri il tuo browser su http://localhost:1313 per visualizzare il sito Web. Mentre modifichi i file sorgenti, Hugo aggiorna automaticamente il sito Web e forza un aggiornamento della pagina visualizzata nel browser.
## Eseguire il sito Web localmente utilizzando Hugo
Vedi la [documentazione ufficiale di Hugo](https://gohugo.io/getting-started/installing/) per le istruzioni di installazione di Hugo. Assicurati di installare esattamente la versione di Hugo specificata dalla variabile d'ambiente `HUGO_VERSION` nel file [`netlify.toml`](netlify.toml#L9).
Per eseguire il sito Web localmente dopo aver installato Hugo:
```bash
make serve
```
Questo comando avvierà il server Hugo locale sulla porta 1313. Apri il tuo browser su http://localhost:1313 per visualizzare il sito Web. Mentre apporti modifiche ai file di origine, Hugo aggiorna il sito Web e forza un aggiornamento del browser.
## Community, discussioni, contribuire e supporto
Scopri come interagire con la community di Kubernetes nella [pagina della community](http://kubernetes.io/community/).
Puoi contattare i maintainers di questo progetto su:
이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
여러분의 풀 리퀘스트가 생생된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다. 뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다. 그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu!
## Twój wkład w dokumentację
Możesz kliknąć w przycisk **Fork** w prawym górnym rogu ekranu, aby stworzyć kopię tego repozytorium na swoim koncie GitHub. Taki rodzaj kopii (odgałęzienia) nazywa się *fork*. Zmieniaj w nim, co chcesz, a kiedy będziesz już gotowy/a przesłać te zmiany do nas, przejdź do swojej kopii i stwórz nowy *pull request*, abyśmy zostali o tym poinformowani.
Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** Może też się zdarzyć, że swoje uwagi zgłosi więcej niż jeden recenzent, lub że recenzję będzie robił ktoś inny, niż ten, kto został przydzielony na początku. W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z [recenzentów technicznych](https://github.com/kubernetes/website/wiki/Tech-reviewers). Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników.
Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz na stronach:
|[README po francusku](README-fr.md)|[README po koreańsku](README-ko.md)|
|[README po niemiecku](README-de.md)|[README po portugalsku](README-pt.md)|
|[README w hindi](README-hi.md)|[README po hiszpańsku](README-es.md)|
|[README po indonezyjsku](README-id.md)|[README po chińsku](README-zh.md)|
|[README po japońsku](README-ja.md)|[README po polsku](README-pl.md)|
|||
## Jak uruchomić lokalną kopię strony przy pomocy Dockera?
Zalecaną metodą uruchomienia serwisu internetowego Kubernetesa lokalnie jest użycie specjalnego obrazu [Dockera](https://docker.com), który zawiera generator stron statycznych [Hugo](https://gohugo.io).
> Użytkownicy Windows będą potrzebowali dodatkowych narzędzi, które mogą zainstalować przy pomocy [Chocolatey](https://chocolatey.org).
```bash
choco install make
```
> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-serwis-lokalnie-przy-pomocy-hugo) poniżej.
Jeśli [zainstalowałeś i uruchomiłeś](https://www.docker.com/get-started) już Dockera, zbuduj obraz `kubernetes-hugo` lokalnie:
```bash
make docker-image
```
Po zbudowaniu obrazu, możesz uruchomić serwis lokalnie:
```bash
make docker-serve
```
Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
## Jak uruchomić lokalną kopię strony przy pomocy Hugo?
Zajrzyj do [oficjalnej dokumentacji Hugo](https://gohugo.io/getting-started/installing/) po instrukcję instalacji. Upewnij się, że instalujesz rozszerzoną wersję Hugo, określoną przez zmienną środowiskową `HUGO_VERSION` w pliku [`netlify.toml`](netlify.toml#L9).
Aby uruchomić serwis lokalnie po instalacji Hugo, napisz:
```bash
make serve
```
Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres http://localhost:1313, aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
## Społeczność, listy dyskusyjne, uczestnictwo i wsparcie
Zajrzyj na stronę [społeczności](http://kubernetes.io/community/), aby dowiedzieć się, jak możesz zaangażować się w jej działania.
Możesz kontaktować się z gospodarzami projektu za pomocą:
@@ -9,7 +9,7 @@ Bem vindos! Este repositório abriga todos os recursos necessários para criar o
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.
Depois que seu **pull request** for criado, 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:
Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания!
## Вклад в документацию
Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/start/)
Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io).
> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#запуск-сайта-с-помощью-hugo) ниже на этой странице.
Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
```bash
make docker-image
```
После того, как вы собрали образ, можно запустить сайт локально:
```bash
make docker-serve
```
Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
## Запуск сайта с помощью Hugo
Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L10).
После установки Hugo, чтобы запустить сайт, выполните в консоли:
```bash
make serve
```
Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
## Сообщество, обсуждение, вклад и поддержка
Узнайте, как поучаствовать в жизни сообщества Kubernetes на [странице сообщества](http://kubernetes.io/community/).
Вы можете связаться с сопровождающими этого проекта по следующим ссылкам:
- [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs)
Chào mừng! Kho lưu trữ này chứa tất cả các tài nguyên cần thiết để xây dựng [trang web của Kubernetes và các tài liệu](https://kubernetes.io/). Chúng tôi rất vui vì bạn muốn đóng góp.
## Đóng góp cho tài liệu
Bạn có thể click vào nút **Fork** ở góc trên bên phải màn hình để tạo bản sao của kho lưu trữ này trong tài khoản GitHub của bạn. Bản sao này được gọi là một bản *fork*. Thực hiện bất kì thay đổi nào mà bạn muốn trong bản fork của bạn và khi bạn sẵn sang gửi những thay đổi đó cho chúng tôi, hãy đến bản fork của bạn và tạo một Pull Request mới để cho chúng tôi biết về nó.
Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách nhiệm cung cấp các phản hồi rõ ràng, có thể thực hiện được. Là chủ sở hữu của pull request, **bạn có trách nhiệm sửa đổi Pull Request của mình để giải quyết các phản hồi bởi reviewer.** Ngoài ra, lưu ý rằng bạn có thể có nhiều hơn một reviewer cung cấp cho bạn các phản hồi hoặc bạn có thể nhận được phản hồi từ reviewer khác với reviewer ban đầu được chỉ định. Hơn nữa, trong một số trường hợp, một trong những reviewer của bạn có thể yêu cầu đánh giá kỹ thuật từ [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) khi cần. Các reviewers sẽ cố gắng hết sức để cung cấp phản hồi một cách kịp thời nhưng thời gian phản hồi có thể thay đổi tùy theo hoàn cảnh.
Để biết thêm thông tin về việc đóng góp cho tài liệu Kubernetes, hãy xem:
* [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/)
* [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/)
## Chạy website cục bộ dùng Docker
Cách được đề xuất để chạy trang web Kubernetes cục bộ là dùng [Docker](https://docker.com) image chứa trình tạo web tĩnh [Hugo](https://gohugo.io).
> Nếu bạn làm việc trên môi trường Windows, bạn sẽ cần thêm môt vài công cụ mà bạn có thể cài đặt với [Chocolatey](https://chocolatey.org). `choco install make`
> Nếu bạn không muốn dùng Docker để chạy trang web cục bộ, hãy xem [Chạy website cục bộ dùng Hugo](#chạy-website-cục-bộ-dùng-hugo) dưới đây.
Nếu bạn có Docker đang [up và running](https://www.docker.com/get-started), build `kubernetes-hugo` Docker image cục bộ:
```bash
make docker-image
```
Khi image đã được built, bạn có thể chạy website cục bộ:
```bash
make docker-serve
```
Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
## Chạy website cục bộ dùng Hugo
Hãy xem [tài liệu chính thức của Hugo](https://gohugo.io/getting-started/installing/) cho việc hướng dẫn cài đặt Hugo. Đảm bảo cài đặt phiên bản mở rộng của Hugo được xác định bởi biến môi trường `HUGO_VERSION` trong file [`netlify.toml`](netlify.toml#L9)
Để chạy website cục bộ khi Hugo được cài đặt:
```bash
make serve
```
Câu lệnh trên sẽ khởi động server Hugo cục bộ trên cổng 1313. Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
## Cộng đồng, thảo luận, đóng góp và hỗ trợ
Tìm hiểu cách tham gia với cộng đồng Kubernetes trên [trang cộng đồng](http://kubernetes.io/community/).
Bạn có thể tiếp cận những maintainers của dự án này tại:
@@ -35,7 +37,7 @@ The recommended way to run the Kubernetes website locally is to run a specialize
> 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 website 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-website-locally-using-hugo) below.
If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
# 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
---
@@ -44,12 +44,12 @@ Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor
<br>
<br>
<br>
<ahref="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019"buttonid="desktopKCButton">KubeCon vom 18-21. November 2019 in San Diego</a>
<ahref="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/"buttonid="desktopKCButton">Besuchen Sie die KubeCon vom 30 März-2 Apr. 2020 in Amsterdam</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>
<ahref="https://www.lfasiallc.cn/kubecon-cloudnativecon-open-source-summit-china/"buttonid="desktopKCButton">Besuchen Sie die KubeCon vom 28-30 Juli 2020 in Shanghai</a>
<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
<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.
Der Kodex befindet sich weiter unten auf der Seite, wie er auch in
<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct-languages/de.md">Commit 214585e</a> gefunden werden kann.
Wenn dir auffällt, dass die hier gezeigte Version nicht mehr aktuell ist,
<a href="https://github.com/kubernetes/website/issues/new">eröffne bitte ein Issue</a>.
Wenn dir bei einem Event, einem Meeting, in Slack oder einem anderen
Kommunikationskanal ein Verstoß gegen den Verhaltenskodex auffällt, wende dich an das <a href="https://git.k8s.io/community/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a>.
Du kannst das Komitee über E-Mail erreichen: <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
Als Mitwirkende und Betreuer dieses Projekts und im Interesse der Förderung einer offenen und einladenden Gemeinschaft verpflichten wir uns dazu, alle Menschen zu respektieren, die durch Berichterstattung, Veröffentlichung von Eigenschaftsanfragen, Aktualisierung der Dokumentation, Einreichung von Pull-Anfragen oder Patches und anderen Aktivitäten einen Beitrag leisten.
Wir sind bestrebt, die Teilnahme an diesem Projekt für alle zu einer belästigungsfreien Erfahrung zu machen, unabhängig von Erfahrungsstand, Geschlecht, geschlechtsspezifischer Identität und Ausdruck, sexueller Orientierung, Behinderung, persönlichem Aussehen, Körpergröße, Rasse, ethnischer Herkunft, Alter, Religion oder Nationalität.
Beispiele für unzumutbares Verhalten der Teilnehmer sind:
- Der Gebrauch von sexualisierter Sprache oder Bildern
- Persönliche Angriffe
- Trolling oder beleidigende/herabwürdigende Kommentare
- Öffentliche oder private Belästigungen
- Veröffentlichung privater Informationen anderer, wie z.B. physischer oder elektronischer Adressen, ohne ausdrückliche Genehmigung
- Anderes unethisches oder unprofessionelles Verhalten.
Projektbetreuer haben das Recht und die Verantwortung, Kommentare, Commits, Code, Wiki-Bearbeitungen, Probleme und andere Beiträge zu entfernen, zu bearbeiten oder abzulehnen, die nicht mit diesem Verhaltenskodex übereinstimmen. Mit der Annahme dieses Verhaltenskodex verpflichten sich die Projektbetreuer, diese Grundsätze fair und konsequent auf jeden Aspekt der Projektleitung anzuwenden. Projektbetreuer, die den Verhaltenskodex nicht befolgen oder durchsetzen, können dauerhaft vom Projektteam ausgeschlossen werden.
Dieser Verhaltenskodex gilt sowohl innerhalb von Projekträumen als auch in öffentlichen Räumen, wenn eine Person das Projekt oder seine Gemeinschaft vertritt.
Fälle von missbräuchlichem, belästigendem oder anderweitig unzumutbarem Verhalten in Kubernetes können gemeldet werden, indem Sie sich an das [Kubernetes Komitee für Verhaltenskodex](https://git.k8s.io/community/committee-code-of-conduct) wenden unter <conduct@kubernetes.io>. Für andere Projekte wenden Sie sich bitte an einen CNCF-Projektbetreuer oder an unseren Mediator, Mishi Choudhary <mishi@linux.com>.
Dieser Verhaltenskodex wurde aus dem Contributor Covenant übernommen (http://contributor-covenant.org), Version 1.2.0, verfügbar unter http://contributor-covenant.org/version/1/2/0/
### CNCF Verhaltenskodex für Veranstaltungen
Für CNCF Veranstaltungen gilt der Verhaltenskodex der Linux Foundation, der auf der Veranstaltungsseite verfügbar ist. Diese ist so konzipiert, dass sie mit der oben genannten Richtlinie kompatibel ist und enthält auch weitere Details zur Reaktion auf Vorfälle.
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.
Im Abschnitt Konzepte erfahren Sie mehr über die Bestandteile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Verwaltung Ihres Clusters zur Verfügung stellt. Sie erhalten zudem ein tieferes Verständnis der Funktionsweise von Kubernetes.
{{% /capture %}}
@@ -15,10 +15,10 @@ Im Abschnitt Konzepte erfahren Sie mehr über die Teile des Kubernetes-Systems u
## Ü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.
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. Dies geschieht 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:
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. das 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:
@@ -27,16 +27,16 @@ Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Contr
## 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.
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte 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:
Darüber hinaus enthält Kubernetes 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:
@@ -46,19 +46,19 @@ Darüber hinaus enthält Kubernetes eine Reihe von Abstraktionen auf höherer Eb
## Kubernetes Control Plane
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.
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 verwaltet ein Inventar aller Kubernetes-Objekte im System und führt kontinuierlich Kontrollschleifen aus, um den Status dieser Objekte zu verwalten. Zu jeder Zeit reagieren die Kontrollschleifen des Control Plane auf Änderungen im Cluster und arbeiten daran, dass der tatsächliche Status aller Objekte im System mit dem von Ihnen definierten Status ü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.
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 Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommandozeilen-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.
> Der Begriff "Master" bezeichnet dabei 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 die 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.
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 Node; Sie werden selten direkt mit Nodes interagieren.
title: Zugrunde liegende Konzepte des Cloud Controller Manager
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
Das Konzept des Cloud Controller Managers (CCM) (nicht zu verwechseln mit der Binärdatei) wurde ursprünglich entwickelt, um Cloud-spezifischen Anbieter Code und den Kubernetes Kern unabhängig voneinander entwickeln zu können. Der Cloud Controller Manager läuft zusammen mit anderen Master Komponenten wie dem Kubernetes Controller Manager, dem API-Server und dem Scheduler auf dem Host. Es kann auch als Kubernetes Addon gestartet werden, in diesem Fall läuft er auf Kubernetes.
Das Design des Cloud Controller Managers basiert auf einem Plugin Mechanismus, der es neuen Cloud Anbietern ermöglicht, sich mit Kubernetes einfach über Plugins zu integrieren. Es gibt Pläne für die Einbindung neuer Cloud Anbieter auf Kubernetes und für die Migration von Cloud Anbietern vom alten Modell auf das neue CCM-Modell.
Dieses Dokument beschreibt die Konzepte hinter dem Cloud Controller Manager und gibt Details zu den damit verbundenen Funktionen.
Die Architektur eines Kubernetes Clusters ohne den Cloud Controller Manager sieht wie folgt aus:
Im vorhergehenden Diagramm sind Kubernetes und der Cloud-Provider über mehrere verschiedene Komponenten integriert:
* Kubelet
* Kubernetes Controller Manager
* Kubernetes API Server
CCM konsolidiert die gesamte Abhängigkeit der Cloud Logik von den drei vorhergehenden Komponenten zu einem einzigen Integrationspunkt mit der Cloud. So sieht die neue Architektur mit dem CCM aus:
## Komponenten des CCM
Der CCM löst einen Teil der Funktionalität des Kubernetes Controller Managers (KCM) ab und führt ihn als separaten Prozess aus. Konkret trennt es die Cloud abhängigen Controller im KCM. Der KCM verfügt über die folgenden Cloud abhängigen Steuerungsschleifen:
* Node Controller
* Volume Controller
* Route Controller
* Service Controller
In der Version 1.9 führt der CCM die folgenden Controller aus der vorhergehenden Liste aus:
* Node Controller
* Route Controller
* Service Controller
{{< note >}}
Der Volume Controller wurde bewusst nicht als Teil des CCM gewählt. Aufgrund der Komplexität und der bestehenden Bemühungen, herstellerspezifische Volume Logik zu abstrahieren, wurde entschieden, dass der Volume Controller nicht zum CCM verschoben wird.
{{< /note >}}
Der ursprüngliche Plan, Volumes mit CCM zu integrieren, sah die Verwendung von Flex-Volumes vor welche austauschbare Volumes unterstützt. Allerdings ist eine konkurrierende Initiative namens CSI geplant, um Flex zu ersetzen.
In Anbetracht dieser Dynamik haben wir uns entschieden, eine Zwischenstopp durchzuführen um die Unterschiede zu beobachten , bis das CSI bereit ist.
## Funktionen des CCM
Der CCM erbt seine Funktionen von Komponenten des Kubernetes, die von einem Cloud Provider abhängig sind. Dieser Abschnitt ist auf der Grundlage dieser Komponenten strukturiert.
### 1. Kubernetes Controller Manager
Die meisten Funktionen des CCM stammen aus dem KCM. Wie im vorherigen Abschnitt erwähnt, führt das CCM die folgenden Steuerschleifen durch:
* Node Controller
* Route Controller
* Service Controller
#### Node Controller
Der Node Controller ist für die Initialisierung eines Knotens verantwortlich, indem er Informationen über die im Cluster laufenden Knoten vom Cloud Provider erhält. Der Node Controller führt die folgenden Funktionen aus:
1. Initialisierung eines Knoten mit Cloud-spezifischen Zonen-/Regionen Labels.
2. Initialisieren von Knoten mit Cloud-spezifischen Instanzdetails, z.B. Typ und Größe.
3. Ermitteln der Netzwerkadressen und des Hostnamen des Knotens.
4. Falls ein Knoten nicht mehr reagiert, überprüft der Controller die Cloud, um festzustellen, ob der Knoten aus der Cloud gelöscht wurde.
Wenn der Knoten aus der Cloud gelöscht wurde, löscht der Controller das Kubernetes Node Objekt.
#### Route Controller
Der Route Controller ist dafür verantwortlich, Routen in der Cloud so zu konfigurieren, dass Container auf verschiedenen Knoten im Kubernetes Cluster miteinander kommunizieren können. Der Route Controller ist nur auf einem Google Compute Engine Cluster anwendbar.
#### Service Controller
Der Service Controller ist verantwortlich für das Abhören von Ereignissen zum Erstellen, Aktualisieren und Löschen von Diensten. Basierend auf dem aktuellen Stand der Services in Kubernetes konfiguriert es Cloud Load Balancer (wie ELB, Google LB oder Oracle Cloud Infrastructure LB), um den Zustand der Services in Kubernetes abzubilden. Darüber hinaus wird sichergestellt, dass die Service Backends für Cloud Loadbalancer auf dem neuesten Stand sind.
### 2. Kubelet
Der Node Controller enthält die Cloud-abhängige Funktionalität des Kubelets. Vor der Einführung des CCM war das Kubelet für die Initialisierung eines Knotens mit cloudspezifischen Details wie IP-Adressen, Regions-/Zonenbezeichnungen und Instanztypinformationen verantwortlich. Mit der Einführung des CCM wurde diese Initialisierungsoperation aus dem Kubelet in das CCM verschoben.
In diesem neuen Modell initialisiert das Kubelet einen Knoten ohne cloudspezifische Informationen. Es fügt jedoch dem neu angelegten Knoten einen Taint hinzu, der den Knoten nicht verplanbar macht, bis der CCM den Knoten mit cloudspezifischen Informationen initialisiert. Dann wird der Taint entfernt.
## Plugin Mechanismus
Der Cloud Controller Manager verwendet die Go Schnittstellen, um Implementierungen aus jeder Cloud einzubinden. Konkret verwendet dieser das CloudProvider Interface, das [hier](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) definiert ist.
Die Implementierung der vier oben genannten geteiltent Controllern und einigen Scaffolding sowie die gemeinsame CloudProvider Schnittstelle bleiben im Kubernetes Kern. Cloud Provider spezifische Implementierungen werden außerhalb des Kerns aufgebaut und implementieren im Kern definierte Schnittstellen.
Weitere Informationen zur Entwicklung von Plugins findest du im Bereich [Entwickeln von Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
## Autorisierung
Dieser Abschnitt beschreibt den Zugriff, den der CCM für die Ausführung seiner Operationen auf verschiedene API Objekte benötigt.
### Node Controller
Der Node Controller funktioniert nur mit Node Objekten. Es benötigt vollen Zugang zu get, list, create, update, patch, watch, und delete Node Objekten.
v1/Node:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
### Route Controller
Der Route Controller horcht auf die Erstellung von Node Objekten und konfiguriert die Routen entsprechend. Es erfordert get Zugriff auf die Node Objekte.
v1/Node:
- Get
### Service Controller
Der Service Controller hört auf die Service Objekt Events create, update und delete und konfiguriert dann die Endpunkte für diese Services entsprechend.
Um auf Services zuzugreifen, benötigt man list und watch Berechtigung. Um die Services zu aktualisieren, sind patch und update Zugriffsrechte erforderlich.
Um die Endpunkte für die Dienste einzurichten, benötigt der Controller Zugriff auf create, list, get, watch und update.
v1/Service:
- List
- Get
- Watch
- Patch
- Update
### Sonstiges
Die Implementierung des Kerns des CCM erfordert den Zugriff auf die Erstellung von Ereignissen und zur Gewährleistung eines sicheren Betriebs den Zugriff auf die Erstellung von ServiceAccounts.
v1/Event:
- Create
- Patch
- Update
v1/ServiceAccount:
- Create
Die RBAC ClusterRole für CCM sieht wie folgt aus:
```yaml
apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
name:cloud-controller-manager
rules:
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- update
- apiGroups:
- ""
resources:
- nodes
verbs:
- '*'
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
- apiGroups:
- ""
resources:
- services
verbs:
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- create
- apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
- update
- watch
- apiGroups:
- ""
resources:
- endpoints
verbs:
- create
- get
- list
- watch
- update
```
## Anbieter Implementierung
Die folgenden Cloud Anbieter haben CCMs implementiert:
Eine vollständige Anleitung zur Konfiguration und zum Betrieb des CCM findest du [hier](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
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 %}}
@@ -20,11 +20,11 @@ Alle Kommunikationspfade vom Cluster zum Master enden beim Apiserver (keine der
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.
Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfiguriert 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.
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 instanziiert 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.
@@ -34,26 +34,26 @@ Der Standardbetriebsmodus für Verbindungen vom Cluster (Knoten und Pods, die au
## 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.
Der Erste ist vom Apiserver hin 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.
* Das Abrufen von Protokollen für Pods.
* Das Verbinden (durch kubectl) mit laufenden Pods.
* Die 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.
Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelets nicht, was die Verbindung angreifbar für Man-in-the-Middle-Angriffe macht. Die Kommunikation 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.
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 kubelets 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.
zwischen dem Apiserver und dem kubelet, falls es erforderlich ist 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 zusichern.
Außerdem sollte [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) aktiviert sein, um die kubelet-API abzusichern.
### Apiserver zu Nodes, Pods und Services
@@ -63,10 +63,10 @@ Diese Verbindungen **sind derzeit nicht sicher** innerhalb von nicht vertrauensw
### 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.
Kubernetes unterstützt SSH-Tunnel zum Schutz der Master -> Cluster Kommunikationspfade.
In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Node im Cluster (Verbindung mit dem SSH-Server, der mit 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.
SSH-Tunnel werden zur Zeit nicht unterstützt. Sie sollten also nicht verwendet werden, sei denn, man weiß, was man tut. 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.
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 %}}
@@ -64,13 +64,13 @@ Der Zustand eines Nodes wird als JSON-Objekt dargestellt. Die folgende Antwort b
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 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.
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.
@@ -79,13 +79,13 @@ Ebenso ignoriert der Scheduler die Bedingungen, wenn er einen Node berücksichti
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.
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
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 >}}
@@ -104,7 +104,7 @@ Die Informationen werden von Kubelet vom Node gesammelt.
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.
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:
@@ -123,7 +123,7 @@ Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
```
Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
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.
@@ -140,45 +140,45 @@ Aktuell gibt es drei Komponenten, die mit dem Kubernetes Node-Interface interagi
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 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).
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).
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).
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).
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.
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).
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.
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.
@@ -198,7 +198,7 @@ Zur Selbstregistrierung wird das kubelet mit den folgenden Optionen gestartet:
-`--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
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.
@@ -214,7 +214,7 @@ 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.
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
@@ -222,7 +222,7 @@ 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.
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 >}}
@@ -234,7 +234,7 @@ Sofern Sie [Manuelle Nodeverwaltung](#Manuelle-Nodeverwaltung) betreiben, müsse
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.
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).
Add-Ons erweitern die Funktionalität von Kubernetes.
Diese Seite gibt eine Übersicht über einige verfügbare Add-Ons und verweist auf die entsprechenden Installationsanleitungen.
Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenfolge impliziert keine bevorzugung einzelner Projekte.
{{% /capture %}}
{{% capture body %}}
## Networking und Network Policy
* [ACI](https://www.github.com/noironetworks/aci-containers) bietet Container-Networking und Network-Security mit Cisco ACI.
* [Calico](https://docs.projectcalico.org/latest/introduction/) ist ein Networking- und Network-Policy-Provider. Calico unterstützt eine Reihe von Networking-Optionen, damit Du die richtige für deinen Use-Case wählen kannst. Dies beinhaltet Non-Overlaying and Overlaying-Networks mit oder ohne BGP. Calico nutzt die gleiche Engine um Network-Policies für Hosts, Pods und (falls Du Istio & Envoy benutzt) Anwendungen auf Service-Mesh-Ebene durchzusetzen.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen.
* [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstützt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
* [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
* [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
* [Multus](https://github.com/Intel-Corp/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt.
* [Romana](http://romana.io) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein.
## Service-Discovery
* [CoreDNS](https://coredns.io) ist ein flexibler, erweiterbarer DNS-Server der in einem Cluster [installiert](https://github.com/coredns/deployment/tree/master/kubernetes) werden kann und das Cluster-interne DNS für Pods bereitzustellen.
## Visualisierung & Überwachung
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) ist ein Dashboard Web Interface für Kubernetes.
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) ist ein Tool um Container, Pods, Services usw. Grafisch zu visualieren. Kann in Verbindung mit einem [Weave Cloud Account](https://cloud.weave.works/) genutzt oder selbst gehosted werden.
## Infrastruktur
* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) ist ein Add-On um Virtuelle Maschinen in Kubernetes auszuführen. Wird typischer auf Bare-Metal Clustern eingesetzt.
## Legacy Add-Ons
Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)-Verzeichnis dokumentiert sind.
Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs!
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.
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.
Sie erstellen ihr Docker Image und laden es in eine Registry hoch bevor es in einem Kubernetes Pod referenziert werden kann.
Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags.
{{% /capture %}}
{{% capture body %}}
## Aktualisieren von Images
Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu das dass Kubelet Images überspringt die bereits auf einem Node vorliegen.
Wenn sie stattdessen möchten das ein Image immer forciert heruntergeladen wird, können sie folgendes tun:
- Die `imagePullPolicy` des Containers auf `Always` setzen.
- Die `imagePullPolicy` auslassen und `:latest` als Image Tag nutzen.
- Die `imagePullPolicy` und den Tag des Images auslassen.
- Den [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) Admission Controller aktivieren.
Beachten Sie das die die Nutzung des `:latest` Tags vermeiden sollten, weitere Informationen siehe: [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images).
## Multi-Architektur Images mit Manifesten bauen
Das Docker Kommandozeilenwerkzeug unterstützt jetzt das Kommando `docker manifest` mit den Subkommandos `create`, `annotate` and `push`.
Diese Kommandos können dazu genutzt werden Manifeste zu bauen und diese hochzuladen.
Weitere Informationen finden sie in der Docker Dokumentation:
Diese Kommandos basieren rein auf dem Docker Kommandozeileninterface und werden auch damit ausgeführt. Sie sollten entweder die Datei `$HOME/.docker/config.json` bearbeiten und den `experimental` Schlüssel auf `enabled`setzen, oder einfach die Umgebungsvariable `DOCKER_CLI_EXPERIMENTAL` auf `enabled`setzen wenn Sie das Docker Kommandozeileninterface aufrufen.
{{< note >}}
Nutzen die bitte Docker *18.06 oder neuer*, ältere Versionen haben entweder bugs oder unterstützen die experimentelle Kommandozeilenoption nicht. Beispiel: https://github.com/docker/cli/issues/1135 verursacht Probleme unter containerd.
{{< /note >}}
Wenn mit alten Manifesten Probleme auftreten können sie die alten Manifeste in `$HOME/.docker/manifests` entfernen um von vorne zu beginnen.
Für Kubernetes selbst haben wir typischerweise Images mit dem Suffix `-$(ARCH)` genutzt. Um die Abwärtskompatibilität zu erhalten bitten wir Sie die älteren Images mit diesen Suffixen zu generieren. Die Idee dahinter ist z.B. das `pause` image zu generieren, welches das Manifest für alle Architekturen hat, `pause-amd64` wäre dann abwärtskompatibel zu älteren Konfigurationen, oder YAML - Dateien die ein Image mit Suffixen hart kodiert haben.
## Nutzung einer privaten Registry
Private Registries könnten Schlüssel erfordern um Images von ihnen herunterzuladen.
Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden:
- Bei der Google Container Registry
- Je Cluster
- Automatisch in der Google Compute Engine oder Google Kubernetes Engine
- Allen Pods erlauben von der privaten Registry des Projektes lesen zu können
- Bei der Amazon Elastic Container Registry (ECR)
- IAM Rollen und Richtlinien nutzen um den Zugriff auf ECR Repositories zu kontrollieren
- Bei der Oracle Cloud Infrastructure Registry (OCIR)
- IAM Rollen und Richtlinien nutzen um den Zugriff auf OCIR Repositories zu kontrollieren
- Bei der Azure Container Registry (ACR)
- Bei der IBM Cloud Container Registry
- Nodes konfigurieren sich bei einer privaten Registry authentifizieren zu können
- Allen Pods erlauben von jeder konfigurierten privaten Registry lesen zu können
- Setzt die Konfiguration der Nodes durch einen Cluster - Aministrator voraus
- Im Voraus heruntergeladene Images
- Alle Pods können jedes gecachte Image auf einem Node nutzen
- Setzt root - Zugriff auf allen Nodes zum einrichten voraus
- Spezifizieren eines ImagePullSecrets bei einem Pod
- Nur Pods die eigene Schlüssel vorhalten haben Zugriff auf eine private Registry
Jeder Option wird im Folgenden im Detail beschrieben
### Bei Nutzung der Google Container Registry
Kubernetes hat eine native Unterstützung für die [Google Container
Registry (GCR)](https://cloud.google.com/tools/container-registry/) wenn es auf der Google Compute
Engine (GCE) läuft. Wenn Sie ihren Cluster auf GCE oder der Google Kubernetes Engine betreiben, genügt es einfach den vollen Image Namen zu nutzen (z.B. gcr.io/my_project/image:tag ).
Alle Pods in einem Cluster haben dann lesenden Zugriff auf Images in dieser Registry.
Das Kubelet authentifiziert sich bei GCR mit Nutzung des Google service Kontos der jeweiligen Instanz.
Das Google service Konto der Instanz hat einen `https://www.googleapis.com/auth/devstorage.read_only`, so kann es vom GCR des Projektes hochladen, aber nicht herunterladen.
### Bei Nutzung der Amazon Elastic Container Registry
Kubernetes eine native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) wenn Knoten AWS EC2 Instanzen sind.
Es muss einfach nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden.
Alle Benutzer eines Clusters die Pods erstellen dürfen können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen.
Das Kubelet wird periodisch ECR Zugriffsdaten herunterladen und auffrischen, es benötigt hierfür die folgenden Berechtigungen:
-`ecr:GetAuthorizationToken`
-`ecr:BatchCheckLayerAvailability`
-`ecr:GetDownloadUrlForLayer`
-`ecr:GetRepositoryPolicy`
-`ecr:DescribeRepositories`
-`ecr:ListImages`
-`ecr:BatchGetImage`
Voraussetzungen:
- Sie müssen Kubelet in der Version `v1.2.0` nutzen. (Führen sie z.B. (e.g. run `/usr/bin/kubelet --version=true` aus um die Version zu prüfen)
- Sie benötigen Version `v1.3.0` oder neuer wenn ihre Knoten in einer A - Region sind und sich ihre Registry in einer anderen B - Region befindet.
- ECR muss in ihrer Region angeboten werden
Fehlerbehebung:
- Die oben genannten Voraussetzungen müssen erfüllt sein
- Laden sie die $REGION (z.B. `us-west-2`) Zugriffsdaten auf ihren Arbeitsrechner. Verbinden sie sich per SSH auf den Host und nutzen die Docker mit diesen Daten. Funktioniert es?
- Prüfen sie ob das Kubelet it dem Parameter `--cloud-provider=aws` läuft.
- Prüfen sie die Logs des Kubelets (z.B. mit `journalctl -u kubelet`) auf Zeilen wie:
-`provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
### Bei Nutzung der Azure Container Registry (ACR)
Bei Nutzung der [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) können sie sich entweder als ein administrativer Nutzer, oder als ein Service Principal authentifizieren
In jedem Fall wird die Authentifizierung über die Standard - Docker Authentifizierung ausgeführt. Diese Anleitung bezieht sich auf das [azure-cli](https://github.com/azure/azure-cli) Kommandozeilenwerkzeug.
Sie müssen zunächst eine Registry und Authentifizierungsdaten erstellen, eine komplette Dokumentation dazu finden sie hier: [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
Sobald sie ihre Container Registry erstelt haben, nutzen sie die folgenden Authentifizierungsdaten:
*`DOCKER_USER` : Service Principal oder Administratorbenutzername
*`DOCKER_PASSWORD`: Service Principal Password oder Administratorpasswort
Wenn sie diese Variablen befüllt haben, können sie:
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Bei Nutzung der IBM Cloud Container Registry
Die IBM Cloud Container Registry bietet eine mandantenfähige Private Image Registry die Sie nutzen können um ihre Docker Images sicher speichern und teilen zu können.
Im Standard werden Images in ihrer Private Registry vom integrierten Schwachstellenscaner durchsucht um Sicherheitsprobleme und potentielle Schwachstellen zu finden. Benutzer können ihren IBM Cloud Account nutzen um Zugang zu ihren Images zu erhalten, oder um einen Token zu gernerieren, der Zugriff auf die Registry Namespaces erlaubt.
Um das IBM Cloud Container Registry Kommandozeilenwerkzeug zu installieren und einen Namespace für ihre Images zu erstellen, folgen sie dieser Dokumentation [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started).
Sie können die IBM Cloud Container Registry nutzen um Container aus [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) und ihren eigenen Images in den `default` Namespace ihres IBM Cloud Kubernetes Service Clusters zu deployen.
Um einen Container in einen anderen Namespace, oder um ein Image aus einer anderen IBM Cloud Container Registry Region oder einem IBM Cloud account zu deployen, erstellen sie ein Kubernetes `imagePullSecret`.
Weitere Informationen finden sie unter: [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images).
### Knoten für die Nutzung einer Private Registry konfigurieren
{{< note >}}
Wenn sie auf Google Kubernetes Engine laufen gibt es schon eine `.dockercfg` auf jedem Knoten die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden.
{{< /note >}}
{{< note >}}
Wenn sie auf AWS EC2 laufen und die EC2 Container Registry (ECR) nutzen, wird das Kubelet auf jedem Knoten die ECR Zugriffsdaten verwalten und aktualisieren. Dann kann die folgende Vorgehensweise nicht angewendet werden.
{{< /note >}}
{{< note >}}
Diese Vorgehensweise ist anwendbar wenn sie ihre Knoten - Konfiguration ändern können, sie wird nicht zuverlässig auf GCE other einem anderen Cloud - Provider funktionieren der automatisch Knoten ersetzt.
{{< /note >}}
{{< note >}}
Kubernetes unterstützt zur Zeit nur die `auths` und `HttpHeaders` Sektionen der Docker Konfiguration . Das bedeutet das die Hilfswerkzeuge (`credHelpers` ooderr `credsStore`) nicht unterstützt werden.
{{< /note >}}
Docker speichert Schlüssel für eigene Registries in der Datei `$HOME/.dockercfg` oder `$HOME/.docker/config.json`. Wenn sie die gleiche Datei in einen der unten aufgeführten Suchpfade ablegen wird Kubelet sie als Hilfswerkzeug für Zugriffsdaten nutzen wenn es Images bezieht.
*`{--root-dir:-/var/lib/kubelet}/config.json`
*`{cwd of kubelet}/config.json`
*`${HOME}/.docker/config.json`
*`/.docker/config.json`
*`{--root-dir:-/var/lib/kubelet}/.dockercfg`
*`{cwd of kubelet}/.dockercfg`
*`${HOME}/.dockercfg`
*`/.dockercfg`
{{< note >}}
Eventuell müssen sie `HOME=/root` in ihrer Umgebungsvariablendatei setzen
{{< /note >}}
Dies sind die empfohlenen Schritte um ihre Knoten für eine Nutzung einer eigenen Registry zu konfigurieren, in diesem Beispiel führen sie folgende Schritte auf ihrem Desktop/Laptop aus:
1. Führen sie `docker login [server]` für jeden Satz ihrer Zugriffsdaten aus. Dies aktualisiert `$HOME/.docker/config.json`.
2. Prüfen Sie `$HOME/.docker/config.json` in einem Editor darauf ob dort nur Zugriffsdaten enthalten sind die Sie nutzen möchten.
3. Erhalten sie eine Liste ihrer Knoten:
- Wenn sie die Namen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
- Wenn sie die IP - Adressen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
4. Kopieren sie ihre lokale `.docker/config.json` in einen der oben genannten Suchpfade.
- Zum Beispiel: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
Prüfen durch das Erstellen eines Pods der ein eigenes Image nutzt, z.B.:
```yaml
kubectl apply -f - <<EOF
apiVersion:v1
kind:Pod
metadata:
name:private-image-test-1
spec:
containers:
- name:uses-private-image
image:$PRIVATE_IMAGE_NAME
imagePullPolicy:Always
command:["echo","SUCCESS"]
EOF
pod/private-image-test-1 created
```
Wenn alles funktioniert sollten sie nach einigen Momenten folgendes sehen:
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19{kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
Sie müssen sich darum kümmern das alle Knoten im Cluster die gleiche `.docker/config.json` haben, anderenfalls werden Pods auf einigen Knoten starten, auf anderen jedoch nicht.
Wenn sie zum Beispiel Knoten automatisch Skalieren lassen, sollte dann jedes Instanztemplate die `.docker/config.json` beinhalten, oder ein Laufwerk einhängen die diese beinhaltet.
Alle Pods haben Lesezugriff auf jedes Image in ihrer eigenen Registry sobald die Registry - Schlüssel zur `.docker/config.json` hinzugefügt wurden.
### Im Voraus heruntergeladene Images
{{< note >}}
Wenn sie auf Google Kubernetes Engine laufen gibt es schon eine `.dockercfg` auf jedem Knoten die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden.
{{< /note >}}
{{< note >}}
Diese Vorgehensweise ist anwendbar wenn sie ihre Knoten - Konfiguration ändern können, sie wird nicht zuverlässig auf GCE other einem anderen Cloud - Provider funktionieren der automatisch Knoten ersetzt.
{{< /note >}}
Im Standard wird das Kubelet versuchen jedes Image von der spezifizierten Registry herunterzuladen.
Falls jedoch die `imagePullPolicy` Eigenschaft der Containers auf `IfNotPresent` oder `Never` gesetzt wurde, wird ein lokales Image genutzt (präferiert oder exklusiv, je nach dem).
Wenn Sie sich auf im Voraus heruntergeladene Images als Ersatz für eine Registry - Authentifizierung verlassen möchten, müssen sie sicherstellen das alle Knoten die gleichen im voraus heruntergeladenen Images aufweisen.
Diese Medthode kann dazu genutzt werden bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
Alle Pods haben Leserechte auf alle im Voraus geladenen Images.
### Spezifizieren eines ImagePullSecrets für einen Pod
{{< note >}}
Diese Vorgehensweise ist aktuell die empfohlene Vorgehensweise für Google Kubernetes Engine, GCE, und jeden Cloud - Provider bei dem die Knotenerstelltung automatisiert ist.
{{< /note >}}
Kubernetes unterstützt die Spezifikation von Registrierungsschlüsseln für einen Pod.
#### Erstellung eines Secrets mit einer Docker Konfiguration
Führen sie foldenen Befehl mit Ersetzung der groß geschriebenen Werte aus:
Wenn sie bereits eine Datei mit Docker Zugriffsdaten haben, könenn sie die Zugriffsdaten als ein Kubernetes Secret importieren:
[Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) beschreibt die Erstellung.
Dies ist insbesondere dann sinnvoll wenn sie mehrere eigene Container Registries nutzen, da `kubectl create secret docker-registry` ein Secret erstellt das nur mit einer einzelnen eigenen Registry funktioniert.
{{< note >}}
Pods können nur eigene Image Pull Secret in ihrem eigenen Namespace referenzieren, somit muss dieser Prozess jedes mal einzeln für je Namespace angewendet werden.
{{< /note >}}
#### Referenzierung eines imagePullSecrets bei einem Pod
Nun können sie Pods erstellen die dieses Secret referenzieren indem sie eine `imagePullSecrets` Sektion zu ihrer Pod - Definition hinzufügen.
```shell
cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF
```
Dies muss für jeden Pod getan werden der eine eigene Registry nutzt.
Die Erstellung dieser Sektion kann jedoch automatisiert werden indem man imagePullSecrets einer serviceAccount](/docs/user-guide/service-accounts) Ressource hinzufügt.
[Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) bietet detaillierte Anweisungen hierzu.
Sie können dies in Verbindung mit einer auf jedem Knoten genutzten `.docker/config.json` benutzen, die Zugriffsdaten werden dann zusammengeführt. Dieser Vorgehensweise wird in der Google Kubernetes Engine funktionieren.
### Anwendungsfälle
Es gibt eine Anzahl an Lösungen um eigene Registries zu konfigurieren, hier sind einige Anwendungsfälle und empfohlene Lösungen.
1. Cluster die nur nicht-proprietäre Images (z.B. open-source) ausführen. Images müssen nicht versteckt werden.
- Nutzung von öffentlichen Images auf Docker Hub.
- Keine Konfiguration notwendig.
- Auf GCE/Google Kubernetes Engine, wird automatisch ein lokaler Spiegel für eine verbesserte Geschwindigkeit und Verfügbarkeit genutzt.
2. Cluster die einige proprietäre Images ausführen die für Außenstehende nicht sichtbar sein dürfen, aber für alle Cluster - Benutzer sichtbar sein sollen.
- Nutzung einer gehosteten privaten Registry [Docker registry](https://docs.docker.com/registry/).
- Kann auf [Docker Hub](https://hub.docker.com/signup), oder woanders gehostet werden.
- Manuelle Konfiguration der .docker/config.json auf jedem Knoten, wie oben beschrieben.
- Der Betrieb einer internen privaten Registry hinter ihrer Firewall mit offenen Leseberechtigungen.
- Keine Kubernetes - Konfiguration notwendig
- Wenn GCE/Google Kubernetes Engine genutzt wird, nutzen sie die Google Container Registry des Projektes.
- Funktioniert besser mit Cluster - Autoskalierung als mit manueller Knotenkonfiguration.
- Auf einem Cluster bei dem die Knotenkonfiguration ungünstig ist können `imagePullSecrets` genutzt werden.
3. Cluster mit proprieritären Images, mit einigen Images die eine erweiterte Zugriffskontrolle erfordern.
- Stellen sie sicher das [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben.
- Verschieben sie sensitive Daten in eine "Secret" Ressource statt sie im Image abzulegen.
4. Ein mandantenfähiger Cluster in dem jeder Mandant eine eigene private Registry benötigt.
- Stellen sie dicher das [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben.
- Nutzen sie eine private Registry die eine Authorisierung erfordert.
- Generieren die Registry - Zugriffsdaten für jeden Mandanten, abgelegt in einem Secret das in jedem Mandanten - Namespace vorhanden ist.
- Der Mandant fügt dieses Sercret zu den imagePullSecrets in jedem seiner Namespace hinzu.
{{% /capture %}}
Falls die Zugriff auf mehrere Registries benötigen, können sie ein Secret für jede Registry erstellen, Kubelet wird jedwede `imagePullSecrets` in einer einzelnen `.docker/config.json` zusammenfassen.
@@ -50,7 +50,7 @@ Der cloud-controller-manager ist eine Alpha-Funktion, die in Kubernetes Version
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.
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.
@@ -81,7 +81,7 @@ Kubernetes unterstützt mehrere Laufzeiten: [Docker](http://www.docker.com), [co
## Addons
Addons sind Pods und Dienste, die Clusterfunktionen implementieren. Die Pods können verwaltet werden
durch Deployments, ReplicationControllers, und so wieter.
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/).
@@ -14,10 +14,10 @@ Diese Seite ist eine Übersicht über Kubernetes.
{{% capture body %}}
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.
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
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?
@@ -29,65 +29,65 @@ Kubernetes hat eine Reihe von Funktionen. Es kann gesehen werden als:
- 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
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
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
[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
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
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
* 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
* 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
* 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)).
* 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
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.
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?
@@ -96,33 +96,33 @@ 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!
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/).
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 %}}
@@ -20,12 +20,12 @@ Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gesta
## 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 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 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.
Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.
aka:
aka:
tags:
- architecture
- storage
---
Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.
<!--more-->
<!--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).
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://etcd.io/docs).
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
aka:
aka:
tags:
- architecture
- fundamental
---
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.
<!--more-->
<!--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:
aka:
tags:
- architecture
- fundamental
---
Komponente auf dem Master, auf dem {{< glossary_tooltip text="controllers" term_id="controller" >}} ausgeführt werden.
<!--more-->
<!--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:
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-->
<!--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:
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-->
<!--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.
kubectl apply -f ./my1.yaml -f ./my2.yaml # aus mehreren Dateien erstellen
kubectl apply -f ./dir # Erstellen Sie Ressourcen in allen Manifestdateien in Verzeichnis
kubectl apply -f https://git.io/vPieo # Ressource(n) aus URL erstellen
kubectl create deployment nginx --image=nginx # Starten Sie eine einzelne Instanz von Nginx
kubectl explain pods,svc # Zeigen Sie die Dokumentation für Pod und SVC Manifeste an
@@ -133,7 +133,7 @@ kubectl get services # Listen Sie alle Dienste im Names
kubectl get pods --all-namespaces # Listen Sie alle Pods in allen Namespaces auf
kubectl get pods -o wide # Listen Sie alle Pods im Namespace mit weiteren Details auf
kubectl get deployment my-dep # Listen Sie eine bestimmte Bereitstellung auf
kubectl get pods --include-uninitialized # Listen Sie alle Pods im Namespace auf, einschließlich der nicht initialisierten
kubectl get pods # Listen Sie alle Pods im Namespace auf
# Describe Befehle mit ausführlicher Ausgabe
kubectl describe nodes my-node
@@ -180,7 +180,7 @@ 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`.
Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/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 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 -n my-ns delete po,svc --all # Löscht alle Pods und Dienste, im Namespace my-ns
@@ -12,7 +12,7 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem
[`kubectl`](/docs/tasks/tools/install-kubectl/) ist ein Kommandozeilenprogramm für Kubernetes. Es steuert den Kubernetes Clustermanager.
## Kubeadm
## 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).
@@ -24,7 +24,7 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem
[`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
[`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.
@@ -34,10 +34,10 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem
Verwenden Sie Helm um:
* Beliebte Software verpackt als Kubernetes charts zu finden und zu verwenden
* 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
* Intelligenten Verwaltung von Ihren Kubernetes manifest files
Auf dieser Seite finden Sie die Lösung, die Ihren Anforderungen am besten entspricht.
Diese Sektion umfasst verschiedene Optionen zum Einrichten und Betrieb von Kubernetes.
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.
Verschiedene Kubernetes Lösungen haben verschiedene Anforderungen: Einfache Wartung, Sicherheit, Kontrolle, verfügbare Resourcen und erforderliches Fachwissen zum Betrieb und zur Verwaltung dess folgende Diagramm zeigt die möglichen Abstraktionen eines Kubernetes-Clusters und ob eine Abstraktion selbst verwaltet oder von einem Anbieter verwaltet wird.
Sie können einen Kubernetes-Cluster auf einer lokalen Maschine, Cloud, On-Prem Datacenter bereitstellen; oder wählen Sie einen verwalteten Kubernetes-Cluster. Sie können auch eine individuelle Lösung über eine grosse Auswahl an Cloud Anbietern oder Bare-Metal-Umgebungen nutzen.
Noch einfacher können Sie einen Kubernetes-Cluster in einer Lern- und Produktionsumgebung erstellen.
{{% /capture %}}
{{% capture body %}}
## Lösungen für lokale Maschinen
## Lernumgebung
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.
Benutzen Sie eine Docker-basierende Lösung, wenn Sie Kubernetes erlernen wollen: Von der Kubernetes-Community unterstützte Werkzeuge oder Werkzeuge in einem Ökosystem zum Einrichten eines Kubernetes-Clusters auf einer lokalen Maschine.
Sie sollten eine lokale Lösung auswählen, wenn Sie:
{{< table caption="Tabelle mit Lösungen für lokale Maschinen, in der die Tools aufgeführt sind, die von der Community und dem Ökosystem für die Bereitstellung von Kubernetes unterstützt werden." >}}
* 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
|Community |Ökosystem |
| ------------ | -------- |
| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
| | [k3s](https://k3s.io)|
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.
## Produktionsumgebung
Sie sollten eine schlüsselfertige Cloud-Lösung auswählen, wenn Sie:
Überlegen Sie sich bei der Bewertung einer Lösung für eine Produktionsumgebung, welche Aspekte des Betriebs eines Kubernetes-Clusters (oder von _abstractions_) Sie selbst verwalten oder an einen Anbieter auslagern möchten.
* Mehr Kontrolle über Ihre Cluster haben möchten, als die gehosteten Lösungen zulassen
* Mehr operative Verantwortung übernehmen Möchten
Einige mögliche Abstraktionen von Kubernetes-Clustern sind {{< glossary_tooltip text="applications" term_id="applications" >}}, {{< glossary_tooltip text="data plane" term_id="data-plane" >}}, {{< glossary_tooltip text="control plane" term_id="control-plane" >}}, {{< glossary_tooltip text="cluster infrastructure" term_id="cluster-infrastructure" >}} und {{< glossary_tooltip text="cluster operations" term_id="cluster-operations" >}}.
Wählen Sie eine [schlüsselfertige Cloud-Lösung](/de/docs/setup/) aus.
Das folgende Diagramm zeigt die möglichen Abstraktionen eines Kubernetes-Clusters und ob eine Abstraktion selbst verwaltet oder von einem Anbieter verwaltet wird.
## Schlüsselfertige On-Premises-Lösungen
Lösungen für Produktionsumgebungen
Mit diesen Lösungen können Sie Kubernetes-Cluster mit nur wenigen Befehlen in Ihrem internen, sicheren Cloud-Netzwerk erstellen.
{{< table caption="Tabelle für Produktionsumgebungs-Lösungen listet Anbieter und deren Lösungen auf." >}}
Sie sollten eine schlüsselfertige lokal betriebene Cloud-Lösung auswählen, wenn Sie:
Die folgende Tabelle für Produktionsumgebungs-Lösungen listet Anbieter und deren Lösungen auf.
* 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.
# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten,
# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten,
# bis der Pod betriebsbereit ist, bevor wir über den exponierten Dienst auf ihn zugreifen können.
# Um zu überprüfen, ob der Pod läuft, können wir Folgendes verwenden:
kubectl get pod
@@ -164,7 +164,7 @@ minikube start \
#### CRI-O
Um [CRI-O](https://github.com/kubernetes-incubator/cri-o) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
Um [CRI-O](https://cri-o.io/) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
```bash
minikube start \
@@ -205,7 +205,7 @@ Weitere Informationen zu unterstützten Treibern und zur Installation von Plugin
### 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.
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 importieren 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:
@@ -88,7 +88,7 @@ Schließlich, kurz bevor HPA das Ziel skaliert, wird die Skalierungsempfehlung a
Der Horizontal Pod Autoscaler ist eine API Ressource in der Kubernetes `autoscaling` API Gruppe.
Die aktuelle stabile Version, die nur die Unterstützung für die automatische Skalierung der CPU beinhaltet, befindet sich in der `autoscaling/v1` API Version.
Die Beta-Version, weclhe die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.
Die Beta-Version, welche die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.
Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.
@@ -131,6 +131,7 @@ Beim Abstimmen dieser Parameterwerte sollte sich ein Clusterbetreiber der mögli
Kubernetes 1.6 bietet Unterstützung für die Skalierung basierend auf mehreren Metriken. Du kannst die API Version `autoscaling/v2beta2` verwenden, um mehrere Metriken für den Horizontal Pod Autoscaler zum Skalieren festzulegen. Anschließend wertet der Horizontal Pod Autoscaler Controller jede Metrik aus und schlägt eine neue Skalierung basierend auf diesen Metrik vor. Die größte der vorgeschlagenen Skalierung wird als neue Skalierung verwendet.
## Unterstützung von benutzerdefinierte Metriken
{{< note >}}
Kubernetes 1.2 bietet Alpha Unterstützung für die Skalierung basierend auf anwendungsspezifischen Metriken über speziellen Annotations. Die Unterstützung für diese Annotations wurde in Kubernetes 1.6 zugunsten der neuen autoskalierenden API entfernt. Während die alte Methode zum Sammeln von benutzerdefinierten Metriken weiterhin verfügbar ist, stehen diese Metriken dem Horizontal Pod Autoscaler nicht mehr zur Verfügung, ebenso wenig wie die früheren Annotations zur Angabe, welche benutzerdefinierten Metriken zur Skalierung vom Horizontal Pod Autoscaler Controller berücksichtigt werden sollen.
{{< /note >}}
@@ -148,14 +149,14 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
* Der [API Aggregations Layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) aktiviert ist.
* Die entsprechenden APIs registriert sind:
* Für Ressourcenmetriken ist dies die API `metrics.k8s.io`, die im Allgemeinen von [metrics-server](https://github.com/kubernetes-incubator/metrics-server) bereitgestellt wird.
* Für Ressourcenmetriken ist dies die API `metrics.k8s.io`, die im Allgemeinen von [metrics-server](https://github.com/kubernetes-incubator/metrics-server) bereitgestellt wird.
Es kann als Cluster-Addon gestartet werden.
* Für benutzerdefinierte Metriken ist dies die API `custom.metrics.k8s.io`. Diese wird vom "Adapter" API Servern bereitgestellt, welches von Anbietern von Metrik Lösungen beliefert wird.
Überprüfe dies mit deiner Metrik Pipeline oder der [Liste bekannter Lösungen](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
Falls du deinen eigenen schreiben möchtest hilft dir folgender [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) um zu starten.
* Für externe Metriken ist dies die `external.metrics.k8s.io` API. Es kann sein, dass dies durch den benutzerdefinierten Metrik Adapter bereitgestellt wird.
* Das Flag `--horizontal-pod-autoscaler-use-rest-clients` ist auf `true` oder ungesetzt. Wird dies auf `false` gesetzt wird die Heapster basierte Autoskalierung aktiviert, welche veraltet ist.
Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten.
Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten.
Mit kubectl können Sie Clusterressourcen überprüfen, Komponenten erstellen, löschen und aktualisieren; Ihren neuen Cluster betrachten; und Beispielanwendungen aufrufen.
{{% /capture %}}
@@ -90,7 +90,7 @@ Wenn Sie mit macOS arbeiten und den [Macports](https://macports.org/) Paketmanag
sudo port selfupdate
sudo port install kubectl
```
2. Testen Sie, ob die installierte Version ausreichend aktuell ist:
```
@@ -107,9 +107,9 @@ Wenn Sie mit Windows arbeiten und den [Powershell Gallery](https://www.powershel
Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` mit der jeweiligen Version.
Um beispielsweise die Version {{< param "fullversion" >}} auf macOS herunterzuladen, verwenden Sie den folgenden Befehl:
@@ -225,7 +225,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` mit der jeweiligen Version.
Um beispielsweise die Version {{< param "fullversion" >}} auf Linux herunterzuladen, verwenden Sie den folgenden Befehl:
@@ -243,7 +243,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
```
{{% /tab %}}
{{% tab name="Windows" %}}
1. Laden Sie das aktuellste Release {{< param "fullversion" >}} von [disem link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe) herunter.
1. Laden Sie das aktuellste Release {{< param "fullversion" >}} von [diesem link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe) herunter.
Oder, sofern Sie `curl` installiert haven, verwenden Sie den folgenden Befehl:
@@ -261,7 +261,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
## kubectl konfigurieren
Damit kubectl einen Kubernetes-Cluster finden und darauf zugreifen kann, benötigt es eine [kubeconfig Datei](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). Diese wird automatisch erstellt, wenn Sie einen Cluster mit kube-up.sh erstellen oder einen Minikube-Cluster erfolgreich implementieren. Weitere Informationen zum Erstellen von Clustern finden Sie in den [Anleitungen für die ersten Schritte](/docs/setup/). Wenn Sie Zugriff auf einen Cluster benötigen, den Sie nicht erstellt haben, lesen Sie die [Cluster-Zugriff freigeben Dokumentation](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
Damit kubectl einen Kubernetes-Cluster finden und darauf zugreifen kann, benötigt es eine [kubeconfig Datei](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). Diese wird automatisch erstellt, wenn Sie einen Cluster mit [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) erstellen oder einen Minikube-Cluster erfolgreich implementieren. Weitere Informationen zum Erstellen von Clustern finden Sie in den [Anleitungen für die ersten Schritte](/docs/setup/). Wenn Sie Zugriff auf einen Cluster benötigen, den Sie nicht erstellt haben, lesen Sie die [Cluster-Zugriff freigeben Dokumentation](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
Die kubectl-Konfiguration befindet sich standardmäßig unter `~/.kube/config`.
Schließen Sie nach der Installation von Minikube die aktuelle CLI-Sitzung und starten Sie sie neu. Minikube sollte automatisch zu Ihrem Pfad hinzugefügt werden.
#### Manuelle installation unter Windows
#### Manuelle installation unter Windows
Um Minikube manuell unter Windows zu installieren, laden Sie die Datei [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest) herunter, umbenennen Sie sie in `minikube.exe` und fügen Sie sie Ihrem Pfad zu.
Dieser Abschnitt der Kubernetes-Dokumentation enthält Tutorials.
Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/).
Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/).
Ein Tutorial besteht normalerweise aus mehreren Abschnitten, die jeweils eine Abfolge von Schritten haben.
Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise ein Lesezeichen zur Seite mit dem [Standardisierten Glossar](/docs/reference/glossary/) setzen um später Informationen nachzuschlagen.
<p>Sind Sie bereit, Ihre Hände schmutzig zu machen? Erstellen Sie einen einfachen Kubernetes-Cluster, auf dem "Hallo Welt" für Node.js ausgeführt wird.</p>
card:
card:
name: tutorials
weight: 10
---
@@ -62,7 +62,7 @@ Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumenta
3. In einer Katacoda-Umgebung: Klicken Sie oben im Terminalbereich auf das Pluszeichen und anschließend auf **Select port to view on Host 1**.
4. In einer Katacoda-Umgebung: Geben Sie `30000` ein und klicken Sie dann auf **Display Port**.
4. In einer Katacoda-Umgebung: Geben Sie `30000` ein und klicken Sie dann auf **Display Port**.
## Erstellen eines Deployments
@@ -71,8 +71,8 @@ Der Pod in diesem Tutorial hat nur einen Container.
Ein Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) überprüft den Zustand Ihres Pods und startet den Container des Pods erneut, wenn er beendet wird.
Deployments sind die empfohlene Methode zum Verwalten der Erstellung und Skalierung von Pods.
1. Verwenden Sie den Befehl `kubectl create`, um ein Deployment zu erstellen, die einen Pod verwaltet.
Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus.
1. Verwenden Sie den Befehl `kubectl create`, um ein Deployment zu erstellen, die einen Pod verwaltet.
Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus.
<p>Bei modernen Webservices erwarten Benutzer, dass Anwendungen rund um die Uhr verfügbar sind, und Entwickler erwarten, mehrmals täglich neue Versionen dieser Anwendungen bereitzustellen (deployen).
Containerisierung hilft bei der Paketierung von Software, um diese Ziele zu erreichen, sodass Anwendungen einfach und schnell ohne Ausfallzeiten veröffentlicht und aktualisiert werden können. Kubernetes hilft Ihnen dabei, sicherzustellen, dass diese Containeranwendungen immer dort laufen, wo und wann Sie möchten, und hilft ihnen, die Ressourcen und Tools zu finden, die sie zum Arbeiten benötigen. Kubernetes ist eine produktionsbereite Open-Source-Plattform, die auf der gesammelten Erfahrung von Google in der Container-Orchestrierung basiert und mit den besten Ideen der Community kombiniert wird.</p>
<p>Bei modernen Webservices erwarten Benutzer, dass Anwendungen rund um die Uhr verfügbar sind, und Entwickler erwarten, mehrmals täglich neue Versionen dieser Anwendungen bereitzustellen (deployen).
Containerisierung hilft bei der Paketierung von Software, um diese Ziele zu erreichen, sodass Anwendungen einfach und schnell ohne Ausfallzeiten veröffentlicht und aktualisiert werden können. Kubernetes hilft Ihnen dabei, sicherzustellen, dass diese Containeranwendungen immer dort laufen, wo und wann Sie möchten, und hilft Ihnen, die Ressourcen und Tools zu finden, die Sie zum Arbeiten benötigen. Kubernetes ist eine produktionsbereite Open-Source-Plattform, die auf der gesammelten Erfahrung von Google in der Container-Orchestrierung basiert und mit den besten Ideen der Community kombiniert wird.</p>
Sobald Sie einen Kubernetes-Cluster ausgeführt haben, können Sie Ihre containerisierten Anwendungen darüber bereitstellen.
Dazu erstellen Sie eine Kubernetes <b>Deployment</b>-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer
Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten
Dazu erstellen Sie eine Kubernetes <b>Deployment</b>-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer
Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten
Anwendungsinstanzen für einzelne Nodes im Cluster.
</p>
<p>Sobald die Anwendungsinstanzen erstellt wurden, überwacht ein Kubernetes Deployment Controller diese Instanzen kontinuierlich. Wenn der Node, der eine Instanz hostet, ausfällt oder gelöscht wird, ersetzt der Deployment Controller die Instanz durch eine Instanz auf einem anderen Node im Cluster. <b>Dies bietet einen Selbstheilungsmechanismus, um Maschinenausfälle oder -wartungen zu vermeiden.</b></p>
<p>In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall.
<p>In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall.
Kubernetes Deployments erstellen Ihre Anwendungsinstanzen und sorgen dafür, dass sie über mehrere Nodes hinweg ausgeführt werden. Dadurch bieten Kubernetes Deployments einen grundlegend anderen Ansatz für die Anwendungsverwaltung.</p>
</div>
@@ -74,7 +74,7 @@ weight: 10
<divclass="row">
<divclass="col-md-8">
<p>Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle <b>Kubectl</b> erstellen und verwalten.
<p>Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle <b>Kubectl</b> erstellen und verwalten.
Kubectl verwendet die Kubernetes-API, um mit dem Cluster zu interagieren.
In diesem Modul lernen Sie die gebräuchlichsten Kubectl-Befehle kennen, die zum Erstellen von Deployments zum Ausführen Ihrer Anwendungen in einem Kubernetes-Cluster erforderlich sind.</p>
@@ -45,12 +45,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
<br>
<br>
<br>
<ahref="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019"buttonid="desktopKCButton">Attend KubeCon in San Diego on Nov. 18-21, 2019</a>
<ahref="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20"buttonid="desktopKCButton">Attend KubeCon in Amsterdam in July/August TBD</a>
<br>
<br>
<br>
<br>
<ahref="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/"buttonid="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
<ahref="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20"buttonid="desktopKCButton">Attend KubeCon in Boston on November 17-20, 2020</a>
@@ -50,7 +50,7 @@ Zend Server - The Complete PHP Application Platform
This list will grow, and is curated [here](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
This list will grow, and is curated [here](https://opendev.org/x/k8s-docker-suite-app-murano/src/branch/master/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://opendev.org/x/k8s-docker-suite-app-murano/src/branch/master/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
@@ -30,19 +30,19 @@ When you start thinking in terms of Pods, there are naturally some general patte
Sidecar containers extend and enhance the "main" container, they take existing containers and make them better. As an example, consider a container that runs the Nginx web server. Add a different container that syncs the file system with a git repository, share the file system between the containers and you have built Git push-to-deploy. But you’ve done it in a modular manner where the git synchronizer can be built by a different team, and can be reused across many different web servers (Apache, Python, Tomcat, etc). Because of this modularity, you only have to write and test your git synchronizer once and reuse it across numerous apps. And if someone else writes it, you don’t even need to do that.
Ambassador containers proxy a local connection to the world. As an example, consider a Redis cluster with read-replicas and a single write master. You can create a Pod that groups your main application with a Redis ambassador container. The ambassador is a proxy is responsible for splitting reads and writes and sending them on to the appropriate servers. Because these two containers share a network namespace, they share an IP address and your application can open a connection on “localhost” and find the proxy without any service discovery. As far as your main application is concerned, it is simply connecting to a Redis server on localhost. This is powerful, not just because of separation of concerns and the fact that different teams can easily own the components, but also because in the development environment, you can simply skip the proxy and connect directly to a Redis server that is running on localhost.
Adapter containers standardize and normalize output. Consider the task of monitoring N different applications. Each application may be built with a different way of exporting monitoring data. (e.g. JMX, StatsD, application specific statistics) but every monitoring system expects a consistent and uniform data model for the monitoring data it collects. By using the adapter pattern of composite containers, you can transform the heterogeneous monitoring data from different systems into a single unified representation by creating Pods that groups the application containers with adapters that know how to do the transformation. Again because these Pods share namespaces and file systems, the coordination of these two containers is simple and straightforward.
In all of these cases, we've used the container boundary as an encapsulation/abstraction boundary that allows us to build modular, reusable components that we combine to build out applications. This reuse enables us to more effectively share containers between different developers, reuse our code across multiple applications, and generally build more reliable, robust distributed systems more quickly. I hope you’ve seen how Pods and composite container patterns can enable you to build robust distributed systems more quickly, and achieve container code re-use. To try these patterns out yourself in your own applications. I encourage you to go check out open source Kubernetes or Google Container Engine.
@@ -95,7 +95,7 @@ Mesosphere has incorporated Kubernetes into its Data Center Operating System (DC
|
[Platalytics, Inc][24]. and announced the release of one-touch deploy-anywhere feature for its Spark Application Platform. Based on Kubernetes, Docker, and CoreOS, it allows simple and automated deployment of Apache Hadoop, Spark, and Platalytics platform, with a single click, to all major public clouds, including Google, Amazon, Azure, DigitalOcean, and private on-premise clouds. It also enables hybrid cloud scenarios, where resources on public and private clouds can be mixed.
[Platalytics, Inc][24]. and announced the release of one-touch deploy-anywhere feature for its Spark Application Platform. Based on Kubernetes, Docker, and CoreOS, it allows simple and automated deployment of Apache Hadoop, Spark, and Platalytics platform, with a single click, to all major public clouds, including Google, Amazon, Azure, DigitalOcean, and private on-premise clouds. It also enables hybrid cloud scenarios, where resources on public and private clouds can be mixed.
So there you have it, nine new and exciting things you can do with your Kubernetes cluster and the kubectl command line. If you’re just getting started with Kubernetes, check out [Google Container Engine](https://cloud.google.com/container-engine/) or other ways to [get started with Kubernetes](http://kubernetes.io/gettingstarted/).
So there you have it, nine new and exciting things you can do with your Kubernetes cluster and the kubectl command line. If you’re just getting started with Kubernetes, check out [Google Container Engine](https://cloud.google.com/container-engine/) or other ways to [get started with Kubernetes](/docs/tutorials/kubernetes-basics/).
@@ -46,7 +46,7 @@ As we mentioned above, we would love your help:
- Connect with the community on [Slack](http://slack.kubernetes.io/)
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
- Post questions (or answer questions) on Stackoverflow
- Get started running, deploying, and using Kubernetes [guides](http://kubernetes.io/gettingstarted/)
- Get started running, deploying, and using Kubernetes [guides](/docs/tutorials/kubernetes-basics/);
But, most of all, just let us know how you are transforming your business using Kubernetes, and how we can help you do it even faster. Thank you for your support!
@@ -11,7 +11,7 @@ People familiar with [Puppet](https://github.com/puppetlabs/puppet) might h
### The Puppet Kubernetes Module
The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](http://kubernetes.io/gettingstarted/). Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.
The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](/docs/tutorials/kubernetes-basics/);Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.
_Editor's note: this is the first in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_
We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience — the 99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).
We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience — the 99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).
Words are fine, but nothing speaks louder than a demo. Check this out!
_Editor's note: this is the third post in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_
@@ -11,7 +11,7 @@ _Editor's note: this is the third post in a [series of in-depth posts](https://k
### Introduction
One of the most frequently-requested features for Kubernetes is the ability to run applications across multiple zones. And with good reason — developers need to deploy applications across multiple domains, to improve availability in thxe advent of a single zone outage.
[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.
[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.
Multi-zone clusters are deliberately simple, and by design, very easy to use — no Kubernetes API changes were required, and no application changes either. You simply deploy your existing Kubernetes application into a new-style multi-zone cluster, and your application automatically becomes resilient to zone failures.
The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
@@ -21,7 +21,7 @@ Our mission is to make building distributed systems easy and accessible for all.
|
3/29
|
\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)
\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
\* Guest post by AppFormix: [Helping Enterprises Operationalize Kubernetes](https://kubernetes.io/blog/2016/03/appformix-helping-enterprises)
|
|
@@ -32,7 +32,7 @@ Our mission is to make building distributed systems easy and accessible for all.
|
3/31
|
\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress)
\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/)
_Editor's note: This is the sixth post in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2._
_Ingress is currently in beta and under active development._
Today we released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet.
@@ -42,7 +42,7 @@ Our heaviest use of the Kubernetes API is definitely our system of creating dyna
**Ingresses**
In order to provide a backend for HTTP API calls and allow self-registration of handlers we make use of the Ingress system in Kubernetes. It wasn't the clearest thing to set up, but reading through enough of the [nginx example](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) eventually got us to a good spot where it is easy to connect services to the frontend.
In order to provide a backend for HTTP API calls and allow self-registration of handlers we make use of the Ingress system in Kubernetes. It wasn't the clearest thing to set up, but reading through enough of the [nginx example](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) eventually got us to a good spot where it is easy to connect services to the frontend.
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
Customers using Kubernetes respond to end user requests quickly and ship software faster than ever before. But what happens when you build a service that is even more popular than you planned for, and run out of compute? In [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we are proud to announce that we have a solution: autoscaling. On [Google Compute Engine](https://cloud.google.com/compute/) (GCE) and [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) (and coming soon on [AWS](https://aws.amazon.com/)), Kubernetes will automatically scale up your cluster as soon as you need it, and scale it back down to save you money when you don’t.
Customers using Kubernetes respond to end user requests quickly and ship software faster than ever before. But what happens when you build a service that is even more popular than you planned for, and run out of compute? In [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we are proud to announce that we have a solution: autoscaling. On [Google Compute Engine](https://cloud.google.com/compute/) (GCE) and [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) (and coming soon on [AWS](https://aws.amazon.com/)), Kubernetes will automatically scale up your cluster as soon as you need it, and scale it back down to save you money when you don’t.
@@ -21,7 +21,7 @@ I wish all our experiences working together with a technical partner were as goo
Next, NetScaler CPX needed to be inserted in the data path of GCP ingress load balancer so that NetScaler CPX can spread traffic to front end web servers. The NetScaler team made modifications so that NetScaler CPX listens to API server events and configures itself to create a VIP, IP table rules and server rules to take ingress traffic and load balance across front end applications. Google Cloud Platform team provided feedback and assistance to verify modifications made to overcome the technical hurdles. Done!
NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.
NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.
You can learn more about NetScaler CPX [here](https://www.citrix.com/networking/microservices.html).
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
As Kubernetes users scale their production deployments we’ve heard a clear desire to deploy services across zone, region, cluster and cloud boundaries. Services that span clusters provide geographic distribution, enable hybrid and multi-cloud scenarios and improve the level of high availability beyond single cluster multi-zone deployments. Customers who want their services to span one or more (possibly remote) clusters, need them to be reachable in a consistent manner from both within and outside their clusters.
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
[Kubernetes Dashboard](http://github.com/kubernetes/dashboard) is a project that aims to bring a general purpose monitoring and operational web interface to the Kubernetes world. Three months ago we [released](https://kubernetes.io/blog/2016/04/building-awesome-user-interfaces-for-kubernetes) the first production ready version, and since then the dashboard has made massive improvements. In a single UI, you’re able to perform majority of possible interactions with your Kubernetes clusters without ever leaving your browser. This blog post breaks down new features introduced in the latest release and outlines the roadmap for the future.
**Full-Featured Dashboard**
Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.
Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.
The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.
Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.
Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.
While many new improvements and features have been added in the latest release, we’ll be highlighting several that stand-out. Follow along and read these in-depth posts on what’s new and how we continue to make Kubernetes the best way to manage containers at scale.
@@ -43,7 +43,7 @@ Day 5
|
Bonus
|
\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3)
\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/update-on-kubernetes-for-windows-server-containers/)
Nearly two years ago, when we officially kicked off the Kubernetes project, we wanted to simplify distributed systems management and provide the core technology required to everyone. The community’s response to this effort has blown us away. Today, thousands of customers, partners and developers are running clusters in production using Kubernetes and have joined the cloud native revolution.
@@ -11,7 +11,7 @@ Kubernetes was the first external orchestration platform supported by [Rancher](
### Rancher and Kubernetes 1.2
Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:
Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:
@@ -155,7 +155,7 @@ Then every underlying Kubernetes cluster represented by Rancher environment, sho
- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)
- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3 _
_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3 _
While Kubernetes is one of the best tools for managing containerized applications available today, and has been production-ready for over a year, Kubernetes has been missing a great local development platform.
For the past several months, several of us from the Kubernetes community have been working to fix this in the [Minikube](http://github.com/kubernetes/minikube) repository on GitHub. Our goal is to build an easy-to-use, high-fidelity Kubernetes distribution that can be run locally on Mac, Linux and Windows workstations and laptops with a single command.
Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).
Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3 _
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3 _
As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.
As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.
"We find CoreOS’s rkt a compelling container engine in Kubernetes because of how rkt is composed with the underlying systemd,” said Mark Petrovic, senior MTS and architect at Xoom, a PayPal service. “The rkt runtime assumes only the responsibility it needs to, then delegates to other system services where appropriate. This separation of concerns is important to us.”
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_
_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
## Running The Greek Pet Monster Races
For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.
For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.
It’s fairly straightforward to use containers with basic stateful applications today. Using a persistent volume, you can mount a disk in a pod, and ensure that your data lasts beyond the life of your pod. However, with deployments of distributed stateful applications, things can become more tricky. With Kubernetes 1.3, the new [Pet Set](/docs/user-guide/petset/) component makes everything much easier. To test this new feature out at scale, we decided to host the Greek Pet Monster Races! We raced Centaurs and other Ancient Greek Monsters over hundreds of thousands of races across multiple availability zones.
We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.
We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.
In this blog post we discuss the detailed performance results from Kubernetes 1.3 and what changes we made from version 1.2 to achieve these results. We also describe Kubemark, a performance testing tool that we’ve integrated into our continuous testing framework to detect performance and scalability regressions.
Last year at OSCON, I got to reconnect with a bunch of friends and see what they have been working on. That turned out to be the [Kubernetes 1.0 launch event](https://www.youtube.com/playlist?list=PL69nYSiGNLP0Ljwa9J98xUd6UlM604Y-l). Even that day, it was clear the project was supported by a broad community -- a group that showed an ambitious vision for distributed computing.
Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:
Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:
- [Sam Ghods](https://www.box.com/blog/kubernetes-box-microservices-maximum-velocity/), services architect and co-founder at Box
@@ -14,7 +14,7 @@ Google spent over ten years developing, applying and refining the principles of
- Dynamically scheduled, for increased infrastructure efficiency and decreased operational overhead; and
- Microservices-based. Loosely coupled components significantly increase the overall agility, resilience and maintainability of applications.
These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.
These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.
_Editor's note: today’s guest post is from Mark Balch, VP of Products at Diamanti, who’ll share more about the contributions they’ve made to Kubernetes._
Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.
Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.
You may have [heard me say before](https://www.diamanti.com/blog/the-next-great-application-platform/) that containers are the next great application platform. Diamanti is accelerating container adoption for stateful apps in production - where performance and ease of deployment really matter.
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.
Kubernetes Prow Robot
