Question: <del> docs/.generated_docs docs/admin/cloud-controller-manager.md docs/admin/kube-apiserver.md docs/admin/kube-controller-manager.md docs/admin/kube-proxy.md docs/admin/kube-scheduler.md docs/admin/kubeadm.md docs/admin/kubeadm_alpha.md docs/admin/kubeadm_alpha_certs.md docs/admin/kubeadm_alpha_certs_renew.md docs/admin/kubeadm_alpha_certs_renew_all.md docs/admin/kubeadm_alpha_certs_renew_apiserver-etcd-client.md docs/admin/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md docs/admin/kubeadm_alpha_certs_renew_apiserver.md docs/admin/kubeadm_alpha_certs_renew_etcd-healthcheck-client.md docs/admin/kubeadm_alpha_certs_renew_etcd-peer.md docs/admin/kubeadm_alpha_certs_renew_etcd-server.md docs/admin/kubeadm_alpha_certs_renew_front-proxy-client.md docs/admin/kubeadm_alpha_kubeconfig.md docs/admin/kubeadm_alpha_kubeconfig_user.md docs/admin/kubeadm_alpha_kubelet.md docs/admin/kubeadm_alpha_kubelet_config.md docs/admin/kubeadm_alpha_kubelet_config_download.md docs/admin/kubeadm_alpha_kubelet_config_enable-dynamic.md docs/admin/kubeadm_alpha_preflight.md docs/admin/kubeadm_alpha_preflight_node.md docs/admin/kubeadm_alpha_selfhosting.md docs/admin/kubeadm_alpha_selfhosting_pivot.md docs/admin/kubeadm_completion.md docs/admin/kubeadm_config.md docs/admin/kubeadm_config_images.md docs/admin/kubeadm_config_images_list.md docs/admin/kubeadm_config_images_pull.md docs/admin/kubeadm_config_migrate.md docs/admin/kubeadm_config_print.md docs/admin/kubeadm_config_print_init-defaults.md docs/admin/kubeadm_config_print_join-defaults.md docs/admin/kubeadm_config_upload.md docs/admin/kubeadm_config_upload_from-file.md docs/admin/kubeadm_config_upload_from-flags.md docs/admin/kubeadm_config_view.md docs/admin/kubeadm_init.md docs/admin/kubeadm_init_phase.md docs/admin/kubeadm_init_phase_addon.md docs/admin/kubeadm_init_phase_addon_all.md docs/admin/kubeadm_init_phase_addon_coredns.md docs/admin/kubeadm_init_phase_addon_kube-proxy.md docs/admin/kubeadm_init_phase_bootstrap-token.md docs/admin/kubeadm_init_phase_certs.md docs/admin/kubeadm_init_phase_certs_all.md docs/admin/kubeadm_init_phase_certs_apiserver-etcd-client.md docs/admin/kubeadm_init_phase_certs_apiserver-kubelet-client.md docs/admin/kubeadm_init_phase_certs_apiserver.md docs/admin/kubeadm_init_phase_certs_ca.md docs/admin/kubeadm_init_phase_certs_etcd-ca.md docs/admin/kubeadm_init_phase_certs_etcd-healthcheck-client.md docs/admin/kubeadm_init_phase_certs_etcd-peer.md docs/admin/kubeadm_init_phase_certs_etcd-server.md docs/admin/kubeadm_init_phase_certs_front-proxy-ca.md docs/admin/kubeadm_init_phase_certs_front-proxy-client.md docs/admin/kubeadm_init_phase_certs_sa.md docs/admin/kubeadm_init_phase_control-plane.md docs/admin/kubeadm_init_phase_control-plane_all.md docs/admin/kubeadm_init_phase_control-plane_apiserver.md docs/admin/kubeadm_init_phase_control-plane_controller-manager.md docs/admin/kubeadm_init_phase_control-plane_scheduler.md docs/admin/kubeadm_init_phase_etcd.md docs/admin/kubeadm_init_phase_etcd_local.md docs/admin/kubeadm_init_phase_kubeconfig.md docs/admin/kubeadm_init_phase_kubeconfig_admin.md docs/admin/kubeadm_init_phase_kubeconfig_all.md docs/admin/kubeadm_init_phase_kubeconfig_controller-manager.md docs/admin/kubeadm_init_phase_kubeconfig_kubelet.md docs/admin/kubeadm_init_phase_kubeconfig_scheduler.md docs/admin/kubeadm_init_phase_kubelet-start.md docs/admin/kubeadm_init_phase_mark-control-plane.md docs/admin/kubeadm_init_phase_preflight.md docs/admin/kubeadm_init_phase_upload-config.md docs/admin/kubeadm_init_phase_upload-config_all.md docs/admin/kubeadm_init_phase_upload-config_kubeadm.md docs/admin/kubeadm_init_phase_upload-config_kubelet.md docs/admin/kubeadm_join.md docs/admin/kubeadm_reset.md docs/admin/kubeadm_token.md docs/admin/kubeadm_token_create.md docs/admin/kubeadm_token_delete.md docs/admin/kubeadm_token_generate.md docs/admin/kubeadm_token_list.md docs/admin/kubeadm_upgrade.md docs/admin/kubeadm_upgrade_apply.md docs/admin/kubeadm_upgrade_diff.md docs/admin/kubeadm_upgrade_node.md docs/admin/kubeadm_upgrade_node_config.md docs/admin/kubeadm_upgrade_node_experimental-control-plane.md docs/admin/kubeadm_upgrade_plan.md docs/admin/kubeadm_version.md docs/admin/kubelet.md docs/man/man1/cloud-controller-manager.1 docs/man/man1/kube-apiserver.1 docs/man/man1/kube-controller-manager.1 docs/man/man1/kube-proxy.1 docs/man/man1/kube-scheduler.1 docs/man/man1/kubeadm-alpha-certs-renew-all.1 docs/man/man1/kubeadm-alpha-certs-renew-apiserver-etcd-client.1 docs/man/man1/kubeadm-alpha-certs-renew-apiserver-kubelet-client.1 docs/man/man1/kubeadm-alpha-certs-renew-apiserver.1 docs/man/man1/kubeadm-alpha-certs-renew-etcd-healthcheck-client.1 docs/man/man1/kubeadm-alpha-certs-renew-etcd-peer.1 docs/man/man1/kubeadm-alpha-certs-renew-etcd-server.1 docs/man/man1/kubeadm-alpha-certs-renew-front-proxy-client.1 docs/man/man1/kubeadm-alpha-certs-renew.1 docs/man/man1/kubeadm-alpha-certs.1 docs/man/man1/kubeadm-alpha-kubeconfig-user.1 docs/man/man1/kubeadm-alpha-kubeconfig.1 docs/man/man1/kubeadm-alpha-kubelet-config-download.1 docs/man/man1/kubeadm-alpha-kubelet-config-enable-dynamic.1 docs/man/man1/kubeadm-alpha-kubelet-config.1 docs/man/man1/kubeadm-alpha-kubelet.1 docs/man/man1/kubeadm-alpha-phase.1 docs/man/man1/kubeadm-alpha-preflight-node.1 docs/man/man1/kubeadm-alpha-preflight.1 docs/man/man1/kubeadm-alpha-selfhosting-pivot.1 docs/man/man1/kubeadm-alpha-selfhosting.1 docs/man/man1/kubeadm-alpha.1 docs/man/man1/kubeadm-completion.1 docs/man/man1/kubeadm-config-images-list.1 docs/man/man1/kubeadm-config-images-pull.1 docs/man/man1/kubeadm-config-images.1 docs/man/man1/kubeadm-config-migrate.1 docs/man/man1/kubeadm-config-print-init-defaults.1 docs/man/man1/kubeadm-config-print-join-defaults.1 docs/man/man1/kubeadm-config-print.1 docs/man/man1/kubeadm-config-upload-from-file.1 docs/man/man1/kubeadm-config-upload-from-flags.1 docs/man/man1/kubeadm-config-upload.1 docs/man/man1/kubeadm-config-view.1 docs/man/man1/kubeadm-config.1 docs/man/man1/kubeadm-init-phase-addon-all.1 docs/man/man1/kubeadm-init-phase-addon-coredns.1 docs/man/man1/kubeadm-init-phase-addon-kube-proxy.1 docs/man/man1/kubeadm-init-phase-addon.1 docs/man/man1/kubeadm-init-phase-bootstrap-token.1 docs/man/man1/kubeadm-init-phase-certs-all.1 docs/man/man1/kubeadm-init-phase-certs-apiserver-etcd-client.1 docs/man/man1/kubeadm-init-phase-certs-apiserver-kubelet-client.1 docs/man/man1/kubeadm-init-phase-certs-apiserver.1 docs/man/man1/kubeadm-init-phase-certs-ca.1 docs/man/man1/kubeadm-init-phase-certs-etcd-ca.1 docs/man/man1/kubeadm-init-phase-certs-etcd-healthcheck-client.1 docs/man/man1/kubeadm-init-phase-certs-etcd-peer.1 docs/man/man1/kubeadm-init-phase-certs-etcd-server.1 docs/man/man1/kubeadm-init-phase-certs-front-proxy-ca.1 docs/man/man1/kubeadm-init-phase-certs-front-proxy-client.1 docs/man/man1/kubeadm-init-phase-certs-sa.1 docs/man/man1/kubeadm-init-phase-certs.1 docs/man/man1/kubeadm-init-phase-control-plane-all.1 docs/man/man1/kubeadm-init-phase-control-plane-apiserver.1 docs/man/man1/kubeadm-init-phase-control-plane-controller-manager.1 docs/man/man1/kubeadm-init-phase-control-plane-scheduler.1 docs/man/man1/kubeadm-init-phase-control-plane.1 docs/man/man1/kubeadm-init-phase-etcd-local.1 docs/man/man1/kubeadm-init-phase-etcd.1 docs/man/man1/kubeadm-init-phase-kubeconfig-admin.1 docs/man/man1/kubeadm-init-phase-kubeconfig-all.1 docs/man/man1/kubeadm-init-phase-kubeconfig-controller-manager.1 docs/man/man1/kubeadm-init-phase-kubeconfig-kubelet.1 docs/man/man1/kubeadm-init-phase-kubeconfig-scheduler.1 docs/man/man1/kubeadm-init-phase-kubeconfig.1 docs/man/man1/kubeadm-init-phase-kubelet-start.1 docs/man/man1/kubeadm-init-phase-mark-control-plane.1 docs/man/man1/kubeadm-init-phase-preflight.1 docs/man/man1/kubeadm-init-phase-upload-config-all.1 docs/man/man1/kubeadm-init-phase-upload-config-kubeadm.1 docs/man/man1/kubeadm-init-phase-upload-config-kubelet.1 docs/man/man1/kubeadm-init-phase-upload-config.1 docs/man/man1/kubeadm-init-phase.1 docs/man/man1/kubeadm-init.1 docs/man/man1/kubeadm-join.1 docs/man/man1/kubeadm-reset.1 docs/man/man1/kubeadm-token-create.1 docs/man/man1/kubeadm-token-delete.1 docs/man/man1/kubeadm-token-generate.1 docs/man/man1/kubeadm-token-list.1 docs/man/man1/kubeadm-token.1 docs/man/man1/kubeadm-upgrade-apply.1 docs/man/man1/kubeadm-upgrade-diff.1 docs/man/man1/kubeadm-upgrade-node-config.1 docs/man/man1/kubeadm-upgrade-node-experimental-control-plane.1 docs/man/man1/kubeadm-upgrade-node.1 docs/man/man1/kubeadm-upgrade-plan.1 docs/man/man1/kubeadm-upgrade.1 docs/man/man1/kubeadm-version.1 docs/man/man1/kubeadm.1 docs/man/man1/kubectl-alpha.1 docs/man/man1/kubectl-annotate.1 docs/man/man1/kubectl-api-resources.1 docs/man/man1/kubectl-api-versions.1 docs/man/man1/kubectl-apply-edit-last-applied.1 docs/man/man1/kubectl-apply-set-last-applied.1 docs/man/man1/kubectl-apply-view-last-applied.1 docs/man/man1/kubectl-apply.1 docs/man/man1/kubectl-attach.1 docs/man/man1/kubectl-auth-can-i.1 docs/man/man1/kubectl-auth-reconcile.1 docs/man/man1/kubectl-auth.1 docs/man/man1/kubectl-autoscale.1 docs/man/man1/kubectl-certificate-approve.1 docs/man/man1/kubectl-certificate-deny.1 docs/man/man1/kubectl-certificate.1 docs/man/man1/kubectl-cluster-info-dump.1 docs/man/man1/kubectl-cluster-info.1 docs/man/man1/kubectl-completion.1 docs/man/man1/kubectl-config-current-context.1 docs/man/man1/kubectl-config-delete-cluster.1 docs/man/man1/kubectl-config-delete-context.1 docs/man/man1/kubectl-config-get-clusters.1 docs/man/man1/kubectl-config-get-contexts.1 docs/man/man1/kubectl-config-rename-context.1 docs/man/man1/kubectl-config-set-cluster.1 docs/man/man1/kubectl-config-set-context.1 docs/man/man1/kubectl-config-set-credentials.1 docs/man/man1/kubectl-config-set.1 docs/man/man1/kubectl-config-unset.1 docs/man/man1/kubectl-config-use-context.1 docs/man/man1/kubectl-config-view.1 docs/man/man1/kubectl-config.1 docs/man/man1/kubectl-convert.1 docs/man/man1/kubectl-cordon.1 docs/man/man1/kubectl-cp.1 docs/man/man1/kubectl-create-clusterrole.1 docs/man/man1/kubectl-create-clusterrolebinding.1 docs/man/man1/kubectl-create-configmap.1 docs/man/man1/kubectl-create-deployment.1 docs/man/man1/kubectl-create-job.1 docs/man/man1/kubectl-create-namespace.1 docs/man/man1/kubectl-create-poddisruptionbudget.1 docs/man/man1/kubectl-create-priorityclass.1 docs/man/man1/kubectl-create-quota.1 docs/man/man1/kubectl-create-role.1 docs/man/man1/kubectl-create-rolebinding.1 docs/man/man1/kubectl-create-secret-docker-registry.1 docs/man/man1/kubectl-create-secret-generic.1 docs/man/man1/kubectl-create-secret-tls.1 docs/man/man1/kubectl-create-secret.1 docs/man/man1/kubectl-create-service-clusterip.1 docs/man/man1/kubectl-create-service-externalname.1 docs/man/man1/kubectl-create-service-loadbalancer.1 docs/man/man1/kubectl-create-service-nodeport.1 docs/man/man1/kubectl-create-service.1 docs/man/man1/kubectl-create-serviceaccount.1 docs/man/man1/kubectl-create.1 docs/man/man1/kubectl-delete.1 docs/man/man1/kubectl-describe.1 docs/man/man1/kubectl-diff.1 docs/man/man1/kubectl-drain.1 docs/man/man1/kubectl-edit.1 docs/man/man1/kubectl-exec.1 docs/man/man1/kubectl-explain.1 docs/man/man1/kubectl-expose.1 docs/man/man1/kubectl-get.1 docs/man/man1/kubectl-label.1 docs/man/man1/kubectl-logs.1 docs/man/man1/kubectl-options.1 docs/man/man1/kubectl-patch.1 docs/man/man1/kubectl-plugin-list.1 docs/man/man1/kubectl-plugin.1 docs/man/man1/kubectl-port-forward.1 docs/man/man1/kubectl-proxy.1 docs/man/man1/kubectl-replace.1 docs/man/man1/kubectl-rolling-update.1 docs/man/man1/kubectl-rollout-history.1 docs/man/man1/kubectl-rollout-pause.1 docs/man/man1/kubectl-rollout-resume.1 docs/man/man1/kubectl-rollout-status.1 docs/man/man1/kubectl-rollout-undo.1 docs/man/man1/kubectl-rollout.1 docs/man/man1/kubectl-run.1 docs/man/man1/kubectl-scale.1 docs/man/man1/kubectl-set-env.1 docs/man/man1/kubectl-set-image.1 docs/man/man1/kubectl-set-resources.1 docs/man/man1/kubectl-set-selector.1 docs/man/man1/kubectl-set-serviceaccount.1 docs/man/man1/kubectl-set-subject.1 docs/man/man1/kubectl-set.1 docs/man/man1/kubectl-taint.1 docs/man/man1/kubectl-top-node.1 docs/man/man1/kubectl-top-pod.1 docs/man/man1/kubectl-top.1 docs/man/man1/kubectl-uncordon.1 docs/man/man1/kubectl-version.1 docs/man/man1/kubectl-wait.1 docs/man/man1/kubectl.1 docs/man/man1/kubelet.1 docs/user-guide/kubectl/kubectl.md docs/user-guide/kubectl/kubectl_annotate.md docs/user-guide/kubectl/kubectl_api-resources.md docs/user-guide/kubectl/kubectl_api-versions.md docs/user-guide/kubectl/kubectl_apply.md docs/user-guide/kubectl/kubectl_apply_edit-last-applied.md docs/user-guide/kubectl/kubectl_apply_set-last-applied.md docs/user-guide/kubectl/kubectl_apply_view-last-applied.md docs/user-guide/kubectl/kubectl_attach.md docs/user-guide/kubectl/kubectl_auth.md docs/user-guide/kubectl/kubectl_auth_can-i.md docs/user-guide/kubectl/kubectl_auth_reconcile.md docs/user-guide/kubectl/kubectl_autoscale.md docs/user-guide/kubectl/kubectl_certificate.md docs/user-guide/kubectl/kubectl_certificate_approve.md docs/user-guide/kubectl/kubectl_certificate_deny.md docs/user-guide/kubectl/kubectl_cluster-info.md docs/user-guide/kubectl/kubectl_cluster-info_dump.md docs/user-guide/kubectl/kubectl_completion.md docs/user-guide/kubectl/kubectl_config.md docs/user-guide/kubectl/kubectl_config_current-context.md docs/user-guide/kubectl/kubectl_config_delete-cluster.md docs/user-guide/kubectl/kubectl_config_delete-context.md docs/user-guide/kubectl/kubectl_config_get-clusters.md docs/user-guide/kubectl/kubectl_config_get-contexts.md docs/user-guide/kubectl/kubectl_config_rename-context.md docs/user-guide/kubectl/kubectl_config_set-cluster.md docs/user-guide/kubectl/kubectl_config_set-context.md docs/user-guide/kubectl/kubectl_config_set-credentials.md docs/user-guide/kubectl/kubectl_config_set.md docs/user-guide/kubectl/kubectl_config_unset.md docs/user-guide/kubectl/kubectl_config_use-context.md docs/user-guide/kubectl/kubectl_config_view.md docs/user-guide/kubectl/kubectl_convert.md docs/user-guide/kubectl/kubectl_cordon.md docs/user-guide/kubectl/kubectl_cp.md docs/user-guide/kubectl/kubectl_create.md docs/user-guide/kubectl/kubectl_create_clusterrole.md docs/user-guide/kubectl/kubectl_create_clusterrolebinding.md docs/user-guide/kubectl/kubectl_create_configmap.md docs/user-guide/kubectl/kubectl_create_deployment.md docs/user-guide/kubectl/kubectl_create_job.md docs/user-guide/kubectl/kubectl_create_namespace.md docs/user-guide/kubectl/kubectl_create_poddisruptionbudget.md docs/user-guide/kubectl/kubectl_create_priorityclass.md docs/user-guide/kubectl/kubectl_create_quota.md docs/user-guide/kubectl/kubectl_create_role.md docs/user-guide/kubectl/kubectl_create_rolebinding.md docs/user-guide/kubectl/kubectl_create_secret.md docs/user-guide/kubectl/kubectl_create_secret_docker-registry.md docs/user-guide/kubectl/kubectl_create_secret_generic.md docs/user-guide/kubectl/kubectl_create_secret_tls.md docs/user-guide/kubectl/kubectl_create_service.md docs/user-guide/kubectl/kubectl_create_service_clusterip.md docs/user-guide/kubectl/kubectl_create_service_externalname.md docs/user-guide/kubectl/kubectl_create_service_loadbalancer.md docs/user-guide/kubectl/kubectl_create_service_nodeport.md docs/user-guide/kubectl/kubectl_create_serviceaccount.md docs/user-guide/kubectl/kubectl_delete.md docs/user-guide/kubectl/kubectl_describe.md docs/user-guide/kubectl/kubectl_diff.md docs/user-guide/kubectl/kubectl_drain.md docs/user-guide/kubectl/kubectl_edit.md docs/user-guide/kubectl/kubectl_exec.md docs/user-guide/kubectl/kubectl_explain.md docs/user-guide/kubectl/kubectl_expose.md docs/user-guide/kubectl/kubectl_get.md docs/user-guide/kubectl/kubectl_label.md docs/user-guide/kubectl/kubectl_logs.md docs/user-guide/kubectl/kubectl_options.md docs/user-guide/kubectl/kubectl_patch.md docs/user-guide/kubectl/kubectl_plugin.md docs/user-guide/kubectl/kubectl_plugin_list.md docs/user-guide/kubectl/kubectl_port-forward.md docs/user-guide/kubectl/kubectl_proxy.md docs/user-guide/kubectl/kubectl_replace.md docs/user-guide/kubectl/kubectl_rollout.md docs/user-guide/kubectl/kubectl_rollout_history.md docs/user-guide/kubectl/kubectl_rollout_pause.md docs/user-guide/kubectl/kubectl_rollout_resume.md docs/user-guide/kubectl/kubectl_rollout_status.md docs/user-guide/kubectl/kubectl_rollout_undo.md docs/user-guide/kubectl/kubectl_run.md docs/user-guide/kubectl/kubectl_scale.md docs/user-guide/kubectl/kubectl_set.md docs/user-guide/kubectl/kubectl_set_env.md docs/user-guide/kubectl/kubectl_set_image.md docs/user-guide/kubectl/kubectl_set_resources.md docs/user-guide/kubectl/kubectl_set_selector.md docs/user-guide/kubectl/kubectl_set_serviceaccount.md docs/user-guide/kubectl/kubectl_set_subject.md docs/user-guide/kubectl/kubectl_taint.md docs/user-guide/kubectl/kubectl_top.md docs/user-guide/kubectl/kubectl_top_node.md docs/user-guide/kubectl/kubectl_top_pod.md docs/user-guide/kubectl/kubectl_uncordon.md docs/user-guide/kubectl/kubectl_version.md docs/user-guide/kubectl/kubectl_wait.md docs/yaml/kubectl/kubectl.yaml docs/yaml/kubectl/kubectl_alpha.yaml docs/yaml/kubectl/kubectl_annotate.yaml docs/yaml/kubectl/kubectl_api-resources.yaml docs/yaml/kubectl/kubectl_api-versions.yaml docs/yaml/kubectl/kubectl_apply.yaml docs/yaml/kubectl/kubectl_attach.yaml docs/yaml/kubectl/kubectl_auth.yaml docs/yaml/kubectl/kubectl_autoscale.yaml docs/yaml/kubectl/kubectl_certificate.yaml docs/yaml/kubectl/kubectl_cluster-info.yaml docs/yaml/kubectl/kubectl_completion.yaml docs/yaml/kubectl/kubectl_config.yaml docs/yaml/kubectl/kubectl_convert.yaml docs/yaml/kubectl/kubectl_cordon.yaml docs/yaml/kubectl/kubectl_cp.yaml docs/yaml/kubectl/kubectl_create.yaml docs/yaml/kubectl/kubectl_delete.yaml docs/yaml/kubectl/kubectl_describe.yaml docs/yaml/kubectl/kubectl_diff.yaml docs/yaml/kubectl/kubectl_drain.yaml docs/yaml/kubectl/kubectl_edit.yaml docs/yaml/kubectl/kubectl_exec.yaml docs/yaml/kubectl/kubectl_explain.yaml docs/yaml/kubectl/kubectl_expose.yaml docs/yaml/kubectl/kubectl_get.yaml docs/yaml/kubectl/kubectl_label.yaml docs/yaml/kubectl/kubectl_logs.yaml docs/yaml/kubectl/kubectl_options.yaml docs/yaml/kubectl/kubectl_patch.yaml docs/yaml/kubectl/kubectl_plugin.yaml docs/yaml/kubectl/kubectl_port-forward.yaml docs/yaml/kubectl/kubectl_proxy.yaml docs/yaml/kubectl/kubectl_replace.yaml docs/yaml/kubectl/kubectl_rolling-update.yaml docs/yaml/kubectl/kubectl_rollout.yaml docs/yaml/kubectl/kubectl_run.yaml docs/yaml/kubectl/kubectl_scale.yaml docs/yaml/kubectl/kubectl_set.yaml docs/yaml/kubectl/kubectl_taint.yaml docs/yaml/kubectl/kubectl_top.yaml docs/yaml/kubectl/kubectl_uncordon.yaml docs/yaml/kubectl/kubectl_version.yaml docs/yaml/kubectl/kubectl_wait.yaml </del>

Instead, have a presubmit test that verifies that the docs can be generated. This will reduce the number of conflicts & rebases, therefore increase speed through the queue. Confirmed with that nothing depends on these docs at the moment. fyi, some manual process might have to change once this is in.
Yes, we want to generate the docs into , anyway. cc
Excellent. One closer step to YAML generation, I hope. :)
was interested in working on this.
Want to get started on this?
is this still a goal of ours?
I've seen a thread this week-end about that. I think docs have moved but we still need to generate them there.
can this issue be closed then?
related to ?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen There's still cruft in the docs directory.
/remove-help I don't think this meets . Please add back via if I'm incorrect
/sig docs /sig release /remove-area test-infra /area build-release /area kubeadm /area kubectl All of the following dirs/files have the following content. Do we need them? This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate- to populate this file. docs/admin: .md files for kube components and kubeadm commands man/man1: .1 files for same user-guide/kubectl: .md files for kubectl commands yaml/kubectl: .yaml files for kubectl commands
/help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used.
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command.


Question: <del> docs/.generated_docs docs/admin/cloud-controller-manager.md docs/admin/kube-apiserver.md docs/admin/kube-controller-manager.md docs/admin/kube-proxy.md docs/admin/kube-scheduler.md docs/admin/kubeadm.md docs/admin/kubeadm_alpha.md docs/admin/kubeadm_alpha_certs.md docs/admin/kubeadm_alpha_certs_renew.md docs/admin/kubeadm_alpha_certs_renew_all.md docs/admin/kubeadm_alpha_certs_renew_apiserver-etcd-client.md docs/admin/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md docs/admin/kubeadm_alpha_certs_renew_apiserver.md docs/admin/kubeadm_alpha_certs_renew_etcd-healthcheck-client.md docs/admin/kubeadm_alpha_certs_renew_etcd-peer.md docs/admin/kubeadm_alpha_certs_renew_etcd-server.md docs/admin/kubeadm_alpha_certs_renew_front-proxy-client.md docs/admin/kubeadm_alpha_kubeconfig.md docs/admin/kubeadm_alpha_kubeconfig_user.md docs/admin/kubeadm_alpha_kubelet.md docs/admin/kubeadm_alpha_kubelet_config.md docs/admin/kubeadm_alpha_kubelet_config_download.md docs/admin/kubeadm_alpha_kubelet_config_enable-dynamic.md docs/admin/kubeadm_alpha_preflight.md docs/admin/kubeadm_alpha_preflight_node.md docs/admin/kubeadm_alpha_selfhosting.md docs/admin/kubeadm_alpha_selfhosting_pivot.md docs/admin/kubeadm_completion.md docs/admin/kubeadm_config.md docs/admin/kubeadm_config_images.md docs/admin/kubeadm_config_images_list.md docs/admin/kubeadm_config_images_pull.md docs/admin/kubeadm_config_migrate.md docs/admin/kubeadm_config_print.md docs/admin/kubeadm_config_print_init-defaults.md docs/admin/kubeadm_config_print_join-defaults.md docs/admin/kubeadm_config_upload.md docs/admin/kubeadm_config_upload_from-file.md docs/admin/kubeadm_config_upload_from-flags.md docs/admin/kubeadm_config_view.md docs/admin/kubeadm_init.md docs/admin/kubeadm_init_phase.md docs/admin/kubeadm_init_phase_addon.md docs/admin/kubeadm_init_phase_addon_all.md docs/admin/kubeadm_init_phase_addon_coredns.md docs/admin/kubeadm_init_phase_addon_kube-proxy.md docs/admin/kubeadm_init_phase_bootstrap-token.md docs/admin/kubeadm_init_phase_certs.md docs/admin/kubeadm_init_phase_certs_all.md docs/admin/kubeadm_init_phase_certs_apiserver-etcd-client.md docs/admin/kubeadm_init_phase_certs_apiserver-kubelet-client.md docs/admin/kubeadm_init_phase_certs_apiserver.md docs/admin/kubeadm_init_phase_certs_ca.md docs/admin/kubeadm_init_phase_certs_etcd-ca.md docs/admin/kubeadm_init_phase_certs_etcd-healthcheck-client.md docs/admin/kubeadm_init_phase_certs_etcd-peer.md docs/admin/kubeadm_init_phase_certs_etcd-server.md docs/admin/kubeadm_init_phase_certs_front-proxy-ca.md docs/admin/kubeadm_init_phase_certs_front-proxy-client.md docs/admin/kubeadm_init_phase_certs_sa.md docs/admin/kubeadm_init_phase_control-plane.md docs/admin/kubeadm_init_phase_control-plane_all.md docs/admin/kubeadm_init_phase_control-plane_apiserver.md docs/admin/kubeadm_init_phase_control-plane_controller-manager.md docs/admin/kubeadm_init_phase_control-plane_scheduler.md docs/admin/kubeadm_init_phase_etcd.md docs/admin/kubeadm_init_phase_etcd_local.md docs/admin/kubeadm_init_phase_kubeconfig.md docs/admin/kubeadm_init_phase_kubeconfig_admin.md docs/admin/kubeadm_init_phase_kubeconfig_all.md docs/admin/kubeadm_init_phase_kubeconfig_controller-manager.md docs/admin/kubeadm_init_phase_kubeconfig_kubelet.md docs/admin/kubeadm_init_phase_kubeconfig_scheduler.md docs/admin/kubeadm_init_phase_kubelet-start.md docs/admin/kubeadm_init_phase_mark-control-plane.md docs/admin/kubeadm_init_phase_preflight.md docs/admin/kubeadm_init_phase_upload-config.md docs/admin/kubeadm_init_phase_upload-config_all.md docs/admin/kubeadm_init_phase_upload-config_kubeadm.md docs/admin/kubeadm_init_phase_upload-config_kubelet.md docs/admin/kubeadm_join.md docs/admin/kubeadm_reset.md docs/admin/kubeadm_token.md docs/admin/kubeadm_token_create.md docs/admin/kubeadm_token_delete.md docs/admin/kubeadm_token_generate.md docs/admin/kubeadm_token_list.md docs/admin/kubeadm_upgrade.md docs/admin/kubeadm_upgrade_apply.md docs/admin/kubeadm_upgrade_diff.md docs/admin/kubeadm_upgrade_node.md docs/admin/kubeadm_upgrade_node_config.md docs/admin/kubeadm_upgrade_node_experimental-control-plane.md docs/admin/kubeadm_upgrade_plan.md docs/admin/kubeadm_version.md docs/admin/kubelet.md docs/man/man1/cloud-controller-manager.1 docs/man/man1/kube-apiserver.1 docs/man/man1/kube-controller-manager.1 docs/man/man1/kube-proxy.1 docs/man/man1/kube-scheduler.1 docs/man/man1/kubeadm-alpha-certs-renew-all.1 docs/man/man1/kubeadm-alpha-certs-renew-apiserver-etcd-client.1 docs/man/man1/kubeadm-alpha-certs-renew-apiserver-kubelet-client.1 docs/man/man1/kubeadm-alpha-certs-renew-apiserver.1 docs/man/man1/kubeadm-alpha-certs-renew-etcd-healthcheck-client.1 docs/man/man1/kubeadm-alpha-certs-renew-etcd-peer.1 docs/man/man1/kubeadm-alpha-certs-renew-etcd-server.1 docs/man/man1/kubeadm-alpha-certs-renew-front-proxy-client.1 docs/man/man1/kubeadm-alpha-certs-renew.1 docs/man/man1/kubeadm-alpha-certs.1 docs/man/man1/kubeadm-alpha-kubeconfig-user.1 docs/man/man1/kubeadm-alpha-kubeconfig.1 docs/man/man1/kubeadm-alpha-kubelet-config-download.1 docs/man/man1/kubeadm-alpha-kubelet-config-enable-dynamic.1 docs/man/man1/kubeadm-alpha-kubelet-config.1 docs/man/man1/kubeadm-alpha-kubelet.1 docs/man/man1/kubeadm-alpha-phase.1 docs/man/man1/kubeadm-alpha-preflight-node.1 docs/man/man1/kubeadm-alpha-preflight.1 docs/man/man1/kubeadm-alpha-selfhosting-pivot.1 docs/man/man1/kubeadm-alpha-selfhosting.1 docs/man/man1/kubeadm-alpha.1 docs/man/man1/kubeadm-completion.1 docs/man/man1/kubeadm-config-images-list.1 docs/man/man1/kubeadm-config-images-pull.1 docs/man/man1/kubeadm-config-images.1 docs/man/man1/kubeadm-config-migrate.1 docs/man/man1/kubeadm-config-print-init-defaults.1 docs/man/man1/kubeadm-config-print-join-defaults.1 docs/man/man1/kubeadm-config-print.1 docs/man/man1/kubeadm-config-upload-from-file.1 docs/man/man1/kubeadm-config-upload-from-flags.1 docs/man/man1/kubeadm-config-upload.1 docs/man/man1/kubeadm-config-view.1 docs/man/man1/kubeadm-config.1 docs/man/man1/kubeadm-init-phase-addon-all.1 docs/man/man1/kubeadm-init-phase-addon-coredns.1 docs/man/man1/kubeadm-init-phase-addon-kube-proxy.1 docs/man/man1/kubeadm-init-phase-addon.1 docs/man/man1/kubeadm-init-phase-bootstrap-token.1 docs/man/man1/kubeadm-init-phase-certs-all.1 docs/man/man1/kubeadm-init-phase-certs-apiserver-etcd-client.1 docs/man/man1/kubeadm-init-phase-certs-apiserver-kubelet-client.1 docs/man/man1/kubeadm-init-phase-certs-apiserver.1 docs/man/man1/kubeadm-init-phase-certs-ca.1 docs/man/man1/kubeadm-init-phase-certs-etcd-ca.1 docs/man/man1/kubeadm-init-phase-certs-etcd-healthcheck-client.1 docs/man/man1/kubeadm-init-phase-certs-etcd-peer.1 docs/man/man1/kubeadm-init-phase-certs-etcd-server.1 docs/man/man1/kubeadm-init-phase-certs-front-proxy-ca.1 docs/man/man1/kubeadm-init-phase-certs-front-proxy-client.1 docs/man/man1/kubeadm-init-phase-certs-sa.1 docs/man/man1/kubeadm-init-phase-certs.1 docs/man/man1/kubeadm-init-phase-control-plane-all.1 docs/man/man1/kubeadm-init-phase-control-plane-apiserver.1 docs/man/man1/kubeadm-init-phase-control-plane-controller-manager.1 docs/man/man1/kubeadm-init-phase-control-plane-scheduler.1 docs/man/man1/kubeadm-init-phase-control-plane.1 docs/man/man1/kubeadm-init-phase-etcd-local.1 docs/man/man1/kubeadm-init-phase-etcd.1 docs/man/man1/kubeadm-init-phase-kubeconfig-admin.1 docs/man/man1/kubeadm-init-phase-kubeconfig-all.1 docs/man/man1/kubeadm-init-phase-kubeconfig-controller-manager.1 docs/man/man1/kubeadm-init-phase-kubeconfig-kubelet.1 docs/man/man1/kubeadm-init-phase-kubeconfig-scheduler.1 docs/man/man1/kubeadm-init-phase-kubeconfig.1 docs/man/man1/kubeadm-init-phase-kubelet-start.1 docs/man/man1/kubeadm-init-phase-mark-control-plane.1 docs/man/man1/kubeadm-init-phase-preflight.1 docs/man/man1/kubeadm-init-phase-upload-config-all.1 docs/man/man1/kubeadm-init-phase-upload-config-kubeadm.1 docs/man/man1/kubeadm-init-phase-upload-config-kubelet.1 docs/man/man1/kubeadm-init-phase-upload-config.1 docs/man/man1/kubeadm-init-phase.1 docs/man/man1/kubeadm-init.1 docs/man/man1/kubeadm-join.1 docs/man/man1/kubeadm-reset.1 docs/man/man1/kubeadm-token-create.1 docs/man/man1/kubeadm-token-delete.1 docs/man/man1/kubeadm-token-generate.1 docs/man/man1/kubeadm-token-list.1 docs/man/man1/kubeadm-token.1 docs/man/man1/kubeadm-upgrade-apply.1 docs/man/man1/kubeadm-upgrade-diff.1 docs/man/man1/kubeadm-upgrade-node-config.1 docs/man/man1/kubeadm-upgrade-node-experimental-control-plane.1 docs/man/man1/kubeadm-upgrade-node.1 docs/man/man1/kubeadm-upgrade-plan.1 docs/man/man1/kubeadm-upgrade.1 docs/man/man1/kubeadm-version.1 docs/man/man1/kubeadm.1 docs/man/man1/kubectl-alpha.1 docs/man/man1/kubectl-annotate.1 docs/man/man1/kubectl-api-resources.1 docs/man/man1/kubectl-api-versions.1 docs/man/man1/kubectl-apply-edit-last-applied.1 docs/man/man1/kubectl-apply-set-last-applied.1 docs/man/man1/kubectl-apply-view-last-applied.1 docs/man/man1/kubectl-apply.1 docs/man/man1/kubectl-attach.1 docs/man/man1/kubectl-auth-can-i.1 docs/man/man1/kubectl-auth-reconcile.1 docs/man/man1/kubectl-auth.1 docs/man/man1/kubectl-autoscale.1 docs/man/man1/kubectl-certificate-approve.1 docs/man/man1/kubectl-certificate-deny.1 docs/man/man1/kubectl-certificate.1 docs/man/man1/kubectl-cluster-info-dump.1 docs/man/man1/kubectl-cluster-info.1 docs/man/man1/kubectl-completion.1 docs/man/man1/kubectl-config-current-context.1 docs/man/man1/kubectl-config-delete-cluster.1 docs/man/man1/kubectl-config-delete-context.1 docs/man/man1/kubectl-config-get-clusters.1 docs/man/man1/kubectl-config-get-contexts.1 docs/man/man1/kubectl-config-rename-context.1 docs/man/man1/kubectl-config-set-cluster.1 docs/man/man1/kubectl-config-set-context.1 docs/man/man1/kubectl-config-set-credentials.1 docs/man/man1/kubectl-config-set.1 docs/man/man1/kubectl-config-unset.1 docs/man/man1/kubectl-config-use-context.1 docs/man/man1/kubectl-config-view.1 docs/man/man1/kubectl-config.1 docs/man/man1/kubectl-convert.1 docs/man/man1/kubectl-cordon.1 docs/man/man1/kubectl-cp.1 docs/man/man1/kubectl-create-clusterrole.1 docs/man/man1/kubectl-create-clusterrolebinding.1 docs/man/man1/kubectl-create-configmap.1 docs/man/man1/kubectl-create-deployment.1 docs/man/man1/kubectl-create-job.1 docs/man/man1/kubectl-create-namespace.1 docs/man/man1/kubectl-create-poddisruptionbudget.1 docs/man/man1/kubectl-create-priorityclass.1 docs/man/man1/kubectl-create-quota.1 docs/man/man1/kubectl-create-role.1 docs/man/man1/kubectl-create-rolebinding.1 docs/man/man1/kubectl-create-secret-docker-registry.1 docs/man/man1/kubectl-create-secret-generic.1 docs/man/man1/kubectl-create-secret-tls.1 docs/man/man1/kubectl-create-secret.1 docs/man/man1/kubectl-create-service-clusterip.1 docs/man/man1/kubectl-create-service-externalname.1 docs/man/man1/kubectl-create-service-loadbalancer.1 docs/man/man1/kubectl-create-service-nodeport.1 docs/man/man1/kubectl-create-service.1 docs/man/man1/kubectl-create-serviceaccount.1 docs/man/man1/kubectl-create.1 docs/man/man1/kubectl-delete.1 docs/man/man1/kubectl-describe.1 docs/man/man1/kubectl-diff.1 docs/man/man1/kubectl-drain.1 docs/man/man1/kubectl-edit.1 docs/man/man1/kubectl-exec.1 docs/man/man1/kubectl-explain.1 docs/man/man1/kubectl-expose.1 docs/man/man1/kubectl-get.1 docs/man/man1/kubectl-label.1 docs/man/man1/kubectl-logs.1 docs/man/man1/kubectl-options.1 docs/man/man1/kubectl-patch.1 docs/man/man1/kubectl-plugin-list.1 docs/man/man1/kubectl-plugin.1 docs/man/man1/kubectl-port-forward.1 docs/man/man1/kubectl-proxy.1 docs/man/man1/kubectl-replace.1 docs/man/man1/kubectl-rolling-update.1 docs/man/man1/kubectl-rollout-history.1 docs/man/man1/kubectl-rollout-pause.1 docs/man/man1/kubectl-rollout-resume.1 docs/man/man1/kubectl-rollout-status.1 docs/man/man1/kubectl-rollout-undo.1 docs/man/man1/kubectl-rollout.1 docs/man/man1/kubectl-run.1 docs/man/man1/kubectl-scale.1 docs/man/man1/kubectl-set-env.1 docs/man/man1/kubectl-set-image.1 docs/man/man1/kubectl-set-resources.1 docs/man/man1/kubectl-set-selector.1 docs/man/man1/kubectl-set-serviceaccount.1 docs/man/man1/kubectl-set-subject.1 docs/man/man1/kubectl-set.1 docs/man/man1/kubectl-taint.1 docs/man/man1/kubectl-top-node.1 docs/man/man1/kubectl-top-pod.1 docs/man/man1/kubectl-top.1 docs/man/man1/kubectl-uncordon.1 docs/man/man1/kubectl-version.1 docs/man/man1/kubectl-wait.1 docs/man/man1/kubectl.1 docs/man/man1/kubelet.1 docs/user-guide/kubectl/kubectl.md docs/user-guide/kubectl/kubectl_annotate.md docs/user-guide/kubectl/kubectl_api-resources.md docs/user-guide/kubectl/kubectl_api-versions.md docs/user-guide/kubectl/kubectl_apply.md docs/user-guide/kubectl/kubectl_apply_edit-last-applied.md docs/user-guide/kubectl/kubectl_apply_set-last-applied.md docs/user-guide/kubectl/kubectl_apply_view-last-applied.md docs/user-guide/kubectl/kubectl_attach.md docs/user-guide/kubectl/kubectl_auth.md docs/user-guide/kubectl/kubectl_auth_can-i.md docs/user-guide/kubectl/kubectl_auth_reconcile.md docs/user-guide/kubectl/kubectl_autoscale.md docs/user-guide/kubectl/kubectl_certificate.md docs/user-guide/kubectl/kubectl_certificate_approve.md docs/user-guide/kubectl/kubectl_certificate_deny.md docs/user-guide/kubectl/kubectl_cluster-info.md docs/user-guide/kubectl/kubectl_cluster-info_dump.md docs/user-guide/kubectl/kubectl_completion.md docs/user-guide/kubectl/kubectl_config.md docs/user-guide/kubectl/kubectl_config_current-context.md docs/user-guide/kubectl/kubectl_config_delete-cluster.md docs/user-guide/kubectl/kubectl_config_delete-context.md docs/user-guide/kubectl/kubectl_config_get-clusters.md docs/user-guide/kubectl/kubectl_config_get-contexts.md docs/user-guide/kubectl/kubectl_config_rename-context.md docs/user-guide/kubectl/kubectl_config_set-cluster.md docs/user-guide/kubectl/kubectl_config_set-context.md docs/user-guide/kubectl/kubectl_config_set-credentials.md docs/user-guide/kubectl/kubectl_config_set.md docs/user-guide/kubectl/kubectl_config_unset.md docs/user-guide/kubectl/kubectl_config_use-context.md docs/user-guide/kubectl/kubectl_config_view.md docs/user-guide/kubectl/kubectl_convert.md docs/user-guide/kubectl/kubectl_cordon.md docs/user-guide/kubectl/kubectl_cp.md docs/user-guide/kubectl/kubectl_create.md docs/user-guide/kubectl/kubectl_create_clusterrole.md docs/user-guide/kubectl/kubectl_create_clusterrolebinding.md docs/user-guide/kubectl/kubectl_create_configmap.md docs/user-guide/kubectl/kubectl_create_deployment.md docs/user-guide/kubectl/kubectl_create_job.md docs/user-guide/kubectl/kubectl_create_namespace.md docs/user-guide/kubectl/kubectl_create_poddisruptionbudget.md docs/user-guide/kubectl/kubectl_create_priorityclass.md docs/user-guide/kubectl/kubectl_create_quota.md docs/user-guide/kubectl/kubectl_create_role.md docs/user-guide/kubectl/kubectl_create_rolebinding.md docs/user-guide/kubectl/kubectl_create_secret.md docs/user-guide/kubectl/kubectl_create_secret_docker-registry.md docs/user-guide/kubectl/kubectl_create_secret_generic.md docs/user-guide/kubectl/kubectl_create_secret_tls.md docs/user-guide/kubectl/kubectl_create_service.md docs/user-guide/kubectl/kubectl_create_service_clusterip.md docs/user-guide/kubectl/kubectl_create_service_externalname.md docs/user-guide/kubectl/kubectl_create_service_loadbalancer.md docs/user-guide/kubectl/kubectl_create_service_nodeport.md docs/user-guide/kubectl/kubectl_create_serviceaccount.md docs/user-guide/kubectl/kubectl_delete.md docs/user-guide/kubectl/kubectl_describe.md docs/user-guide/kubectl/kubectl_diff.md docs/user-guide/kubectl/kubectl_drain.md docs/user-guide/kubectl/kubectl_edit.md docs/user-guide/kubectl/kubectl_exec.md docs/user-guide/kubectl/kubectl_explain.md docs/user-guide/kubectl/kubectl_expose.md docs/user-guide/kubectl/kubectl_get.md docs/user-guide/kubectl/kubectl_label.md docs/user-guide/kubectl/kubectl_logs.md docs/user-guide/kubectl/kubectl_options.md docs/user-guide/kubectl/kubectl_patch.md docs/user-guide/kubectl/kubectl_plugin.md docs/user-guide/kubectl/kubectl_plugin_list.md docs/user-guide/kubectl/kubectl_port-forward.md docs/user-guide/kubectl/kubectl_proxy.md docs/user-guide/kubectl/kubectl_replace.md docs/user-guide/kubectl/kubectl_rollout.md docs/user-guide/kubectl/kubectl_rollout_history.md docs/user-guide/kubectl/kubectl_rollout_pause.md docs/user-guide/kubectl/kubectl_rollout_resume.md docs/user-guide/kubectl/kubectl_rollout_status.md docs/user-guide/kubectl/kubectl_rollout_undo.md docs/user-guide/kubectl/kubectl_run.md docs/user-guide/kubectl/kubectl_scale.md docs/user-guide/kubectl/kubectl_set.md docs/user-guide/kubectl/kubectl_set_env.md docs/user-guide/kubectl/kubectl_set_image.md docs/user-guide/kubectl/kubectl_set_resources.md docs/user-guide/kubectl/kubectl_set_selector.md docs/user-guide/kubectl/kubectl_set_serviceaccount.md docs/user-guide/kubectl/kubectl_set_subject.md docs/user-guide/kubectl/kubectl_taint.md docs/user-guide/kubectl/kubectl_top.md docs/user-guide/kubectl/kubectl_top_node.md docs/user-guide/kubectl/kubectl_top_pod.md docs/user-guide/kubectl/kubectl_uncordon.md docs/user-guide/kubectl/kubectl_version.md docs/user-guide/kubectl/kubectl_wait.md docs/yaml/kubectl/kubectl.yaml docs/yaml/kubectl/kubectl_alpha.yaml docs/yaml/kubectl/kubectl_annotate.yaml docs/yaml/kubectl/kubectl_api-resources.yaml docs/yaml/kubectl/kubectl_api-versions.yaml docs/yaml/kubectl/kubectl_apply.yaml docs/yaml/kubectl/kubectl_attach.yaml docs/yaml/kubectl/kubectl_auth.yaml docs/yaml/kubectl/kubectl_autoscale.yaml docs/yaml/kubectl/kubectl_certificate.yaml docs/yaml/kubectl/kubectl_cluster-info.yaml docs/yaml/kubectl/kubectl_completion.yaml docs/yaml/kubectl/kubectl_config.yaml docs/yaml/kubectl/kubectl_convert.yaml docs/yaml/kubectl/kubectl_cordon.yaml docs/yaml/kubectl/kubectl_cp.yaml docs/yaml/kubectl/kubectl_create.yaml docs/yaml/kubectl/kubectl_delete.yaml docs/yaml/kubectl/kubectl_describe.yaml docs/yaml/kubectl/kubectl_diff.yaml docs/yaml/kubectl/kubectl_drain.yaml docs/yaml/kubectl/kubectl_edit.yaml docs/yaml/kubectl/kubectl_exec.yaml docs/yaml/kubectl/kubectl_explain.yaml docs/yaml/kubectl/kubectl_expose.yaml docs/yaml/kubectl/kubectl_get.yaml docs/yaml/kubectl/kubectl_label.yaml docs/yaml/kubectl/kubectl_logs.yaml docs/yaml/kubectl/kubectl_options.yaml docs/yaml/kubectl/kubectl_patch.yaml docs/yaml/kubectl/kubectl_plugin.yaml docs/yaml/kubectl/kubectl_port-forward.yaml docs/yaml/kubectl/kubectl_proxy.yaml docs/yaml/kubectl/kubectl_replace.yaml docs/yaml/kubectl/kubectl_rolling-update.yaml docs/yaml/kubectl/kubectl_rollout.yaml docs/yaml/kubectl/kubectl_run.yaml docs/yaml/kubectl/kubectl_scale.yaml docs/yaml/kubectl/kubectl_set.yaml docs/yaml/kubectl/kubectl_taint.yaml docs/yaml/kubectl/kubectl_top.yaml docs/yaml/kubectl/kubectl_uncordon.yaml docs/yaml/kubectl/kubectl_version.yaml docs/yaml/kubectl/kubectl_wait.yaml </del>

<detailsIn response to : /help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-priority important-soon /priority important-longterm This hasn't been committed to for any release cycle in a while. I hope someone does commit to it, but I personally cannot, so I'm bumping down to the "hopefully next time" priority. /kind cleanup in addition to docs This impacts merge velocity of any kubectl/kubeadm changes because the docs/OWNERS file is small. We're going to work around by adding OWNERS files for the relevant sigs to the relevant dirs. But if these files don't have to exist in the first place, that'd be even better.
as discovered today this would not work as OWNERS in sub-folders do not solve the problem with the /docs/.generated_docs file which is in the parent folder. i've been looking into a solution to remove the placeholders completely and make verify-docs only consist of kube::util::gen-docs. this will: ensure that godoc errors and such still block presubmits the contributors are not blocked having to commit placeholder files
/lifecycle active
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle active as PR is still in flight.


Question: fakeShutdownChan := make(chan bool) fakeDbus := &fakeDbus{currentInhibitDelay: tc.systemInhibitDelay, shutdownChan: fakeShutdownChan, overrideSystemInhibitDelay: tc.overrideSystemInhibitDelay} <ins> lock.Lock() </ins> systemDbus = func() (dbusInhibiter, error) { return fakeDbus, nil }

/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
/sig node
I find the reason for it, but I don't know the solution is suitable, correct me if not.
/triage accepted /assign


Question: # --insecure-registry for local registries. DOCKER_OPTS=${DOCKER_OPTS:-""} <ins> # Extra options to set on the kube-proxy command line.  This is useful # for selecting the iptables proxy-mode, for example. KUBE_PROXY_EXTRA_OPTS=${KUBE_PROXY_EXTRA_OPTS:-""} </ins> # Optional: Install cluster DNS. ENABLE_CLUSTER_DNS="${KUBE_ENABLE_CLUSTER_DNS:-true}" # DNS_SERVER_IP must be a IP in SERVICE_CLUSTER_IP_RANGE

There should be a way to select the iptables proxy-mode.
Are you interested in modifying ubuntu deploy scripts to use a user provided configure file?
This is fixed by and it will be merged in soon.
This fix breaks cluster/kube- while kubernetes provider is rather than ubuntu, as the following variables are only defined in ubuntu folder PROXYSETTING=${PROXYSETTING:-""} DEBUG=${DEBUG:-"false"} When I run KUBERNETES_PROVIDER=vagrant and run cluster/kube- It will fail with error "==master: [ERROR ] {'pid': 5871, 'retcode': 1, 'stderr': ' line 21: DEBUG: unbound variable', 'stdout': ''}" I will open a separated issue to discuss the solution.
I do not understand. I have not tried KUBERNETESPROVIDER=vagrant and run cluster/kube-, can you please clarify what is going wrong? This PR () affected only files in cluster/ubuntu/; are you saying that some of them are used when KUBERNETESPROVIDER=vagrant? This PR did not introduce PROXY_SETTING or DEBUG.
I tried running kube- with the Vagrant provider, but ran into a different (and much prior) problem; see --- any help would be appreciated.
OK, I see you opened issue for this and PR fixed it. Thanks. I will respond to the larger question under .


Question: "strings" "time" <ins> "github.com/ghodss/yaml" </ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The local-volume bootstrapper/provisioner configuration format changed in kubernetes-incubator/external-storage, and its related e2e tests will fail when the provisioner & bootstrapper images are updated to v2.0.0. What you expected to happen: I'd expect the e2e tests to continue to work properly with the new version of the provisioner and boostrapper. How to reproduce it (as minimally and precisely as possible): Update local-volume provisioner and boostrapper images to v2.0.0, and then the provisioner e2e test will fail.
/sig storage
/assign


Question: var _ = SIGDescribe("Network", func() { const ( <del> testDaemonHTTPPort    = 11301 testDaemonTCPPort     = 11302 timeoutSeconds        = 10 postFinTimeoutSeconds = 5 </del> <ins> testDaemonHTTPPort     = 11301 testDaemonTCPPort      = 11302 deadlineTimeoutSeconds = 10 postFinTimeoutSeconds  = 30 </ins> ) fr := framework.NewDefaultFramework("network")

Which jobs are failing: kops-aws and many other jobs Which test(s) are failing: This isn't the actual test, but the text we're consistently seeing is Since when has it been failing: Testgrid links: (ref: ) Reason for failure: TBD Anything else we need to know: Very rarely tests pass when one of the tests passes: Seems related to , that was merged about the same time:
/sig cluster-lifecycle /sig aws
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cluster-lifecycle /sig aws Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority critical-urgent this is merge blocking
/assign /cc /cc /cc
The PR we think we want to revert
is also failing, I don't think this is aws-specific
/cc
/assign
it failed with kind too :/ with the same message
Opened to revert
/unassign /sig network /sig testing /remove-sig cluster-lifecycle
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
This may be the actual cause PR to address But we're going with revert first to be sure we've identified the offending PR
I think I've identified the root cause
Revert brought us back to green: Awaiting root cause fix
/remove-triage unresolved
/reopen merged but we're now seeing multiple tests fail since it merged Looking at it went red between these commits:
Reopened this issue. <detailsIn response to : /reopen merged but we're now seeing multiple tests fail since it merged Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
is an attempt to fix
reverting in
is the failure cluster I suspect will go down once the revert goes in
/close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"
Closing this issue.


Question: var _ = SIGDescribe("Network", func() { const ( <del> testDaemonHTTPPort    = 11301 testDaemonTCPPort     = 11302 timeoutSeconds        = 10 postFinTimeoutSeconds = 5 </del> <ins> testDaemonHTTPPort     = 11301 testDaemonTCPPort      = 11302 deadlineTimeoutSeconds = 10 postFinTimeoutSeconds  = 30 </ins> ) fr := framework.NewDefaultFramework("network")

<detailsIn response to : /close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"</details


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

Nodes can't recognize the static pods that they create possibly because the defaulting is different. always returns false. Here is a json diff of two pod specs before and after they are Semenatic.DeepEqual'd where before is created pod and after is what kubelet things the created pod should be. ! Thus: p0 for triage
I think the solution is to not apply defaults to mirror pods in the API Server.
Yes,we have to add specific code to API Server to detect the mirror pod, then not apply defaults.
The right fix should be , which we didn't get to before v1.0. I will start on this and at least get it in for v1.1 to prevent future complications. Since we cannot update the node/kubelet, options are: suggests to disable applying defaults to mirror pods as a temporary fix. IIRC, was against treating mirror pod differently at the apiserver. Since this is only a workaround, perhaps we can relax the constraint? a script to update the pod manifest files.
Disabling defaults has a number of problems: are version-specific. Conversion may fail if defaults are not applied. may fail if defaults are not applied. using defaulted fields assumes default values have been applied. defaulting pass is not the only place where values can be set, as mentioned in . For instance, if the user were to change the kube-system LimitRange, that would cause the same problem. This is another case where would have been useful. Which gives me another idea. For mirror pods, we could capture the entire metadata+spec provided by the user as an annotation, as we do in the client for kubectl apply, and then we could return that in GET. PUT may not work. We'd have to resolve the size concerns raised by . How serious of a problem is this delete-recreate loop?
Ok, we are going with approach proposed in . I am closing this issue as dup of
"entire metadata+spec" in plain text? It'd be hard for kubelet to diff using this. It'd be better to let kubelet store hash of its own choosing so that it can easily compare when there is any change.
Even with , we can't fix v1.0 kubelet.
I agree with
Yes, I were confused.


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

The comparison is in Kubelet, and we cannot patch 1.0 kubelet in this case.
There are no serious issues with this bug: static pods are running properly, but corresponding mirror pods coming and gone. cc/ Can we treat this as part of GKE cluster upgrade process? Can we upgrade GKE master nodes, then ask the users to upgrade their fluentd yaml file in their cluster? For OSS kubernetes users, most likely they won't run into this issue. But we should document this as known issue for 1.1.
Or can we update the fluentd yaml files when updating the master?
cc/
This is a cc issue, really. But the fast answer is no, because "then ask the users to upgrade their fluentd yaml file in their cluster?" Historically our users are extremely slow to do maintenance.
Our current plan for this issue is just document as a known issue for 1.1 release.
In a 100 node cluster this is going to cause +100 writes +100 deletes per second. Is that extra load a concern?
This would be +100 writes +100 deletes every 10 seconds in a 100-node cluster. We are still discussing options to let user update their manifest files.
Ok, from the logs in the issue description, it looked more frequent but most of the deletes are failing with key not found
's easy to trigger a sync for all pods in kubelet. Any change in any pod would trigger a sync. In this case, the DELETE/ADD of the mirror pod could also trigger another sync. So, yes, it could be worse than 10s... We are looking at patching this in the apiserver, based on suggestion.
Yeah, my suggestion is fixing defaulting/conversion/validation as needed to make exceptions for mirror pods.
I'm not 100% sure it's needed, but if necessary we can turn the defaulting fix on in apiserver, and leave it off in scheduler, so that it gets the defaults it expects.
Yeah, it is way more frequent than 10s. I pointed this out to earlier. We had a meeting with and looks like: Providing a scripts to convert fluentd yaml file and asking the user to run is not a solution. Our users are very slow on such maintenance work. Piggyback such conversion work on master updating might not a solution for GKE clusters.


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

We do have access to GKE nodes, and we don't do that. To obtain the permission to run script and sync a file requires more work from PM side. This is a API backward compatibility issue anyway. Given today's version management policy, we should handle such compatibility issue. I checked our default code: request diff was introduced by TerminationGracePeriodSeconds was introduced along with graceful termination support. There is no conversion for both fields There is no validation checking both fields today I think it is safe to disable such defaulting for mirror pods shouldn't cause any issue for 1.1 release. Sending PR shortly.
In order to not break the v1.1+ kubelet (which applies newer defaults), we should only skip defaulting for pods from pre-v1.1 kubelets. An easy way to do this is to reuse , which changes the mirror key annotation value from "mirror" to the hash of the pod manifest file. In short, if the key exists, it's a mirror pod. If the value is "mirror", it is sent by a pre-v1.1 kubelet. Otherwise, it's sent by a v1.1+ kubelet. Note that we will also need to maintain the special defaulting case for the future releases until we drop support for v1.0 nodes.
Just this morning, we discussed providing a script/tool to update static pod configs for people with large clusters. Why have we changed that plan? Any hack in apiserver is going to be confusing and fragile. For instance, a LimitRange installed for kube-system would defeat the hack. If we were to add a hack in apiserver, we'd need to remove it in 1.2.
we talked to and the conclusion was that node update may not be feasible as . I agree that any apiserver fix is hacky and fragile, but it seems the most viable option right now. We would need to carry this fix in apiserver as long as GKE supports v1.N master + v1.0 node, unless we can make updating the configs part of the cluster upgrade process.
Ah. These fields are problems because they existed in 1.0, but weren't used nor populated. Entirely new fields are silently dropped during decoding.


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

We should cherrypick the solution into 1.0.7, since it appears there will be one.
That is, we should cherrypick into the 1.0 branch.
Ref.
If the hack is going to remain indefinitely, I'm not comfortable circumventing defaulting, conversion, and validation.
Just not performing the defaulting for these specific fields on just mirror pods seems safer.
In particular, I could easily imagine a new version of the pod API in 1.2 or 1.3, which will require defaulting and conversion to be applied, in general.
We'll be discussing this soon after 1.1 lands, I expect. My proposal would be for v1.N masters to support v1.N-1 and v1.N-2 (and maybe v1.N-3) nodes. That gives users 6-9 months to lag their nodes behind their masters. But it warrants much further discussion. This isn't a viable solution either, because we can't depend on users updating their nodes to the latest 1.0 rev. We expect arbitrary 1.0 nodes to work, including 1.0.6 all the way back to 1.0.1, per our current .
As Ike noted, cherrypicking into 1.0 kubelets is not feasible for solving this, because the whole reason for the problem is that people aren't updating their nodes. The conversion fix in is much preferable to the defaulting fix: it's less brittle, and components that need the defaulting (e.g. scheduler) will see the defaulting (because they run the conversion stack themselves), but on the wire the mirror pods from old kubelets will remain undefaulted.
I didn't say cherrypicking into 1.0 would solve the problem for everything. The behavior in 1.0 is pretty broken, even when not considering upgrade. We have a fix. We should cherrypick it into 1.0.
I don't see how different components would see different values for these fields, assuming they are all updated to the new code. As discussed offline, the scheduler and node controller need to handle cases of empty requests and pod termination for 1.0 kubelets, anyway, so I think the conversion approach is fine. Please put the explanation in code comments, though, not just in issue/PR comments.


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

Since the conversion stack does the defaulting at the end and runs in every component, and scheduler, node-controller, etc all consume api.Pod objects (instead of v1.Pod objects), they will have a view of the object with the fields defaulted. The conversion based fix essentially retains the defaulting in *api.Pod objects, but undoes it in any serialized representation of the object. Over the wire the defaulting will not be baked in to the object. Older clients that have not been recompiled (including these kubelets) would see a version of the object without the fields being defaulted.
Defaulting is run first:
Oh, you're right, I somehow had that backwards in my head. Sorry, everyone. I think that tilts me back in favor of . This means that defaulting is part of the versioned structs and therefore changing the defaulting is an API breaking change, which we claimed we wouldn't do. Can we change our minds about the defaulting? How about moving this particular defaulting into conversion functions, which is the intended way of doing something like this?
In , we only reset the defaults when converting api.Pod to v1.Pod. Shouldn't all components still see the defaulting values? Agreed that this is an API breaking change. Perhaps we should not change the defaults at all? mentioned in that scheduler already deals with empty requests. It's true in , but seems untrue in . Maybe this should be fixed. As for , we can also ask kubelet to apply a default value if we truly on to have the 30 second dfault.
resources.requests and terminationGracePeriodSeconds are effectively newly fields, so setting defaults is not a breaking change for most clients. If Kubelet were comparing the pre-decoded pods returned by apisever, it would barf on every new field we've . It's an accident of the implementation that it broke on exactly these fields.
Actually, neither priorities nor predicates takes values from limits any longer. That code is rely on the defaulting pass to copy limits to requests in the case that the requests field is absent. We would need to change that, yes, if we were to not set requests for the 1.0 mirror pods.
This Kubelet behavior was known to be broken back in May: What we're trying to do now is figure out a workaround for this broken behavior.


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

My recommended solution is: not set resources.requests and terminationGracePeriodSeconds to non-nil values for just 1.0 mirror pods. All other fields and all other pods, including 1.1 mirror pods, should have default values set normally. Doing this in the defaulting pass makes the most sense, assuming that it's straightforward to do given the structure of that pass. the scheduler fit and priority functions to use limits for pods where requests are entirely absent. that the new code in the node controller to handle termination of pods on 1.0 kubelets deals with unset terminationGracePeriodSeconds appropriately. a kind/workaround-removal issue to remove these hacks once we don't need to worry about 1.0 kubelets.
Just for comparison, an alternative: this default setting from the defaulting function. it to the conversion function instead. mirror pods from 1.0 kubelets (MPF1K), store the original value in an annotation. MPF1K, when converting to v1, restore the original value & remove the annotation. No changes needed anywhere else in the system, maintenance cost is very low, we can carry this as long as needed.
I don't see how that keeps the default values off the wire.
Actually, I think I see. Yes, I think that could work.
The defaults are on the v1-internal transition, and removed on the internal-v1 transition.
(3) is converting v1 to IR, and (4) is converting IR to v1, either for storing to etcd or to communicate to another component, such as Kubelet.
I'm saying stop using the default setting code for setting these "breaking" defaults.
Right.
I don't think we want to do this for pods in general, though, just for MPF1K
So I think we can actually just add a few more changes to PR and it should work. (Just move the defaulting.)
Yes, I agree. Just for MPF1K. We can easily broaden it if needed.
SGTM
We're going to want to do something similar for new fields to alpha API versions that we don't want to expose in the stable, serialized version of the API.
So if this works, we should add it to
Yes. Changing defaults is a breaking change and therefore needs to happen in conversion.


Question: "k8s.io/kubernetes/pkg/apis/extensions" ) <del> const ( // Annotation key used to identify mirror pods. mirrorAnnotationKey = "kubernetes.io/config.mirror" // Value used to identify mirror pods from pre-v1.1 kubelet. mirrorAnnotationValue_1_0 = "mirror" ) </del> // This is a "fast-path" that avoids reflection for common types. It focuses on the objects that are // converted the most in the cluster. // TODO: generate one of these for every external API group - this is to prove the impact

Adding new fields with new defaults is fine, just not changing the behavior of existing fields. course I do think kubelet is being a very inflexible client here, but we can't fix the stuff that's already out there.
+1 to both points. We should've patched kubelet sooner to avoid this, but it's out there and kubelet 1.0 remains a stubborn client. Sorry for that. thanks for coming up with the solution! Since both of you agreed on , I will change my PR acoordingly.
So that there is no misunderstanding that leads to future such problems: Whether fields are new or pre-existing, it is an invalid assumption that unset fields may not be changed, whether by defaulting or by some other process, such as admission control.
This issue will be considered fixed for 1.1 once is submitted. (I didn't read this thread carefully enough yet to know whether additional work is necessary before considering this whole issue closed.)
Update: has just been merged. Closing the issue.
Probably we should not close this issue until we do a cherrypick?
The change was cherrypicked, so closing this issue


Question: <ins> /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package fieldmanager_test import ( "reflect" "testing" "time" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime/schema" "sigs.k8s.io/yaml" ) func TestNoManagedFieldsUpdateDoesntUpdateTime(t *testing.T) { f := NewTestFieldManager(schema.FromAPIVersionAndKind("v1", "Pod"), false, nil) obj := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "pod", "labels": {"app": "nginx"} }, }`), &obj.Object); err != nil { t.Fatalf("error decoding YAML: %v", err) } if err := f.Update(obj, "fieldmanager_test"); err != nil { t.Fatalf("failed to update object: %v", err) } managed := f.ManagedFields() obj2 := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "pod", "labels": {"app": "nginx2"} }, }`), &obj2.Object); err != nil { t.Fatalf("error decoding YAML: %v", err) } time.Sleep(time.Second) if err := f.Update(obj2, "fieldmanager_test"); err != nil { t.Fatalf("failed to update object: %v", err) } if !reflect.DeepEqual(managed, f.ManagedFields()) { t.Errorf("ManagedFields changed:nBefore:n%vnAfter:n%v", managed, f.ManagedFields()) } } </ins>

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I'm trying to automate the usage of to check for changes that need to be applied to the cluster based on a static set of manifests. However, for some manifests, if I run the output contains differences on fields called and , after the manifest was applied to the cluster. I ran . After that, I ran The following output was produced (I copied just the first diff, as many more followed): What you expected to happen: No differences should be detected. How to reproduce it (as minimally and precisely as possible): Run Then run Anything else we need to know?: This does not happen to all manifests. If I try with the manifest no differences are detected. I also tried with manifests loaded from disk, and was able to reproduce the behavior with the following manifest: With the above manifest the following occurs: Empirically, the differences observed always seem to be some seconds apart between the two versions. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: baremetalOS (e.g: ):Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig CLI
Ref: The newest version of has a different result still has a problem when diffing :
Sorry, I was unaware that there was a specific repository on which to report kubectl related issues. If needed, I can recreate this issue on the kubernetes/kubectl repository. Do let me know if this is preferred.
/assign
Hey, thanks for the report About the first issue, applying "". It looks like this yaml is dynamically generated and different every time you get it: So I think this one is totally working as intended. We're showing a difference because there is an actual difference. The second one is actually a bug that we are supposed to have fixed in 1.18. Let me look at it.
Ah, I see. That does account for the differences in the date field. Most unfortunate for me, but definitely not a bug in kubernetes/kubelet. My apologies, I should have checked that first.


Question: <ins> /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package fieldmanager_test import ( "reflect" "testing" "time" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime/schema" "sigs.k8s.io/yaml" ) func TestNoManagedFieldsUpdateDoesntUpdateTime(t *testing.T) { f := NewTestFieldManager(schema.FromAPIVersionAndKind("v1", "Pod"), false, nil) obj := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "pod", "labels": {"app": "nginx"} }, }`), &obj.Object); err != nil { t.Fatalf("error decoding YAML: %v", err) } if err := f.Update(obj, "fieldmanager_test"); err != nil { t.Fatalf("failed to update object: %v", err) } managed := f.ManagedFields() obj2 := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "pod", "labels": {"app": "nginx2"} }, }`), &obj2.Object); err != nil { t.Fatalf("error decoding YAML: %v", err) } time.Sleep(time.Second) if err := f.Update(obj2, "fieldmanager_test"); err != nil { t.Fatalf("failed to update object: %v", err) } if !reflect.DeepEqual(managed, f.ManagedFields()) { t.Errorf("ManagedFields changed:nBefore:n%vnAfter:n%v", managed, f.ManagedFields()) } } </ins>

So the only actual issue is with the changing time field. Thanks for looking into that. Do let me know if there is anything I can do to help.
Can you show me the object before you run that diff? I'm curious what the first "fieldManager" is and why it's different from "kubectl-client-side-apply". Also, did you create the object using ?
I figured out what the problem is in that second message: the cpu goes from an to a : Note that I'm using a non-server-side capable apiserver version, but I think the problem is the same: we can't detect that this object has been changed because cpu goes from to , or from to and we consider this as a change. I have no clue how to solve that "bug".
Hi The test you made is comparing the local yaml against the version the apiserver currently has, correct? That would be similar to running the diff with the option to run server side, which I think yields a suspiciously similar result: I also suspect that it is for this reason that if I run the apply command with the dry-run flag, we always get incoming changes to apply: For comparison sake, the same test with the server-metrics manifest, that does not produce any diff changes, does not detect any incoming changes (notice all of the items are marked with unchanged): I also have no idea how to fix this properly, but perhaps running a yaml formatter on both sources (left and right) before comparison could produce better results? A canonical representation of both inputs might be better suited for comparison. Perhaps such a behavior could be controlled with a new enabling CLI flag. Again, thanks for looking into this. Having a more reliable diff behavior would go a long way for us to detect configuration mismatches against our configuration management system.
Sure thing! I spawned from this bug report to cover the "failed to create typed patch object" problem. I will try to test with the newly minted 1.19 release later today, to see if any previously observed behavior changes.
I recreated the cluster as version 1.19.0, and here are the results of the previous tests: Ran as expected Ran as expected Ran showing unexpected diff results
Thanks for all the details that's actually really useful for me to understand what's going on.
Some more context.


Question: <ins> /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package fieldmanager_test import ( "reflect" "testing" "time" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime/schema" "sigs.k8s.io/yaml" ) func TestNoManagedFieldsUpdateDoesntUpdateTime(t *testing.T) { f := NewTestFieldManager(schema.FromAPIVersionAndKind("v1", "Pod"), false, nil) obj := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "pod", "labels": {"app": "nginx"} }, }`), &obj.Object); err != nil { t.Fatalf("error decoding YAML: %v", err) } if err := f.Update(obj, "fieldmanager_test"); err != nil { t.Fatalf("failed to update object: %v", err) } managed := f.ManagedFields() obj2 := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "pod", "labels": {"app": "nginx2"} }, }`), &obj2.Object); err != nil { t.Fatalf("error decoding YAML: %v", err) } time.Sleep(time.Second) if err := f.Update(obj2, "fieldmanager_test"); err != nil { t.Fatalf("failed to update object: %v", err) } if !reflect.DeepEqual(managed, f.ManagedFields()) { t.Errorf("ManagedFields changed:nBefore:n%vnAfter:n%v", managed, f.ManagedFields()) } } </ins>

A Gatekeeper user reported behavior where always shows a diff in the timestamp for of its CRD objects -- it looks like non-CRDs are unaffected. This happens when re-applying the static manifest found at
Thanks, this is useful, we'll look into it!


Question: SourceObject: &unstructured.Unstructured{ Object: map[string]interface{}{ "apiVersion": "example.com/v1", <ins> "metadata":   map[string]interface{}{}, </ins> "other":      "data", "kind":       "foo", },

If a CR converter is wired in and it modifies the input list, the delegating CR converter does not protect against this. A converter cannot effect the input list Not really possible externally - it's a coding issue that the current converters don't hit. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /assign
/triage accepted


Question: `spec.terminationGracePeriodSeconds: must be >= 0; negative values are invalid and will be treated as 1`, }, }, <ins> { name: "null LabelSelector in topologySpreadConstraints", template: &api.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{}, Spec: api.PodSpec{ TopologySpreadConstraints: []api.TopologySpreadConstraint{ { LabelSelector: &metav1.LabelSelector{}, }, { LabelSelector: nil, }, }, }, }, expected: []string{ `spec.topologySpreadConstraints[1].labelSelector: a null labelSelector results in matching no pod`, }, }, { name: "null LabelSelector in PodAffinity", template: &api.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{}, Spec: api.PodSpec{ Affinity: &api.Affinity{ PodAffinity: &api.PodAffinity{ RequiredDuringSchedulingIgnoredDuringExecution: []api.PodAffinityTerm{ { LabelSelector: &metav1.LabelSelector{}, }, { LabelSelector: nil, }, }, PreferredDuringSchedulingIgnoredDuringExecution: []api.WeightedPodAffinityTerm{ { PodAffinityTerm: api.PodAffinityTerm{ LabelSelector: &metav1.LabelSelector{}, }, }, { PodAffinityTerm: api.PodAffinityTerm{ LabelSelector: nil, }, }, }, }, PodAntiAffinity: &api.PodAntiAffinity{ RequiredDuringSchedulingIgnoredDuringExecution: []api.PodAffinityTerm{ { LabelSelector: &metav1.LabelSelector{}, }, { LabelSelector: nil, }, }, PreferredDuringSchedulingIgnoredDuringExecution: []api.WeightedPodAffinityTerm{ { PodAffinityTerm: api.PodAffinityTerm{ LabelSelector: &metav1.LabelSelector{}, }, }, { PodAffinityTerm: api.PodAffinityTerm{ LabelSelector: nil, }, }, }, }, }, }, }, expected: []string{ `spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution[1].labelSelector: a null labelSelector results in matching no pod`, `spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution[1].podAffinityTerm.labelSelector: a null labelSelector results in matching no pod`, `spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[1].labelSelector: a null labelSelector results in matching no pod`, `spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[1].podAffinityTerm.labelSelector: a null labelSelector results in matching no pod`, }, }, </ins> } for _, tc := range testcases {

Currently, when the Label Selector in the Pod Affinity is empty, no objects will be match. That means if it's in a required PodAffinity, the Pod will never be schedulable. And if it's in a required PodAntiAffinity, that PodAntiAffinity will be no-op. So, I'm thinking PodAffinity with empty Label Selector is very likely mistake. It'd be good if we could notice it for users. To prevent such a misconfiguration. Probably, we cannot filter out such a Pod creation in the validation for a backward compatibility. /assign /sig scheduling
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'm wondering if it has already discussed somewhere or not. Please just let me know if we have some decisions on it.
I am not sure, where do you propose to put the warning? If the pod is unschedulable, that will show up in the events and pod status.
Do you mean the place to implement this warning? I suspect ↓ is a suitable place:
A warning sounds useful, even if the pod is unschedulable, as it gives you a heads up at the time when you create the Pod. Whereas the Pod scheduling failure might be a bit harder to interpret.
ok, I thought you were referring to something that the scheduler will produce after attempting to schedule the pod. Yeah, if there is already a setup to print warnings on pod creation, it is certainly useful for this case.
Can you please also add it in topology spread?
Sure


Question: }{ { name:              "all normal requests use only one connection", <del> reqs:              []string{urlNormal, urlNormal, urlNormal}, </del> <ins> reqs:              []string{urlGet, urlPost, urlGet}, </ins> expectConnections: 1, }, { name:              "got GOAWAY after set-up watch", <del> reqs:              []string{urlNormal, urlWatch, urlGoaway, urlNormal, urlNormal}, </del> <ins> reqs:              []string{urlPost, urlWatch, urlGetWithGoaway, urlGet, urlPost}, </ins> expectConnections: 2, }, { name:              "got GOAWAY after set-up watch, and set-up a new watch", <del> reqs:              []string{urlNormal, urlWatch, urlGoaway, urlWatch, urlNormal, urlNormal}, </del> <ins> reqs:              []string{urlGet, urlWatch, urlGetWithGoaway, urlWatch, urlGet, urlPost}, </ins> expectConnections: 2, }, { name:              "got 2 GOAWAY after set-up watch", <del> reqs:              []string{urlNormal, urlWatch, urlGoaway, urlGoaway, urlNormal, urlNormal}, </del> <ins> reqs:              []string{urlPost, urlWatch, urlGetWithGoaway, urlGetWithGoaway, urlGet, urlPost}, </ins> expectConnections: 3, }, { name:              "combine with watch-with-goaway", <del> reqs:              []string{urlNormal, urlWatchWithGoaway, urlNormal, urlWatch, urlGoaway, urlNormal, urlNormal}, </del> <ins> reqs:              []string{urlGet, urlWatchWithGoaway, urlGet, urlWatch, urlGetWithGoaway, urlGet, urlPost}, </ins> expectConnections: 3, }, }

What happened: We enabled feature in our large-scale cluster, and we found client(Kubelet) may got error(500 http code response) like after received GOAWAY frame. I had already re-produce this bug and open an in golang repo. So far I think this bug only occur with a small probability when client request server in high concurrency use a same httpclient instance, and it's a golang sdk bug in http client. Before I solved this issue, I suggest do NOT enable GOAWAY() feature. As it's a golang sdk bug(currently I known and doubt) in http client, revert GOAWAY feature(codes) is not necessary.
cc
/sig api-machinery
Thanks for the report.
Based on not setting the field, I think it defaults that way, so that's good. We will leave the option and filter so that when golang updates its client, we will have a simple way to turn it on and execute it.
Sure. I am trying to fix the golang http client issue and will update progress at . After golang http client issue fixed, I will add more concurrent test cases to see if there are any other bugs may occur by GOAWAY feature. BTW, we still enable GOAWAY feature in our production cluster, because there is no any evidence told us this error will influence SLO, as all most components(kubelet, controller-manager, scheduler) is controller work mode and will re-try after got error. /assign
Golang version or required, which will release at 07/01/2020.
Kubernetes v1.19(or master branch) now is using golang 1.15, and golang 1.15 has fixed the issue. And is on going. Let me add more test cases to ensure the error will not happen again.
I think we should re-open this issue because of . /re-open


Question: ginkgo.Describe("Kubectl server-side dry-run", func() { /* <del> Release : v1.18 </del> <ins> Release : v1.19 </ins> Testname: Kubectl, server-side dry-run Pod Description: The command 'kubectl run' must create a pod with the specified image name. After, the command 'kubectl replace --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. */ <del> ginkgo.It("should dry-run update the Pod", func() { </del> <ins> framework.ConformanceIt("should check if kubectl can dry-run update Pods", func() { </ins> ginkgo.By("running the image " + httpdImage) podName := "e2e-test-httpd-pod" nsFlag := fmt.Sprintf("--namespace=%v", ns)

and server-side dry-run are being promoted to stable features in 1.18. Conformance should ensure that cloud providers support these features. As a user, I expect to work, which requires that cloud providers for cloud default webhooks. Conformance would generally avoid cloud-specific issues like this one: This suggestion is from /area conformance
/sig testing /sig architecture
/wg apply
There are some good references for conformance tests in the conformance meeting notes:
once merges, we need to promote the e2e test to conformance in a follow up PR, in accordance to this doc: It seems like we meet the conformance test requirements. Here's the process specifically, which includes sig-arch and a review board group:


Question: // conditions is the set of conditions required for this autoscaler to scale its target, // and indicates whether or not those conditions are met. <ins> // +optional </ins> Conditions []HorizontalPodAutoscalerCondition `json:"conditions" protobuf:"bytes,6,rep,name=conditions"` }

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Serializing a v2beta2 HorizontalPodAutoscaler with (and ) produces yaml that cannot be applied due to a ValidationError on the field which is under the optional field . A valid HPA serialized with should be able to be applied to the cluster with no validation errors, without filling out the optional field. Other valid objects (such as Namespaces and Deployments) can be applied directly, without filling out their optional fields. Run this to generate the serialized yaml (same outcome with both and functions) Running the go code should yield this yaml: Writing the above yaml to a file and applying it (with ) will result in: Kubernetes version (use ): Server: v1.20.2, Client: v1.20.4 go version: go1.16 darwin/amd64 has: cc cc
/sig api-machinery /sig autoscaling /sig cli
/assign /triage accepted
marking conditions as +optional in the API type would resolve the client-side apply error
It would remove the validation error, but I'd be concerned about any side effects or unwanted outcomes when moving that field from required to optional. A somewhat analogous field is required. But if you anticipate this won't change much else, that will work.
Client-side validation is non-authoritative, and problematic for the reasons described in this issue ... the client is disallowing a request the server would actually have no problems with. No field the server would permit to be empty (e.g. succeeds with ) should be marked as required for this reason. fwiw, openapi schema generation marks fields tagged as as optional:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.


Question: // conditions is the set of conditions required for this autoscaler to scale its target, // and indicates whether or not those conditions are met. <ins> // +optional </ins> Conditions []HorizontalPodAutoscalerCondition `json:"conditions" protobuf:"bytes,6,rep,name=conditions"` }

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten


Question: }() } }(cache, clusterName) <ins> sc.endpointWorkerMap[clusterName] = true </ins> } }

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: What happened: Memory usage of federation-control-manager keeps on increasing to very large size overtime. What you expected to happen: Memory usage is stable How to reproduce it (as minimally and precisely as possible): Register one or more cluster to federation control plane and watch the top output for the federation-control-manager Also can check the pprof, here is the one such output after federation-control-manager is run for an hour. We can see there are around goroutines created in an hour which are leaked and would consume memory. Anything else do we need to know: I do have a fix for the issue and would be happy to submit it, if this issue is accepted.
plz check the issue
feel free to just submit a pull request, we don't really have a concept of an issue being "accepted" :)
This looks like a legitimate bug. could you please clarify what version of the federated service controller you are running? The image path and version of the container, or a git hash of the source should be sufficient.
i am taking the latest code from master branch.


Question: framework.ConformanceIt("should update pod when spec was updated and update strategy is RollingUpdate", func() { label := map[string]string{daemonsetNameLabel: dsName} <del> templateGeneration := int64(999) framework.Logf("Creating simple daemon set %s with templateGeneration %d", dsName, templateGeneration) </del> <ins> framework.Logf("Creating simple daemon set %s", dsName) </ins> ds := newDaemonSet(dsName, image, label) ds.Spec.UpdateStrategy = apps.DaemonSetUpdateStrategy{Type: apps.RollingUpdateDaemonSetStrategyType} ds, err := c.AppsV1().DaemonSets(ns).Create(ds)

Please see : https://k8s- fails just after this line: Failure was introduced in: But this was not noticed until it started running in [Conformance] tests. You can see the same problem in other dashboards too: https://k8s- https://k8s-
cc /sig apps
/priority critical-urgent
/kind bug /priority failing-test
/milestone v1.10
Is this just an oversight of not removing the template generation when the API update was done?
/cc
triaged in progress
i have never touched this test before ... so i just threw in a WIP, feel free to use/discard it. there seems to be lot of methods in there that is no longer used, may be we can rip those out too. (see )
xref
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action Required: This issue has not been updated since Mar 5. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: <ins> package(default_visibility = ["//visibility:public"]) licenses(["notice"]) load( "@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library", ) go_binary( name = "nonewprivs", library = ":go_default_library", tags = ["automanaged"], ) go_library( name = "go_default_library", srcs = ["nnp.go"], tags = ["automanaged"], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], ) </ins>

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature This issue is for creating image as multiarch
/assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig testing


Question: var map_EndpointPort = map[string]string{ "":         "EndpointPort is a tuple that describes a single port.", <del> "name":     "The name of this port (corresponds to ServicePort.Name). Must be a DNS_LABEL. Optional only if one port is defined.", </del> <ins> "name":     "The name of this port.  This must match the 'name' field in the corresponding ServicePort. Must be a DNS_LABEL. Optional only if one port is defined.", </ins> "port":     "The port number of the endpoint.", "protocol": "The IP protocol for this port. Must be UDP, TCP, or SCTP. Default is TCP.", }

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When running a cluster service and manually created endpoints, the port name set on the cluster definition acts as an implicit selector - suitable end-points do not get mapped to the cluster service. What you expected to happen: Port name shouldn't be an implicit selector. How to reproduce it (as minimally and precisely as possible): Using the following spec file "": kubectl create -f , then describe the service. Output shows the endpoint as being correctly mapped Now run kubectl delete -f the and uncomment the name: foobar Re-run the kubectl create -f command. Now, checking the service gives the output below (end point isn't mapped): Anything else we need to know?: Adding the name: foobar to the endpoint definition makes the end point to be mapped again into the cluster. I.e. there is an implicit matching of the end-point and cluster port definitions. This is either a bug or a very surprising and undocumented feature Environment: kubectl version Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-03-25T02:52:13Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-01-16T18:14:49Z", GoVersion:"go1.10.7", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): root cat /etc/os-release NAME="Ubuntu" VERSION="18.04.1 LTS (Bionic Beaver)" Kernel (e.g.


Question: var map_EndpointPort = map[string]string{ "":         "EndpointPort is a tuple that describes a single port.", <del> "name":     "The name of this port (corresponds to ServicePort.Name). Must be a DNS_LABEL. Optional only if one port is defined.", </del> <ins> "name":     "The name of this port.  This must match the 'name' field in the corresponding ServicePort. Must be a DNS_LABEL. Optional only if one port is defined.", </ins> "port":     "The port number of the endpoint.", "protocol": "The IP protocol for this port. Must be UDP, TCP, or SCTP. Default is TCP.", }

): uname -a Linux 4.15.0-51-generic -Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/remove-sig api-machinery /sig network The name mapping to the endpoints is intentional, but needs documentation
/triage unresolved
/assign
It may be under-documented, but it is not UNdocmented.
Also
working on a PR to fix doc


Question: TemplateArgument: &tc.templateArg, AllowMissingKeys: tc.allowMissingKeys, } <ins> if !sort.StringsAreSorted(printFlags.AllowedFormats()) { t.Fatalf("allowed formats are not sorted") } </ins> outputFormat := "template" p, err := printFlags.ToPrinter(outputFormat)

/kind bug What happened: When building kubernetes-1.7.0 packages for openSUSE, results differ for each build in and other man pages. coming from that uses and probably sets do not have any specific order, so it would need to be sorted on output. What you expected to happen: Every build should give identical results. See https://reproducible- for why this matters. How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version: 1.7.0 OS (e.g. from /etc/os-release): openSUSE Tumbleweed
/sig release
somehow this bug seems to have been forgotten - can you help getting the right people to have a look?
- can you please confirm that PR works for you?
I tested it and it looks good.
/assign I enjoy reading my highlights to find the issue has already been addressed. :)
Sorry this wasn't addressed sooner. It does seem like it fell into a black hole, and pinging was the right way to resolve that. :)
/area build-release
related to /reopen
Reopening this issue. <detailsIn response to : related to Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: lvcreate -l 100%FREE -n kubernetes vg-ephemeral mkfs -t ext4 /dev/vg-ephemeral/kubernetes mkdir -p /mnt/ephemeral/kubernetes <del> echo "/dev/vg-ephemeral/kubernetes  /mnt/ephemeral/kubernetes  ext4  noatime  0 0" >> /etc/fstab </del> <ins> echo "/dev/vg-ephemeral/kubernetes  /mnt/ephemeral/kubernetes  ext4  noatime,nofail  0 0" >> /etc/fstab </ins> mount /mnt/ephemeral/kubernetes move_kubelet="/mnt/ephemeral/kubernetes"

On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.