![]() If a CRI error occurs during the terminating phase after a pod is force deleted (API or static) then the housekeeping loop will not deliver updates to the pod worker which prevents the pod's state machine from progressing. The pod will remain in the terminating phase but no further attempts to terminate or cleanup will occur until the kubelet is restarted. The pod worker now maintains a store of the pods state that it is attempting to reconcile and uses that to resync unknown pods when SyncKnownPods() is invoked, so that failures in sync methods for unknown pods no longer hang forever. The pod worker's store tracks desired updates and the last update applied on podSyncStatuses. Each goroutine now synchronizes to acquire the next work item, context, and whether the pod can start. This synchronization moves the pending update to the stored last update, which will ensure third parties accessing pod worker state don't see updates before the pod worker begins synchronizing them. As a consequence, the update channel becomes a simple notifier (struct{}) so that SyncKnownPods can coordinate with the pod worker to create a synthetic pending update for unknown pods (i.e. no one besides the pod worker has data about those pods). Otherwise the pending update info would be hidden inside the channel. In order to properly track pending updates, we have to be very careful not to mix RunningPods (which are calculated from the container runtime and are missing all spec info) and config- sourced pods. Update the pod worker to avoid using ToAPIPod() and instead require the pod worker to directly use update.Options.Pod or update.Options.RunningPod for the correct methods. Add a new SyncTerminatingRuntimePod to prevent accidental invocations of runtime only pod data. Finally, fix SyncKnownPods to replay the last valid update for undesired pods which drives the pod state machine towards termination, and alter HandlePodCleanups to: - terminate runtime pods that aren't known to the pod worker - launch admitted pods that aren't known to the pod worker Any started pods receive a replay until they reach the finished state, and then are removed from the pod worker. When a desired pod is detected as not being in the worker, the usual cause is that the pod was deleted and recreated with the same UID (almost always a static pod since API UID reuse is statistically unlikely). This simplifies the previous restartable pod support. We are careful to filter for active pods (those not already terminal or those which have been previously rejected by admission). We also force a refresh of the runtime cache to ensure we don't see an older version of the state. Future changes will allow other components that need to view the pod worker's actual state (not the desired state the podManager represents) to retrieve that info from the pod worker. Several bugs in pod lifecycle have been undetectable at runtime because the kubelet does not clearly describe the number of pods in use. To better report, add the following metrics: kubelet_desired_pods: Pods the pod manager sees kubelet_active_pods: "Admitted" pods that gate new pods kubelet_mirror_pods: Mirror pods the kubelet is tracking kubelet_working_pods: Breakdown of pods from the last sync in each phase, orphaned state, and static or not kubelet_restarted_pods_total: A counter for pods that saw a CREATE before the previous pod with the same UID was finished kubelet_orphaned_runtime_pods_total: A counter for pods detected at runtime that were not known to the kubelet. Will be populated at Kubelet startup and should never be incremented after. Add a metric check to our e2e tests that verifies the values are captured correctly during a serial test, and then verify them in detail in unit tests. Adds 23 series to the kubelet /metrics endpoint. |
||
---|---|---|
.. | ||
boilerplate | ||
conformance | ||
e2e-internal | ||
gen-swagger-doc | ||
jenkins | ||
lib | ||
make-rules | ||
testdata | ||
tools | ||
verify-flags | ||
.descriptions_failures | ||
.import-aliases | ||
.spelling_failures | ||
benchmark-go.sh | ||
build-cross.sh | ||
build-go.sh | ||
cherry_pick_pull.sh | ||
dev-build-and-push.sh | ||
dev-build-and-up.sh | ||
dev-push-conformance.sh | ||
e2e-node-test.sh | ||
generate-docs.sh | ||
get-build.sh | ||
ginkgo-e2e.sh | ||
golangci.yaml | ||
grab-profiles.sh | ||
install-etcd.sh | ||
install-protoc.sh | ||
lint-dependencies.sh | ||
list-feature-tests.sh | ||
local-up-cluster.sh | ||
logcheck.conf | ||
module-graph.sh | ||
OWNERS | ||
pin-dependency.sh | ||
print-workspace-status.sh | ||
README.md | ||
run-in-gopath.sh | ||
run-prometheus-on-etcd-scrapes.sh | ||
serve-prom-scrapes.sh | ||
test-go.sh | ||
test-integration.sh | ||
unwanted-dependencies.json | ||
update-all.sh | ||
update-codegen.sh | ||
update-conformance-yaml.sh | ||
update-generated-api-compatibility-data.sh | ||
update-generated-docs.sh | ||
update-generated-proto-bindings-dockerized.sh | ||
update-generated-protobuf-dockerized.sh | ||
update-generated-stable-metrics.sh | ||
update-gofmt.sh | ||
update-import-aliases.sh | ||
update-internal-modules.sh | ||
update-kustomize.sh | ||
update-mocks.sh | ||
update-netparse-cve.sh | ||
update-openapi-spec.sh | ||
update-translations.sh | ||
update-vendor-licenses.sh | ||
update-vendor.sh | ||
update-yamlfmt.sh | ||
verify-all.sh | ||
verify-api-groups.sh | ||
verify-boilerplate.sh | ||
verify-cli-conventions.sh | ||
verify-codegen.sh | ||
verify-conformance-requirements.sh | ||
verify-conformance-yaml.sh | ||
verify-description.sh | ||
verify-e2e-test-ownership.sh | ||
verify-external-dependencies-version.sh | ||
verify-fieldname-docs.sh | ||
verify-flags-underscore.py | ||
verify-generated-docs.sh | ||
verify-generated-stable-metrics.sh | ||
verify-gofmt.sh | ||
verify-golangci-lint.sh | ||
verify-govet-levee.sh | ||
verify-govet.sh | ||
verify-import-aliases.sh | ||
verify-import-boss.sh | ||
verify-imports.sh | ||
verify-internal-modules.sh | ||
verify-licenses.sh | ||
verify-mocks.sh | ||
verify-netparse-cve.sh | ||
verify-no-vendor-cycles.sh | ||
verify-non-mutating-validation.sh | ||
verify-openapi-spec.sh | ||
verify-pkg-names.sh | ||
verify-prerelease-lifecycle-tags.sh | ||
verify-prometheus-imports.sh | ||
verify-publishing-bot.py | ||
verify-readonly-packages.sh | ||
verify-shellcheck.sh | ||
verify-spelling.sh | ||
verify-staging-meta-files.sh | ||
verify-test-code.sh | ||
verify-test-featuregates.sh | ||
verify-test-images.sh | ||
verify-typecheck-providerless.sh | ||
verify-typecheck.sh | ||
verify-vendor-licenses.sh | ||
verify-vendor.sh | ||
verify-yamlfmt.sh |
Kubernetes hack GuideLines
This document describes how you can use the scripts from hack
directory
and gives a brief introduction and explanation of these scripts.
Overview
The hack
directory contains many scripts that ensure continuous development of kubernetes,
enhance the robustness of the code, improve development efficiency, etc.
The explanations and descriptions of these scripts are helpful for contributors.
For details, refer to the following guidelines.
Key scripts
verify-all.sh
: This script is a vestigial redirection, Please do not add "real" logic. It is equivalent tomake verify
.update-all.sh
: This script is a vestigial redirection, Please do not add "real" logic. Thetrue
target of this makerule ishack/make-rules/update.sh
.It is equivalent tomake update
.
Attention
Note that all scripts must be run from the Kubernetes root directory.
We should run hack/verify-all.sh
before submitting a PR and if anything fails run hack/update-all.sh
.