Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dry run feature documentation 1.12 #10033

Merged
merged 1 commit into from
Sep 10, 2018

Conversation

jennybuckley
Copy link

@jennybuckley jennybuckley commented Aug 21, 2018

Add documentation for the dry run feature. Will also add documentation about dry-run and webhooks once kubernetes/kubernetes#66936 merges.

/sig api-machinery
/kind feature
/sig docs
/milestone 1.12

Discussed in kubernetes/enhancements#576 (comment)

/cc @zparnold @lavalamp @apelisse

@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. kind/feature Categorizes issue or PR as related to a new feature. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Aug 21, 2018
@k8sio-netlify-preview-bot
Copy link
Collaborator

k8sio-netlify-preview-bot commented Aug 21, 2018

Deploy preview for kubernetes-io-vnext-staging processing.

Built with commit 373af54

https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/5b92fb2a792f8923ed6d0ca1

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. sig/docs Categorizes an issue or PR as relevant to SIG Docs. labels Aug 21, 2018

## Dry Run

In version 1.12, if the DryRun alpha feature is enabled, the modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry-run mode, which allows users to see if the request would have succeeded (admission chain, validation, merge conflicts, ...) and/or what would have happened without having it actually happen. The response body for the request is as close as possible to a non dry-run response.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Possibly clean-up usage of Dry Run, Dry-run, DryRun
  • May want to split up the first sentence.
  • Possibly further explain Dry run mode:
    Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"DryRun" is special because it's the feature flag name, and I used "Dry Run" as the title of the section, but besides that I only used "dry-run" I think. I will switch all the uses to "dry run" so it will be consistent with the title of the section.

In version 1.12, if the DryRun alpha feature is enabled, the modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry-run mode, which allows users to see if the request would have succeeded (admission chain, validation, merge conflicts, ...) and/or what would have happened without having it actually happen. The response body for the request is as close as possible to a non dry-run response.

Dry-run is triggered by setting the `dryRun` parameter. This parameter is an array of strings, working as an array of enums, to allow for future extensibility. Accepted values are:
* All: Every step runs as normal, except for the final storage step. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there two accepted values All or "" (which is the default)? The parameter is an array of strings? Can you explain a bit further.

* UID uniquely identifies the object and is randomly generated (non-deterministic),
* resourceVersion tracks the persisted version of the object.

The values of these fields will likely be set differently in a dry-run and non-dry-run creation, because they are not genereated deterministically. It is important not to rely upon the values of these fields being set correctly by a dry-run request.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: genereated

* UID uniquely identifies the object and is randomly generated (non-deterministic),
* resourceVersion tracks the persisted version of the object.

The values of these fields will likely be set differently in a dry-run and non-dry-run creation, because they are not genereated deterministically. It is important not to rely upon the values of these fields being set correctly by a dry-run request.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Possibly use mode instead of creation?
    ... will likely be set differently in dry-run mode, because ...
  • Are you indicating that the four fields listed above will contain dummy values?

@k8s-ci-robot k8s-ci-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Aug 22, 2018
@kbarnard10 kbarnard10 added this to the 1.12 milestone Aug 22, 2018
@jennybuckley
Copy link
Author

/assign @kwiesmueller
Could you please take a look at this proposed documentation for dry-run and let me know if there is there anything you would add or change?

@k8s-ci-robot
Copy link
Contributor

@jennybuckley: GitHub didn't allow me to assign the following users: kwiesmueller.

Note that only kubernetes members and repo collaborators can be assigned.
For more information please see the contributor guide

In response to this:

/assign @kwiesmueller
Could you please take a look at this proposed documentation for dry-run and let me know if there is there anything you would add or change?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@kwiesmueller
Copy link
Member

Will do @jennybuckley

In version 1.12, if the DryRun alpha feature is enabled, the modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry run mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non dry run response.

Dry run is triggered by setting the `dryRun` parameter. This parameter is an array of strings (working as an array of enums) to allow the possibility for a finer-grained mechanism, where the user can specify which request stages to run, to be introduced later. In 1.12 the only accepted values are:
* `All`: If present, this must be the only element of the array. Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The texts are good though. Should be understandable and clear what it does.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Aug 28, 2018
@jennybuckley
Copy link
Author

There are more comments here: fd21062 which seem to be lost on the PR for some reason

@kwiesmueller
Copy link
Member

Looks good!
I don't know if this works (doubt it), but
/approve

Copy link
Member

@apelisse apelisse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jennybuckley !


## Dry Run

{{< feature-state for_k8s_version="v1.12" state="alpha" >}} In version 1.12, if the DryRun alpha feature is enabled, the modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry run mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non dry run response.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the DryRun alpha feature is enabled,

Should we say where and how to enable it?


{{< feature-state for_k8s_version="v1.12" state="alpha" >}} In version 1.12, if the DryRun alpha feature is enabled, the modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry run mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non dry run response.

Dry run is triggered by setting the `dryRun` parameter. This parameter is an array of strings (working as an array of enums) to allow the possibility for a finer-grained mechanism, where the user can specify which request stages to run, to be introduced later. In 1.12 the only accepted values are:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dry run is triggered by setting the dryRun parameter.

I suspect "parameter" is to vague.

This parameter is an array of strings

Probably not necessary since it's not yet possible to use multiple values, but it might be useful to explain how one would do it. Also, to be honest, since only one or zero value can be specified, I would maybe drop this sentence since it's confusing and not really helpful to users.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Earlier in the same doc it says "parameter" to talk about query parameter but I'll change it to "query parameter", I think you're right that it is too vague.

And I'll remove that sentence

Copy link
Author

@jennybuckley jennybuckley Sep 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think something explaining why it uses the values "All" and "" instead of true/false could be useful though

* UID uniquely identifies the object and is randomly generated (non-deterministic),
* resourceVersion tracks the persisted version of the object.

The values of these fields will likely be different in dry run mode from when the real request is made, because they are not generated deterministically. It is important not to rely upon the values of these fields set by a dry run request.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is important not to rely upon the values of these fields set by a dry run request.

I suspect this is important enough (and actually probably one of the most important thing of the session), that I would put it way earlier in the section. Along the line of:

Some values of an object are randomly generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry run request, since these values will likely be different in dry run mode from when the real request is made. Some of these fields are: ...

### Generated values

Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry run request, since these values will likely be different in dry run mode from when the real request is made. Some of these fields are:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, @jennybuckley.
Small nit: You may want to emphasize the fields as the field name runs into the description. Another way would be to show a partial json/yaml response containing these fields?

you need to:

* Include "DryRun" in the `--enable-admission-plugins` flag when starting
`kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: does this imply that both the kube-apiserver and the http request need the dry run flag enabled?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll add some documentation for this


## Dry run

{{< feature-state for_k8s_version="v1.12" state="alpha" >}} In version 1.12, if the dry run alpha feature is enabled, the modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry run mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non dry run response.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add: "The system guarantees that dry run requests will not be persisted in storage or have any other side effects."


* Include "DryRun" in the `--enable-admission-plugins` flag when starting
`kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
have the same flag setting.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We didn't use a feature gate for this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! It is a feature gate, I copied this from the initializers setup instructions and must have deleted the wrong section, I'll fix this now.

`kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
have the same flag setting.

If this feature is not enabled, all requests with a modifying verb (`POST`, `PUT`, `PATCH`, and `DELETE`) which set the `dryRun` query parameter will be rejected with a 400 Bad Request error.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add: "Kubernetes 1.11 always rejects dry run requests like this, so it is safe for clients to make dry run requests even if the feature is not enabled on the server, as long as the server version is >= 1.11."


Dry run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and in 1.12 the only accepted values are:

* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add: "If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. Admission webhooks can now declare (in their configuration object) that they do not have side effects to prevent this. All built in admission control plugins support dry run."


Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry run request, since these values will likely be different in dry run mode from when the real request is made. Some of these fields are:

* `generateName` can be used to assign a unique random name to the object,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name: if generateName is set, name will have a unique random name.

* `generateName` can be used to assign a unique random name to the object,
* `creationTimestamp`/`deletionTimestamp` records the time of creation/deletion,
* `UID` uniquely identifies the object and is randomly generated (non-deterministic),
* `resourceVersion` tracks the persisted version of the object.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add something like:

  • Any field set by a mutating admission controller.
  • For the Service resource: Ports or IPs that kube-apiserver assigns to v1.Service objects.

@lavalamp
Copy link
Member

lavalamp commented Sep 7, 2018

Consider this a lgtm whenever my comments are looked at, incorporate as much as seems useful.

@jennybuckley
Copy link
Author

@lavalamp Thanks for the review! I incorporated the comments, PTAL

@lavalamp
Copy link
Member

lavalamp commented Sep 7, 2018

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Sep 7, 2018
@jennybuckley
Copy link
Author

@zparnold I think this needs approval from someone in the kubernetes/website OWNERS file, could you please take a look? I think you asked for this PR in kubernetes/enhancements#576 (comment)

@zparnold
Copy link
Member

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kwiesmueller, zparnold

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 10, 2018
@k8s-ci-robot k8s-ci-robot merged commit d494a44 into kubernetes:release-1.12 Sep 10, 2018
detiber pushed a commit to detiber/kubernetes-website that referenced this pull request Sep 19, 2018
k8s-ci-robot pushed a commit that referenced this pull request Sep 27, 2018
* Update docs for fields allowed at root of CRD schema (#9973)

* add plugin docs and examples (#10053)

* docs update to promote TaintNodesByCondition to beta (#9626)

* HPA Specificity Improvements (#8757)

Updated the HPA docs to reference the `autoscaling/v2beta2` API version,
and added documentation about the new fields.

* adjust docs for pod ready++ (#10049)

* Remove --cadvisor-port - has been deprecated since v1.10 (#10023)

Change-Id: Id2a685473a243aef492a98ff450759f39e362557

* Add Documentation for Snapshot Feature (#9948)

* Add documentation for snapshot feature

* Update volume-snapshots.md

* Add dry-run to api-concepts (#10033)

* kubeadm-init: Update the offline support section (#10062)

The update includes the following things (in mind with Kubernetes 1.12):

- Remove the 1.8 image versions
- Add the 1.10 image versions that were missing until now
- Include a comment for the missing arch suffixes in 1.12

Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>

* Say bye to `DynamicProvisioningScheduling` (#10157)

The mentioned feature gate is now collapsed into `VolumeScheduling`.

xref: kubernetes/kubernetes#67432

* Update ResourceQuota per PriorityClass state for 1.12 (#10229)

* TokenRequest and TokenRequestProjection now beta (#10161)

xref: kubernetes/kubernetes#67349

* Change feature state for kms provider to beta. (#10230)

KMS Provider will be graduating to beta in v1.12, reflecting this change on the website.

* coredns default (#10200)

* Promote ShareProcessNamespace to beta in docs (#9996)

* Add CoreDNS details to DNS Debug docs (#10201)

* add coredns details

* address nits, add query logging section

* Update docs with topology aware dynamic provisioning (#9939)

* Document topology aware volume binding feature

* update for readability

* Update storage-classes.md

* comma splice

* don't abbreviate

* HPA Algorithm Information Improvements (#9780)

* Update HPA docs with more algorithm details

The HPA docs pointed to an out-of-date document for information on the
algorithm details, which users were finding confusing.  This sticks a
section on the algorithm in the HPA docs instead, documenting both
general behavior and corner cases.

* Add glossary info, HPA docs on quantities

People often ask about the quantity notation when working with the
metrics APIs, so this adds a glossary entry on quantities (since they're
used elsewhere in the system), and a short explantation in the HPA walkthough.

* Information about HPA readiness and stabilization

This adds information about the new changes to HPA readiness and
stabilization from kubernetes/enhancements#591, and other minor changes that
landed in Kubernetes 1.12.

* Update horizontal-pod-autoscale.md

* Audit 1.12 doc (#9953)

* audit 1.12 document

* remove legacy audit feature

kubernetes/kubernetes#65862

* update feature gate doc

* MountPropagation is now GA (#10090)

* RuntimeClass documentation (#10102)

* RuntimeClass documentation

* Update runtime-class.md

* Add documentation for Scheduler performance tuning (#10048)

* Add documentation for Scheduler performance tuning

* Update scheduler-perf-tuning.md

* TTL controller for cleaning up finished resources (#10064)

* TTL controller for cleaning up finished resources

* Address comments

* Update ttlafterfinished.md

* Bump quota configuration api version (#10217)

* Incremental update from master (#10278)

* fix invalid href of cloud controller manager (#10240)

* fix invalid yaml format (#10238)

* update storage-limits doc with Azure disk part (#10224)

update storage-limits doc with Azure disk part

fix comments

* Update kubelet-config-file.md (#10222)

Update link to KubeletConfiguration struct.

* fix a trivial misspelling (#10244)

* Fix cassandra-statefulset.yaml indent level (#10243)

* Mention minimum etcd versions (#10208)

Source: https://groups.google.com/d/msg/kubernetes-dev/jMPA4JzKiY4/HIx2ugvLBAAJ

* fix 404 error (#10250)

* Small verb tweak (#10190)

Present participle, ftw.

* Add AnchorJS logic for header links (#10155)

* Add AnchorJS JavaScript

* Remove existing inpage_heading logic

* Remove underline from anchor tags

* Use single icon and add touch visibility

* Use paragraph link icon for AnchorJS

* Update Sass to use code formatting in docsContent headers

* Update header size coverage to H3-H6

* fix broken link in kubefed.md (#10254)

* Update the version numbers for the X-Remote-Extra- and Impersonate-Extra- key fixes (#9827)

The fix was cherry picked into 1.11.3, 1.10.7, and 1.9.11:

kubernetes/kubernetes#67162
kubernetes/kubernetes#67163
kubernetes/kubernetes#67164

* fix typo (#10168)

* fix typo

* addressing comments.

* Update setup-ha-etcd-with-kubeadm.md

* fix typos (#10252)

* fix description of contribute guide (#10253)

* describe truncate feature about advanced audit (#10236)

* describe truncate feature about advanced audit

* Update audit.md

* docs update to promote ScheduleDaemonSetPods to beta (#9923)

* Dynamic volume limit updates for 1.12 (#10211)

* add a placeholder commit

* Update docs for csi volume limits

* Update storage-limits.md

* Add "MayRunAs" value among other GroupStrategies (#9888)

* Add CoreDNS details to the customize DNS doc (#10228)

* Add CoreDNS details to the customize DNS doc

Rewrite the document to include more details about CoreDNS, since it's now the default from v1.12

* Address comments

* Improve doc wording

* Fix link

* Update dns-custom-nameservers.md

* Update dns-custom-nameservers.md

* Fix secrets docs in 1.12 branch (#10056)

* Fix secrets docs

* Update secret.md

* Revert CoreDNS Docs (#10319)

* Revert "Add CoreDNS details to DNS Debug docs (#10201)"

This reverts commit 462817a.

* Revert "Add CoreDNS details to the customize DNS doc (#10228)"

This reverts commit e7319ee.

* Revert "coredns default (#10200)"

This reverts commit 698e93b.

* Add CRI installation instructions page

Added cri-installation page with CRI installation instructions
Referenced it from kubeadm-init and install-kubeadm pages.

* kubeadm: update API types documentation for 1.12 (#10283)

v1alpha2 -> v1alpha3
MasterConfiguration -> [new-api-types]

* TokenRequest feature documentation (#10295)

* AdvancedAuditing is now GA (#10156)

xref: kubernetes/kubernetes#65862

`AdvancedAuditing` feature is GA in 1.12. This PR adjusts the related
docs.

* update runtime-class.md (#10332)

* update runtime-class.md

* Update runtime-class.md

* Document cross-authorizer permissions for creating RBAC roles (#10015)

* Document cross-authorizer permissions for creating RBAC roles

* Update rbac.md

* kubeadm: update authored content for 1.12 (reference docs and cluster creation) (#10348)

* kubeadm: update authored content in reference docs for 1.12

* kubeadm: add time frame in create-cluster-kubeadm for 1.12

* add AllowedProcMountTypes and ProcMountType to docs (#9911)

Signed-off-by: Jess Frazelle <acidburn@microsoft.com>

* kubeadm: add new command line reference (#10306)

Add:
- placeholder files
- include place holder files
- include "renew" sub command
- add missing tabs for "alpha phase kubelet"

* Documenting SCTP support in Kubernetes (#10279)

* Documenting SCTP support in Kubernetes Service, Endpoint, NetworkPolicy and Pod

* Updates based on comments on the PR

* kubectl expose update with SCTP support

* Updated according to comments in the PR

* Revert "kubectl expose update with SCTP support"

This reverts commit 0d5a1e6.

* TLS Bootstrap and Server Cert Rotation feature documentation (#10232)

* TokenRequest feature documentation

* line wrapping to make review not insane

* update content for GA without major refactor

* Update kubelet-tls-bootstrapping.md

* Add clarifications for volume snapshots (#10296)

* Update kubadm ha installation for 1.12 (#10264)

* Update kubadm ha installation for 1.12

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* update stable version

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* Update stacked control plane for v1.12 (#2)

* use v1alpha3

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* more v1alpha3 (#4)

* updates

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* Document how to run in-tree cloud providers with kubeadm (#10357)

Change-Id: Iab6b996a830503d74a6eb0c507c5f8ca7a39235b

* kubeadm reference doc for release 1.12 (#10359)

* Revert "Revert "Add CoreDNS details to DNS Debug docs (#10201)""

This reverts commit bb30f4d.

* Revert "Revert "Add CoreDNS details to the customize DNS doc (#10228)""

This reverts commit bc23d45.

* Revert "Revert "coredns default (#10200)""

This reverts commit 7f4350d.

* add missing instruction for ha guide (#10374)

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* kubeadm - Ha upgrade updates (#10340)

* Update HA upgrade docs

* Adds external etcd HA upgrade guide

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* copyedit

* more edits

* add runasgroup in psp (#10076)

* update KubeletPluginsWatcher feature gate (#10205)

* generated 1.12 docs

* Building Multi-arch images with Manifests (#10379)

In 1.12, a variety of images used in a typical kubernetes installation
have started to using manifests to better support environments with arm
or ppc64le architectures. For example all images used with kubeadm by
default have manifests, another would be all the tests in the
conformance test suite. Here we capture the best practices for everyone
to start using manifests in their own workflows.

Change-Id: I5ba4c5fe55ffc9486a8251760f3352be4f2e1494

* Upgrade docs for v1.12 (#10344)

* generated assets and docs

* remove 1.7

* update 1.12

* update plugin documentation under docs>tasks>extend-kubectl (#10259)

* update plugin documentation under docs>tasks>extend-kubectl

* Update kubectl-plugins.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/docs Categorizes an issue or PR as relevant to SIG Docs. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants