├── .gitattributes ├── .gitignore ├── Makefile ├── README.md ├── contents ├── books │ └── kubernetes-guide-5.pdf ├── posts │ ├── 2015-03-00-Kubernetes-Gathering-Videos.md │ ├── 2015-03-00-Weekly-Kubernetes-Community-Hangout.md │ ├── 2015-03-00-Welcome-To-Kubernetes-Blog.md │ ├── 2015-04-00-Borg-Predecessor-To-Kubernetes.md │ ├── 2015-04-00-Kubernetes-Release-0150.md │ ├── 2015-04-00-Weekly-Kubernetes-Community-Hangout.md │ ├── 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md │ ├── 2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md │ ├── 2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md │ ├── 2015-05-00-Kubernetes-On-Openstack.md │ ├── 2015-05-00-Weekly-Kubernetes-Community-Hangout.md │ ├── 2015-06-00-Slides-Cluster-Management-With.md │ ├── 2015-07-00-Announcing-First-Kubernetes-Enterprise.md │ ├── 2015-08-00-Weekly-Kubernetes-Community-Hangout.md │ ├── 2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md │ ├── 2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md │ ├── 2016-01-00-Kubernetes-Community-Meeting-Notes.md │ ├── 2016-01-00-Simple-Leader-Election-With-Kubernetes.md │ ├── 2016-01-00-Why-Kubernetes-Doesnt-Use-Libnetwork.md │ ├── 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md │ ├── 2016-02-00-Kubernetes-Community-Meeting-Notes.md │ ├── 2016-02-00-State-Of-Container-World-January-2016.md │ ├── 2016-02-00-kubernetes-community-meeting-notes_23.md │ ├── 2016-04-00-Adding-Support-For-Kubernetes-In-Rancher.md │ ├── 2016-04-00-Kubernetes-Network-Policy-APIs.md │ ├── 2016-04-00-Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters.md │ ├── 2016-05-00-Coreosfest2016-Kubernetes-Community.md │ ├── 2016-07-00-Bringing-End-To-End-Kubernetes-Testing-To-Azure-2.md │ ├── 2016-07-00-Citrix-Netscaler-And-Kubernetes.md │ ├── 2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md │ ├── 2016-07-00-Oh-The-Places-You-Will-Go.md │ ├── 2016-07-00-stateful-applications-in-containers-kubernetes.md │ ├── 2016-08-00-Sig-Apps-Running-Apps-In-Kubernetes.md │ ├── 2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md │ ├── 2017-10-00-Five-Days-Of-Kubernetes-18.md │ ├── 2017-10-00-Kubernetes-Community-Steering-Committee-Election-Results.md │ ├── 2017-11-00-Autoscaling-In-Kubernetes.md │ ├── 2018-01-00-Kubernetes-V19-Beta-Windows-Support.md │ ├── 2018-03-00-Principles-Of-Container-App-Design.md │ ├── 2018-04-25-open-source-charts-2017.md │ ├── 2018-05-01-developing-on-kubernetes.md │ ├── 2018-05-30-say-hello-to-discuss-kubernetes.md │ ├── 2018-06-06-4-years-of-k8s.md │ ├── 2018-06-07-dynamic-ingress-kubernetes.md │ ├── 2018-06-28-Airflow-Kubernetes-Operator.md │ ├── 2018-07-09-IPVS-In-Cluster-Load-Balancing.md │ ├── 2018-07-10-coredns-ga.md │ ├── 2018-07-11-dynamic-kubelet-configuration.md │ ├── 2018-07-12-resizing-persistent-volumes-using-kubernetes.md │ ├── 2018-08-02-dynamically-expand-volume-csi.md │ ├── 2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md │ ├── 2018-10-01-health-checking-grpc.md │ ├── 2018-10-03-kubedirector.md │ ├── 2018-10-10-runtimeclass.md │ ├── 2018-10-11-topology-aware-volume-provisioning.md │ ├── 2018-10-15-steering-election-results.md │ ├── 2018-10-16-kubernetes-2018-north-american-contributor-summit.md │ ├── 2018-11-08-kubernetes-docs-update-i18n.md │ ├── 2018-12-05-new-contributor-shanghai.md │ ├── 2019-03-07-raw-block-volume-support-to-beta.md │ ├── 2019-03-28-PID-Limiting.md │ ├── 2019-04-26-latest-on-localization.md │ ├── 2019-05-14-expanding-our-contributor-workshops.md │ ├── 2019-06-12-contributor-summit-shanghai.md │ ├── 2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md │ ├── 2019-09-24-san-diego-contributor-summit.md │ ├── 2019-10-03-2019-Steering-Committee-Election-Results.md │ ├── 2019-10-10-contributor-summit-san-diego-schedule.md │ ├── 2019-10-29-2019-sig-docs-survey.md │ ├── 2019-11-05-kubernetes-with-microk8s.md │ ├── 2019-11-26-cloud-native-java-controller-sdk.md │ ├── 2019-12-09-kubernetes-1.17-release-announcement.md │ ├── 2020-01-15-Kubernetes-on-MIPS.md │ ├── 2020-03-25-kubernetes-1.18-release-announcement.md │ ├── 2020-06-15-better-docs-ux-with-docsy.md │ ├── 2020-09-03-warnings │ │ └── index.md │ ├── 2020-09-04-introducing-structured-logs.md │ ├── 2020-09-30-writing-crl-scheduler │ │ └── index.md │ ├── 2020-10-01-contributing-to-the-development-guide │ │ └── index.md │ ├── 2020-12-02-dockershim-faq.md │ ├── 2020-12-02-dont-panic-kubernetes-and-docker.md │ ├── 2020-12-08-kubernetes-release-1.20.md │ ├── 2020-12-10-Pod-Impersonation-and-Short-lived-Volumes-in-CSI-Drivers.md │ ├── 2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md │ ├── 2021-04-16-volume-health-monitoring-alpha.md │ ├── 2021-07-15-SIG-Usability-Spotlight.md │ ├── 2021-07-26-update-with-ingress-nginx.md │ ├── 2021-09-27-SIG-Node-Spotlight │ │ └── index.md │ ├── 2021-11-08-steering-committee-results-2021.md │ ├── 2021-12-08-dual-stack-networking-ga.md │ ├── 2021-12-10-csi-migration-status.md │ ├── 2021-12-16-StatefulSet-PVC-Auto-Deletion.md │ ├── 2021-12-17-security-profiles-operator-v0.4.0 │ │ └── index.md │ ├── 2022-01-07-kubernetes-is-moving-on-from-dockershim.md │ ├── 2022-01-10-meet-our-contributors-APAC-India-region-01.md │ ├── 2022-01-19-Securing-Admission-Controllers.md │ ├── 2022-02-07-sig-multicluster-spotlight │ │ └── index.md │ ├── 2022-02-16-sig-node-ci-subproject-celebrates │ │ └── index.md │ ├── 2022-02-17-updated-dockershim-faq.md │ ├── 2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md │ ├── 2022-03-31-ready-for-dockershim-removal.md │ ├── 2022-04-07-Kubernetes-1-24-removals-and-deprecations.md │ ├── 2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX │ │ └── index.md │ ├── 2022-04-29-kubernetes-1.23-release-interview.md │ ├── 2022-05-03-dockershim-historical-context.md │ ├── 2022-05-03-kubernetes-release-1.24.md │ ├── 2022-05-05-volume-expansion-ga.md │ ├── 2022-05-06-storage-capacity-GA │ │ └── index.md │ ├── 2022-05-13-grpc-probes-in-beta.md │ ├── 2022-05-16-volume-populators-beta.md │ ├── 2022-05-18-prevent-unauthorised-volume-mode-conversion.md │ ├── 2022-05-20-non-graceful-node-shutdown.md │ ├── 2022-05-23-service-ip-dynamic-and-static-allocation.md │ ├── 2022-05-25-contextual-logging │ │ └── index.md │ ├── 2022-05-27-maxunavailable-for-statefulset.md │ ├── 2022-06-01-annual-report-2021.md │ ├── 2022-07-13-gateway-api-in-beta.md │ ├── 2022-08-02-sig-docs-spotlight │ │ └── index.md │ ├── 2022-08-04-kubernetes-1.25-deprecations-and-removals.md │ ├── 2022-08-11-enhancing-kubernetes-one-kep-at-a-time │ │ └── index.md │ ├── 2022-08-15-meet-our-contributors-APAC-China-region-03.md │ ├── 2022-08-16-PSP-historical-context │ │ └── index.md │ ├── 2022-08-22-sig-storage-spotlight.md │ ├── 2022-08-23-kubernetes-1.25-blog.md │ ├── 2022-08-29-csi-inline-volumes-ga.md │ ├── 2022-08-31-cgroupv2-ga.md │ ├── 2022-09-02-cosi-kubernetes-object-storage-management.md │ ├── 2022-09-07-iptables-chains.md │ ├── 2022-09-12-Announcing-the-Auto-Refreshing-Official-CVE-Feed │ │ └── index.md │ ├── 2022-09-14-pod-has-network-condition.md │ ├── 2022-09-15-sig-apps-GA-1.25 │ │ └── index.md │ ├── 2022-10-03-add-userns-alpha │ │ └── index.md │ ├── 2022-10-04-introducing-kueue.md │ ├── 2022-10-18-kubernetes-1.26-deprecations-and-removals.md │ ├── 2022-12-05-forensic-container-checkpointing │ │ └── index.md │ ├── 2022-12-12-kubernetes-release-artifact-signing.md │ ├── 2022-12-15-dynamic-resource-allocation-alpha │ │ └── index.md │ ├── 2022-12-16-non-graceful-node-shutdown-to-beta.md │ ├── 2022-12-23-fsgroup-on-mount.md │ ├── 2022-12-26-pod-scheduling-readiness.md │ ├── 2022-12-27-cpumanager-goes-GA.md │ ├── 2023-01-02-cross-namespace-data-sources-alpha.md │ ├── 2023-01-05-retroactive-default-storage-class.md │ ├── 2023-01-06-unhealthy-pod-eviction-policy-for-pdb.md │ ├── 2023-02-03-sig-instrumentation-spotlight.md │ ├── 2023-02-06-k8s-gcr-io-freeze-announcement.md │ ├── 2023-03-01-introducing-kwok │ │ └── index.md │ ├── 2023-03-10-forensic-container-analysis │ │ └── index.md │ ├── 2023-03-10-image-registry-change.md │ ├── 2023-03-17-kubernetes-1.27-deprecations-and-removals.md │ ├── 2023-04-06-keeping-kubernetes-secure-with-updated-go-versions.md │ ├── 2023-04-17-topology-spread-features.md │ ├── 2023-04-20-read-write-once-pod-access-mode-beta.md │ ├── 2023-04-21-node-log-query-alpha.md │ ├── 2023-04-24-openapi-v3-field-validation-ga.md │ ├── 2023-04-28-statefulset-migration.md │ ├── 2023-05-02-hpa-container-resource-metric.md │ ├── 2023-05-04-statefulset-autodelete.md │ ├── 2023-05-08-volume-group-snapshot-alpha.md │ ├── 2023-05-09-Safer-More-Performant-Pruning-in-kubectl-apply.md │ ├── 2023-05-11-nodeport-dynamic-and-static-allocation.md │ ├── 2023-05-12-in-place-pod-resize │ │ └── index.md │ ├── 2023-05-15-kubernetes-1-27-updates-on-speeding-up-pod-startup.md │ ├── 2023-05-16-kmsv2-beta.md │ ├── 2023-05-18-seccomp-profiles-edge.md │ ├── 2023-05-24-oci-security-profiles.md │ ├── 2023-06-09-dl-adopt-cdn.md │ ├── 2023-06-29-container-image-signature-verification │ │ └── index.md │ ├── 2023-07-06-confidential-kubernetes.md │ ├── 2023-07-20-sig-cli-spotlight.md │ └── free-katacoda-kubernetes-tutorials-are-shutting-down.md └── website │ ├── _index.md │ ├── concepts │ ├── _index.md │ ├── architecture │ │ ├── _index.md │ │ ├── cgroups.md │ │ ├── cloud-controller.md │ │ ├── control-plane-node-communication.md │ │ ├── controller.md │ │ ├── cri.md │ │ ├── garbage-collection.md │ │ ├── leases.md │ │ └── nodes.md │ ├── cluster-administration │ │ ├── _index.md │ │ ├── addons.md │ │ ├── certificates.md │ │ ├── flow-control.md │ │ ├── logging.md │ │ ├── manage-deployment.md │ │ ├── networking.md │ │ ├── proxies.md │ │ ├── system-logs.md │ │ ├── system-metrics.md │ │ └── system-traces.md │ ├── configuration │ │ ├── _index.md │ │ ├── configmap.md │ │ ├── manage-resources-containers.md │ │ ├── organize-cluster-access-kubeconfig.md │ │ ├── overview.md │ │ ├── secret.md │ │ └── windows-resource-management.md │ ├── containers │ │ ├── _index.md │ │ ├── container-environment.md │ │ ├── container-lifecycle-hooks.md │ │ ├── images.md │ │ └── runtime-class.md │ ├── extend-kubernetes │ │ ├── _index.md │ │ ├── api-extension │ │ │ ├── _index.md │ │ │ ├── apiserver-aggregation.md │ │ │ └── custom-resources.md │ │ ├── compute-storage-net │ │ │ ├── _index.md │ │ │ ├── device-plugins.md │ │ │ └── network-plugins.md │ │ └── operator.md │ ├── overview │ │ ├── _index.md │ │ ├── components.md │ │ ├── kubernetes-api.md │ │ └── working-with-objects │ │ │ ├── _index.md │ │ │ ├── annotations.md │ │ │ ├── common-labels.md │ │ │ ├── field-selectors.md │ │ │ ├── finalizers.md │ │ │ ├── labels.md │ │ │ ├── names.md │ │ │ ├── namespaces.md │ │ │ ├── object-management.md │ │ │ └── owners-dependents.md │ ├── policy │ │ ├── _index.md │ │ ├── limit-range.md │ │ ├── node-resource-managers.md │ │ ├── pid-limiting.md │ │ └── resource-quotas.md │ ├── scheduling-eviction │ │ ├── _index.md │ │ ├── api-eviction.md │ │ ├── assign-pod-node.md │ │ ├── dynamic-resource-allocation.md │ │ ├── kube-scheduler.md │ │ ├── node-pressure-eviction.md │ │ ├── pod-overhead.md │ │ ├── pod-priority-preemption.md │ │ ├── pod-scheduling-readiness.md │ │ ├── resource-bin-packing.md │ │ ├── scheduler-perf-tuning.md │ │ ├── scheduling-framework.md │ │ ├── taint-and-toleration.md │ │ └── topology-spread-constraints.md │ ├── security │ │ ├── _index.md │ │ ├── api-server-bypass-risks.md │ │ ├── controlling-access.md │ │ ├── multi-tenancy.md │ │ ├── overview.md │ │ ├── pod-security-admission.md │ │ ├── pod-security-policy.md │ │ ├── pod-security-standards.md │ │ ├── rbac-good-practices.md │ │ ├── secrets-good-practices.md │ │ ├── security-checklist.md │ │ └── windows-security.md │ ├── services-networking │ │ ├── _index.md │ │ ├── cluster-ip-allocation.md │ │ ├── dns-pod-service.md │ │ ├── dual-stack.md │ │ ├── endpoint-slices.md │ │ ├── ingress-controllers.md │ │ ├── ingress.md │ │ ├── network-policies.md │ │ ├── service-topology.md │ │ ├── service-traffic-policy.md │ │ ├── service.md │ │ ├── topology-aware-routing.md │ │ └── windows-networking.md │ ├── storage │ │ ├── _index.md │ │ ├── dynamic-provisioning.md │ │ ├── ephemeral-volumes.md │ │ ├── persistent-volumes.md │ │ ├── projected-volumes.md │ │ ├── storage-capacity.md │ │ ├── storage-classes.md │ │ ├── storage-limits.md │ │ ├── volume-health-monitoring.md │ │ ├── volume-pvc-datasource.md │ │ ├── volume-snapshot-classes.md │ │ ├── volume-snapshots.md │ │ ├── volumes.md │ │ └── windows-storage.md │ ├── windows │ │ ├── _index.md │ │ ├── intro.md │ │ └── user-guide.md │ └── workloads │ │ ├── _index.md │ │ ├── controllers │ │ ├── _index.md │ │ ├── cron-jobs.md │ │ ├── daemonset.md │ │ ├── deployment.md │ │ ├── job.md │ │ ├── replicaset.md │ │ ├── replicationcontroller.md │ │ ├── statefulset.md │ │ └── ttlafterfinished.md │ │ └── pods │ │ ├── _index.md │ │ ├── disruptions.md │ │ ├── downward-api.md │ │ ├── ephemeral-containers.md │ │ ├── init-containers.md │ │ ├── pod-lifecycle.md │ │ ├── pod-qos.md │ │ └── user-namespaces.md │ ├── contribute │ ├── _index.md │ ├── advanced.md │ ├── analytics.md │ ├── generate-ref-docs │ │ ├── _index.md │ │ ├── contribute-upstream.md │ │ ├── kubectl.md │ │ ├── kubernetes-api.md │ │ ├── kubernetes-components.md │ │ ├── prerequisites-ref-docs.md │ │ └── quickstart.md │ ├── localization.md │ ├── localization_zh.md │ ├── new-content │ │ ├── _index.md │ │ ├── blogs-case-studies.md │ │ ├── new-features.md │ │ └── open-a-pr.md │ ├── participate │ │ ├── _index.md │ │ ├── pr-wranglers.md │ │ └── roles-and-responsibilities.md │ ├── review │ │ ├── _index.md │ │ ├── for-approvers.md │ │ └── reviewing-prs.md │ ├── style │ │ ├── _index.md │ │ ├── content-guide.md │ │ ├── content-organization.md │ │ ├── diagram-guide.md │ │ ├── hugo-shortcodes │ │ │ ├── example1.md │ │ │ ├── example2.md │ │ │ └── index.md │ │ ├── page-content-types.md │ │ ├── style-guide.md │ │ └── write-new-topic.md │ └── suggesting-improvements.md │ ├── doc-contributor-tools │ └── linkchecker │ │ └── README.md │ ├── home │ ├── _index.md │ └── supported-doc-versions.md │ ├── reference │ ├── _index.md │ ├── access-authn-authz │ │ ├── _index.md │ │ ├── abac.md │ │ ├── admission-controllers.md │ │ ├── authentication.md │ │ ├── authorization.md │ │ ├── bootstrap-tokens.md │ │ ├── certificate-signing-requests.md │ │ ├── extensible-admission-controllers.md │ │ ├── kubelet-authn-authz.md │ │ ├── kubelet-tls-bootstrapping.md │ │ ├── node.md │ │ ├── psp-to-pod-security-standards.md │ │ ├── rbac.md │ │ ├── service-accounts-admin.md │ │ ├── validating-admission-policy.md │ │ └── webhook.md │ ├── command-line-tools-reference │ │ ├── _index.md │ │ ├── feature-gates-removed.md │ │ ├── feature-gates.md │ │ ├── kube-apiserver.md │ │ ├── kube-controller-manager.md │ │ ├── kube-proxy.md │ │ ├── kube-scheduler.md │ │ └── kubelet.md │ ├── config-api │ │ ├── _index.md │ │ ├── apiserver-audit.v1.md │ │ ├── apiserver-config.v1.md │ │ ├── apiserver-config.v1alpha1.md │ │ ├── apiserver-config.v1beta1.md │ │ ├── apiserver-encryption.v1.md │ │ ├── apiserver-eventratelimit.v1alpha1.md │ │ ├── apiserver-webhookadmission.v1.md │ │ ├── client-authentication.v1.md │ │ ├── client-authentication.v1beta1.md │ │ ├── imagepolicy.v1alpha1.md │ │ ├── kube-proxy-config.v1alpha1.md │ │ ├── kube-scheduler-config.v1.md │ │ ├── kube-scheduler-config.v1beta2.md │ │ ├── kube-scheduler-config.v1beta3.md │ │ ├── kubeadm-config.v1beta3.md │ │ ├── kubelet-config.v1alpha1.md │ │ ├── kubelet-config.v1beta1.md │ │ ├── kubelet-credentialprovider.v1.md │ │ ├── kubelet-credentialprovider.v1alpha1.md │ │ └── kubelet-credentialprovider.v1beta1.md │ ├── glossary │ │ ├── addons.md │ │ ├── admission-controller.md │ │ ├── affinity.md │ │ ├── aggregation-layer.md │ │ ├── annotation.md │ │ ├── api-eviction.md │ │ ├── api-group.md │ │ ├── app-container.md │ │ ├── application-architect.md │ │ ├── application-developer.md │ │ ├── applications.md │ │ ├── approver.md │ │ ├── cadvisor.md │ │ ├── certificate.md │ │ ├── cgroup.md │ │ ├── cidr.md │ │ ├── cla.md │ │ ├── cloud-controller-manager.md │ │ ├── cloud-provider.md │ │ ├── cluster-architect.md │ │ ├── cluster-infrastructure.md │ │ ├── cluster-operations.md │ │ ├── cluster-operator.md │ │ ├── cluster.md │ │ ├── cncf.md │ │ ├── cni.md │ │ ├── code-contributor.md │ │ ├── configmap.md │ │ ├── container-env-variables.md │ │ ├── container-lifecycle-hooks.md │ │ ├── container-runtime-interface.md │ │ ├── container-runtime.md │ │ ├── container.md │ │ ├── containerd.md │ │ ├── contributor.md │ │ ├── control-plane.md │ │ ├── controller.md │ │ ├── cri-o.md │ │ ├── cri.md │ │ ├── cronjob.md │ │ ├── csi.md │ │ ├── customresourcedefinition.md │ │ ├── daemonset.md │ │ ├── data-plane.md │ │ ├── deployment.md │ │ ├── developer.md │ │ ├── device-plugin.md │ │ ├── disruption.md │ │ ├── docker.md │ │ ├── dockershim.md │ │ ├── downstream.md │ │ ├── downward-api.md │ │ ├── dynamic-volume-provisioning.md │ │ ├── endpoint-slice.md │ │ ├── endpoint.md │ │ ├── ephemeral-container.md │ │ ├── etcd.md │ │ ├── event.md │ │ ├── eviction.md │ │ ├── extensions.md │ │ ├── feature-gates.md │ │ ├── finalizer.md │ │ ├── flexvolume.md │ │ ├── garbage-collection.md │ │ ├── helm-chart.md │ │ ├── horizontal-pod-autoscaler.md │ │ ├── host-aliases.md │ │ ├── image.md │ │ ├── index.md │ │ ├── ingress.md │ │ ├── init-container.md │ │ ├── istio.md │ │ ├── job.md │ │ ├── jwt.md │ │ ├── kops.md │ │ ├── kube-apiserver.md │ │ ├── kube-controller-manager.md │ │ ├── kube-proxy.md │ │ ├── kube-scheduler.md │ │ ├── kubeadm.md │ │ ├── kubectl.md │ │ ├── kubelet.md │ │ ├── kubernetes-api.md │ │ ├── label.md │ │ ├── limitrange.md │ │ ├── logging.md │ │ ├── managed-service.md │ │ ├── manifest.md │ │ ├── master.md │ │ ├── member.md │ │ ├── minikube.md │ │ ├── mirror-pod.md │ │ ├── name.md │ │ ├── namespace.md │ │ ├── network-policy.md │ │ ├── node-pressure-eviction.md │ │ ├── node.md │ │ ├── object.md │ │ ├── operator-pattern.md │ │ ├── persistent-volume-claim.md │ │ ├── persistent-volume.md │ │ ├── platform-developer.md │ │ ├── pod-disruption-budget.md │ │ ├── pod-disruption.md │ │ ├── pod-lifecycle.md │ │ ├── pod-priority.md │ │ ├── pod-security-policy.md │ │ ├── pod.md │ │ ├── preemption.md │ │ ├── proxy.md │ │ ├── qos-class.md │ │ ├── quantity.md │ │ ├── rbac.md │ │ ├── replica-set.md │ │ ├── replication-controller.md │ │ ├── resource-quota.md │ │ ├── reviewer.md │ │ ├── secret.md │ │ ├── security-context.md │ │ ├── selector.md │ │ ├── service-account.md │ │ ├── service-catalog.md │ │ ├── service.md │ │ ├── shuffle-sharding.md │ │ ├── sig.md │ │ ├── statefulset.md │ │ ├── static-pod.md │ │ ├── storage-class.md │ │ ├── sysctl.md │ │ ├── taint.md │ │ ├── toleration.md │ │ ├── uid.md │ │ ├── upstream.md │ │ ├── userns.md │ │ ├── volume-plugin.md │ │ ├── volume.md │ │ ├── wg.md │ │ └── workload.md │ ├── instrumentation │ │ ├── _index.md │ │ ├── cri-pod-container-metrics.md │ │ ├── node-metrics.md │ │ └── slis.md │ ├── issues-security │ │ ├── _index.md │ │ ├── issues.md │ │ ├── official-cve-feed.md │ │ └── security.md │ ├── kubectl │ │ ├── _index.md │ │ ├── cheatsheet.md │ │ ├── conventions.md │ │ ├── docker-cli-to-kubectl.md │ │ ├── jsonpath.md │ │ ├── kubectl-cmds.md │ │ └── kubectl.md │ ├── kubernetes-api │ │ ├── _index.md │ │ ├── authentication-resources │ │ │ ├── _index.md │ │ │ ├── certificate-signing-request-v1.md │ │ │ ├── self-subject-review-v1beta1.md │ │ │ ├── service-account-v1.md │ │ │ ├── token-request-v1.md │ │ │ └── token-review-v1.md │ │ ├── authorization-resources │ │ │ ├── _index.md │ │ │ ├── cluster-role-binding-v1.md │ │ │ ├── cluster-role-v1.md │ │ │ ├── local-subject-access-review-v1.md │ │ │ ├── role-binding-v1.md │ │ │ ├── role-v1.md │ │ │ ├── self-subject-access-review-v1.md │ │ │ ├── self-subject-review-v1alpha1.md │ │ │ ├── self-subject-rules-review-v1.md │ │ │ └── subject-access-review-v1.md │ │ ├── cluster-resources │ │ │ ├── _index.md │ │ │ ├── api-service-v1.md │ │ │ ├── binding-v1.md │ │ │ ├── cluster-cidr-v1alpha1.md │ │ │ ├── component-status-v1.md │ │ │ ├── event-v1.md │ │ │ ├── flow-schema-v1beta3.md │ │ │ ├── lease-v1.md │ │ │ ├── namespace-v1.md │ │ │ ├── node-v1.md │ │ │ ├── priority-level-configuration-v1beta3.md │ │ │ └── runtime-class-v1.md │ │ ├── common-definitions │ │ │ ├── _index.md │ │ │ ├── delete-options.md │ │ │ ├── label-selector.md │ │ │ ├── list-meta.md │ │ │ ├── local-object-reference.md │ │ │ ├── node-selector-requirement.md │ │ │ ├── object-field-selector.md │ │ │ ├── object-meta.md │ │ │ ├── object-reference.md │ │ │ ├── patch.md │ │ │ ├── quantity.md │ │ │ ├── resource-field-selector.md │ │ │ ├── status.md │ │ │ └── typed-local-object-reference.md │ │ ├── common-parameters │ │ │ └── common-parameters.md │ │ ├── config-and-storage-resources │ │ │ ├── _index.md │ │ │ ├── config-map-v1.md │ │ │ ├── csi-driver-v1.md │ │ │ ├── csi-node-v1.md │ │ │ ├── csi-storage-capacity-v1.md │ │ │ ├── persistent-volume-claim-v1.md │ │ │ ├── persistent-volume-v1.md │ │ │ ├── secret-v1.md │ │ │ ├── storage-class-v1.md │ │ │ ├── volume-attachment-v1.md │ │ │ └── volume.md │ │ ├── extend-resources │ │ │ ├── _index.md │ │ │ ├── custom-resource-definition-v1.md │ │ │ ├── mutating-webhook-configuration-v1.md │ │ │ └── validating-webhook-configuration-v1.md │ │ ├── other-resources │ │ │ ├── _index.md │ │ │ └── validating-admission-policy-binding-list-v1alpha1.md │ │ ├── policy-resources │ │ │ ├── _index.md │ │ │ ├── limit-range-v1.md │ │ │ ├── network-policy-v1.md │ │ │ ├── pod-disruption-budget-v1.md │ │ │ └── resource-quota-v1.md │ │ ├── service-resources │ │ │ ├── _index.md │ │ │ ├── endpoint-slice-v1.md │ │ │ ├── endpoints-v1.md │ │ │ ├── ingress-class-v1.md │ │ │ ├── ingress-v1.md │ │ │ └── service-v1.md │ │ └── workload-resources │ │ │ ├── _index.md │ │ │ ├── controller-revision-v1.md │ │ │ ├── cron-job-v1.md │ │ │ ├── daemon-set-v1.md │ │ │ ├── deployment-v1.md │ │ │ ├── horizontal-pod-autoscaler-v1.md │ │ │ ├── horizontal-pod-autoscaler-v2.md │ │ │ ├── job-v1.md │ │ │ ├── pod-scheduling-context-v1alpha2.md │ │ │ ├── pod-template-v1.md │ │ │ ├── pod-v1.md │ │ │ ├── priority-class-v1.md │ │ │ ├── replica-set-v1.md │ │ │ ├── replication-controller-v1.md │ │ │ ├── resource-claim-template-v1alpha2.md │ │ │ ├── resource-claim-v1alpha2.md │ │ │ ├── resource-class-v1alpha2.md │ │ │ └── stateful-set-v1.md │ ├── labels-annotations-taints │ │ ├── _index.md │ │ └── audit-annotations.md │ ├── networking │ │ ├── _index.md │ │ ├── ports-and-protocols.md │ │ ├── service-protocols.md │ │ └── virtual-ips.md │ ├── node │ │ ├── _index.md │ │ ├── device-plugin-api-versions.md │ │ ├── kubelet-checkpoint-api.md │ │ └── topics-on-dockershim-and-cri-compatible-runtimes.md │ ├── scheduling │ │ ├── _index.md │ │ ├── config.md │ │ └── policies.md │ ├── setup-tools │ │ ├── _index.md │ │ └── kubeadm │ │ │ ├── _index.md │ │ │ ├── generated │ │ │ ├── README.md │ │ │ ├── _index.md │ │ │ ├── kubeadm.md │ │ │ ├── kubeadm_certs.md │ │ │ ├── kubeadm_certs_certificate-key.md │ │ │ ├── kubeadm_certs_check-expiration.md │ │ │ ├── kubeadm_certs_generate-csr.md │ │ │ ├── kubeadm_certs_renew.md │ │ │ ├── kubeadm_certs_renew_admin.conf.md │ │ │ ├── kubeadm_certs_renew_all.md │ │ │ ├── kubeadm_certs_renew_apiserver-etcd-client.md │ │ │ ├── kubeadm_certs_renew_apiserver-kubelet-client.md │ │ │ ├── kubeadm_certs_renew_apiserver.md │ │ │ ├── kubeadm_certs_renew_controller-manager.conf.md │ │ │ ├── kubeadm_certs_renew_etcd-healthcheck-client.md │ │ │ ├── kubeadm_certs_renew_etcd-peer.md │ │ │ ├── kubeadm_certs_renew_etcd-server.md │ │ │ ├── kubeadm_certs_renew_front-proxy-client.md │ │ │ ├── kubeadm_certs_renew_scheduler.conf.md │ │ │ ├── kubeadm_completion.md │ │ │ ├── kubeadm_config.md │ │ │ ├── kubeadm_config_images.md │ │ │ ├── kubeadm_config_images_list.md │ │ │ ├── kubeadm_config_images_pull.md │ │ │ ├── kubeadm_config_migrate.md │ │ │ ├── kubeadm_config_print.md │ │ │ ├── kubeadm_config_print_init-defaults.md │ │ │ ├── kubeadm_config_print_join-defaults.md │ │ │ ├── kubeadm_init.md │ │ │ ├── kubeadm_init_phase.md │ │ │ ├── kubeadm_init_phase_addon.md │ │ │ ├── kubeadm_init_phase_addon_all.md │ │ │ ├── kubeadm_init_phase_addon_coredns.md │ │ │ ├── kubeadm_init_phase_addon_kube-proxy.md │ │ │ ├── kubeadm_init_phase_bootstrap-token.md │ │ │ ├── kubeadm_init_phase_certs.md │ │ │ ├── kubeadm_init_phase_certs_all.md │ │ │ ├── kubeadm_init_phase_certs_apiserver-etcd-client.md │ │ │ ├── kubeadm_init_phase_certs_apiserver-kubelet-client.md │ │ │ ├── kubeadm_init_phase_certs_apiserver.md │ │ │ ├── kubeadm_init_phase_certs_ca.md │ │ │ ├── kubeadm_init_phase_certs_etcd-ca.md │ │ │ ├── kubeadm_init_phase_certs_etcd-healthcheck-client.md │ │ │ ├── kubeadm_init_phase_certs_etcd-peer.md │ │ │ ├── kubeadm_init_phase_certs_etcd-server.md │ │ │ ├── kubeadm_init_phase_certs_front-proxy-ca.md │ │ │ ├── kubeadm_init_phase_certs_front-proxy-client.md │ │ │ ├── kubeadm_init_phase_certs_sa.md │ │ │ ├── kubeadm_init_phase_control-plane.md │ │ │ ├── kubeadm_init_phase_control-plane_all.md │ │ │ ├── kubeadm_init_phase_control-plane_apiserver.md │ │ │ ├── kubeadm_init_phase_control-plane_controller-manager.md │ │ │ ├── kubeadm_init_phase_control-plane_scheduler.md │ │ │ ├── kubeadm_init_phase_etcd.md │ │ │ ├── kubeadm_init_phase_etcd_local.md │ │ │ ├── kubeadm_init_phase_kubeconfig.md │ │ │ ├── kubeadm_init_phase_kubeconfig_admin.md │ │ │ ├── kubeadm_init_phase_kubeconfig_all.md │ │ │ ├── kubeadm_init_phase_kubeconfig_controller-manager.md │ │ │ ├── kubeadm_init_phase_kubeconfig_kubelet.md │ │ │ ├── kubeadm_init_phase_kubeconfig_scheduler.md │ │ │ ├── kubeadm_init_phase_kubelet-finalize.md │ │ │ ├── kubeadm_init_phase_kubelet-finalize_all.md │ │ │ ├── kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md │ │ │ ├── kubeadm_init_phase_kubelet-start.md │ │ │ ├── kubeadm_init_phase_mark-control-plane.md │ │ │ ├── kubeadm_init_phase_preflight.md │ │ │ ├── kubeadm_init_phase_show-join-command.md │ │ │ ├── kubeadm_init_phase_upload-certs.md │ │ │ ├── kubeadm_init_phase_upload-config.md │ │ │ ├── kubeadm_init_phase_upload-config_all.md │ │ │ ├── kubeadm_init_phase_upload-config_kubeadm.md │ │ │ ├── kubeadm_init_phase_upload-config_kubelet.md │ │ │ ├── kubeadm_join.md │ │ │ ├── kubeadm_join_phase.md │ │ │ ├── kubeadm_join_phase_control-plane-join.md │ │ │ ├── kubeadm_join_phase_control-plane-join_all.md │ │ │ ├── kubeadm_join_phase_control-plane-join_etcd.md │ │ │ ├── kubeadm_join_phase_control-plane-join_mark-control-plane.md │ │ │ ├── kubeadm_join_phase_control-plane-join_update-status.md │ │ │ ├── kubeadm_join_phase_control-plane-prepare.md │ │ │ ├── kubeadm_join_phase_control-plane-prepare_all.md │ │ │ ├── kubeadm_join_phase_control-plane-prepare_certs.md │ │ │ ├── kubeadm_join_phase_control-plane-prepare_control-plane.md │ │ │ ├── kubeadm_join_phase_control-plane-prepare_download-certs.md │ │ │ ├── kubeadm_join_phase_control-plane-prepare_kubeconfig.md │ │ │ ├── kubeadm_join_phase_kubelet-start.md │ │ │ ├── kubeadm_join_phase_preflight.md │ │ │ ├── kubeadm_kubeconfig.md │ │ │ ├── kubeadm_kubeconfig_user.md │ │ │ ├── kubeadm_reset.md │ │ │ ├── kubeadm_reset_phase.md │ │ │ ├── kubeadm_reset_phase_cleanup-node.md │ │ │ ├── kubeadm_reset_phase_preflight.md │ │ │ ├── kubeadm_reset_phase_remove-etcd-member.md │ │ │ ├── kubeadm_token.md │ │ │ ├── kubeadm_token_create.md │ │ │ ├── kubeadm_token_delete.md │ │ │ ├── kubeadm_token_generate.md │ │ │ ├── kubeadm_token_list.md │ │ │ ├── kubeadm_upgrade.md │ │ │ ├── kubeadm_upgrade_apply.md │ │ │ ├── kubeadm_upgrade_diff.md │ │ │ ├── kubeadm_upgrade_node.md │ │ │ ├── kubeadm_upgrade_node_phase.md │ │ │ ├── kubeadm_upgrade_node_phase_control-plane.md │ │ │ ├── kubeadm_upgrade_node_phase_kubelet-config.md │ │ │ ├── kubeadm_upgrade_node_phase_preflight.md │ │ │ ├── kubeadm_upgrade_plan.md │ │ │ └── kubeadm_version.md │ │ │ ├── implementation-details.md │ │ │ ├── kubeadm-alpha.md │ │ │ ├── kubeadm-certs.md │ │ │ ├── kubeadm-config.md │ │ │ ├── kubeadm-init-phase.md │ │ │ ├── kubeadm-init.md │ │ │ ├── kubeadm-join-phase.md │ │ │ ├── kubeadm-join.md │ │ │ ├── kubeadm-kubeconfig.md │ │ │ ├── kubeadm-reset-phase.md │ │ │ ├── kubeadm-reset.md │ │ │ ├── kubeadm-token.md │ │ │ ├── kubeadm-upgrade-phase.md │ │ │ ├── kubeadm-upgrade.md │ │ │ └── kubeadm-version.md │ ├── tools │ │ ├── _index.md │ │ └── map-crictl-dockercli.md │ └── using-api │ │ ├── _index.md │ │ ├── api-concepts.md │ │ ├── cel.md │ │ ├── client-libraries.md │ │ ├── deprecation-guide.md │ │ ├── deprecation-policy.md │ │ ├── health-checks.md │ │ └── server-side-apply.md │ ├── setup │ ├── _index.md │ ├── best-practices │ │ ├── _index.md │ │ ├── certificates.md │ │ ├── cluster-large.md │ │ ├── enforcing-pod-security-standards.md │ │ ├── multiple-zones.md │ │ └── node-conformance.md │ ├── learning-environment │ │ └── _index.md │ └── production-environment │ │ ├── _index.md │ │ ├── container-runtimes.md │ │ ├── tools │ │ ├── _index.md │ │ ├── kops.md │ │ ├── kubeadm │ │ │ ├── _index.md │ │ │ ├── control-plane-flags.md │ │ │ ├── create-cluster-kubeadm.md │ │ │ ├── dual-stack-support.md │ │ │ ├── ha-topology.md │ │ │ ├── high-availability.md │ │ │ ├── install-kubeadm.md │ │ │ ├── kubelet-integration.md │ │ │ ├── setup-ha-etcd-with-kubeadm.md │ │ │ └── troubleshooting-kubeadm.md │ │ └── kubespray.md │ │ └── turnkey-solutions.md │ ├── tasks │ ├── _index.md │ ├── access-application-cluster │ │ ├── _index.md │ │ ├── access-cluster-services.md │ │ ├── access-cluster.md │ │ ├── communicate-containers-same-pod-shared-volume.md │ │ ├── configure-access-multiple-clusters.md │ │ ├── configure-dns-cluster.md │ │ ├── connecting-frontend-backend.md │ │ ├── create-external-load-balancer.md │ │ ├── ingress-minikube.md │ │ ├── list-all-running-container-images.md │ │ ├── port-forward-access-application-cluster.md │ │ ├── service-access-application-cluster.md │ │ └── web-ui-dashboard.md │ ├── administer-cluster │ │ ├── _index.md │ │ ├── access-cluster-api.md │ │ ├── certificates.md │ │ ├── change-default-storage-class.md │ │ ├── change-pv-reclaim-policy.md │ │ ├── cluster-upgrade.md │ │ ├── configure-upgrade-etcd.md │ │ ├── controller-manager-leader-migration.md │ │ ├── coredns.md │ │ ├── cpu-management-policies.md │ │ ├── declare-network-policy.md │ │ ├── developing-cloud-controller-manager.md │ │ ├── dns-custom-nameservers.md │ │ ├── dns-debugging-resolution.md │ │ ├── dns-horizontal-autoscaling.md │ │ ├── enable-disable-api.md │ │ ├── encrypt-data.md │ │ ├── extended-resource-node.md │ │ ├── guaranteed-scheduling-critical-addon-pods.md │ │ ├── ip-masq-agent.md │ │ ├── kms-provider.md │ │ ├── kubeadm │ │ │ ├── _index.md │ │ │ ├── configure-cgroup-driver.md │ │ │ ├── kubeadm-certs.md │ │ │ ├── kubeadm-reconfigure.md │ │ │ ├── kubeadm-upgrade.md │ │ │ ├── upgrading-linux-nodes.md │ │ │ └── upgrading-windows-nodes.md │ │ ├── kubelet-config-file.md │ │ ├── kubelet-credential-provider.md │ │ ├── kubelet-in-userns.md │ │ ├── limit-storage-consumption.md │ │ ├── manage-resources │ │ │ ├── _index.md │ │ │ ├── cpu-constraint-namespace.md │ │ │ ├── cpu-default-namespace.md │ │ │ ├── memory-constraint-namespace.md │ │ │ ├── memory-default-namespace.md │ │ │ ├── quota-memory-cpu-namespace.md │ │ │ └── quota-pod-namespace.md │ │ ├── memory-manager.md │ │ ├── migrating-from-dockershim │ │ │ ├── _index.md │ │ │ ├── change-runtime-containerd.md │ │ │ ├── check-if-dockershim-removal-affects-you.md │ │ │ ├── find-out-runtime-you-use.md │ │ │ ├── migrate-dockershim-dockerd.md │ │ │ ├── migrating-telemetry-and-security-agents.md │ │ │ └── troubleshooting-cni-plugin-related-errors.md │ │ ├── namespaces-walkthrough.md │ │ ├── namespaces.md │ │ ├── network-policy-provider │ │ │ ├── _index.md │ │ │ ├── antrea-network-policy.md │ │ │ ├── calico-network-policy.md │ │ │ ├── cilium-network-policy.md │ │ │ ├── kube-router-network-policy.md │ │ │ ├── romana-network-policy.md │ │ │ └── weave-network-policy.md │ │ ├── nodelocaldns.md │ │ ├── quota-api-object.md │ │ ├── reserve-compute-resources.md │ │ ├── running-cloud-controller.md │ │ ├── safely-drain-node.md │ │ ├── securing-a-cluster.md │ │ ├── switch-to-evented-pleg.md │ │ ├── sysctl-cluster.md │ │ ├── topology-manager.md │ │ ├── use-cascading-deletion.md │ │ └── verify-signed-artifacts.md │ ├── configmap-secret │ │ ├── _index.md │ │ ├── managing-secret-using-config-file.md │ │ ├── managing-secret-using-kubectl.md │ │ └── managing-secret-using-kustomize.md │ ├── configure-pod-container │ │ ├── _index.md │ │ ├── assign-cpu-resource.md │ │ ├── assign-memory-resource.md │ │ ├── assign-pods-nodes-using-node-affinity.md │ │ ├── assign-pods-nodes.md │ │ ├── attach-handler-lifecycle-event.md │ │ ├── configure-gmsa.md │ │ ├── configure-liveness-readiness-startup-probes.md │ │ ├── configure-persistent-volume-storage.md │ │ ├── configure-pod-configmap.md │ │ ├── configure-pod-initialization.md │ │ ├── configure-projected-volume-storage.md │ │ ├── configure-runasusername.md │ │ ├── configure-service-account.md │ │ ├── configure-volume-storage.md │ │ ├── create-hostprocess-pod.md │ │ ├── enforce-standards-admission-controller.md │ │ ├── enforce-standards-namespace-labels.md │ │ ├── extended-resource.md │ │ ├── migrate-from-psp.md │ │ ├── pull-image-private-registry.md │ │ ├── quality-service-pod.md │ │ ├── resize-container-resources.md │ │ ├── security-context.md │ │ ├── share-process-namespace.md │ │ ├── static-pod.md │ │ ├── translate-compose-kubernetes.md │ │ └── user-namespaces.md │ ├── debug │ │ ├── _index.md │ │ ├── debug-application │ │ │ ├── _index.md │ │ │ ├── debug-init-containers.md │ │ │ ├── debug-pods.md │ │ │ ├── debug-running-pod.md │ │ │ ├── debug-service.md │ │ │ ├── debug-statefulset.md │ │ │ ├── determine-reason-pod-failure.md │ │ │ └── get-shell-running-container.md │ │ └── debug-cluster │ │ │ ├── _index.md │ │ │ ├── audit.md │ │ │ ├── crictl.md │ │ │ ├── kubectl-node-debug.md │ │ │ ├── local-debugging.md │ │ │ ├── monitor-node-health.md │ │ │ ├── resource-metrics-pipeline.md │ │ │ ├── resource-usage-monitoring.md │ │ │ └── windows.md │ ├── extend-kubectl │ │ └── kubectl-plugins.md │ ├── extend-kubernetes │ │ ├── _index.md │ │ ├── configure-aggregation-layer.md │ │ ├── configure-multiple-schedulers.md │ │ ├── custom-resources │ │ │ ├── _index.md │ │ │ ├── custom-resource-definition-versioning.md │ │ │ └── custom-resource-definitions.md │ │ ├── http-proxy-access-api.md │ │ ├── setup-extension-api-server.md │ │ ├── setup-konnectivity.md │ │ └── socks5-proxy-access-api.md │ ├── inject-data-application │ │ ├── _index.md │ │ ├── define-command-argument-container.md │ │ ├── define-environment-variable-container.md │ │ ├── define-interdependent-environment-variables.md │ │ ├── distribute-credentials-secure.md │ │ ├── downward-api-volume-expose-pod-information.md │ │ └── environment-variable-expose-pod-information.md │ ├── job │ │ ├── _index.md │ │ ├── automated-tasks-with-cron-jobs.md │ │ ├── coarse-parallel-processing-work-queue.md │ │ ├── fine-parallel-processing-work-queue.md │ │ ├── indexed-parallel-processing-static.md │ │ ├── job-with-pod-to-pod-communication.md │ │ ├── parallel-processing-expansion.md │ │ └── pod-failure-policy.md │ ├── manage-daemon │ │ ├── _index.md │ │ ├── pods-some-nodes.md │ │ ├── rollback-daemon-set.md │ │ └── update-daemon-set.md │ ├── manage-gpus │ │ └── scheduling-gpus.md │ ├── manage-hugepages │ │ └── scheduling-hugepages.md │ ├── manage-kubernetes-objects │ │ ├── _index.md │ │ ├── declarative-config.md │ │ ├── imperative-command.md │ │ ├── imperative-config.md │ │ ├── kustomization.md │ │ └── update-api-object-kubectl-patch.md │ ├── network │ │ ├── _index.md │ │ ├── customize-hosts-file-for-pods.md │ │ └── validate-dual-stack.md │ ├── run-application │ │ ├── _index.md │ │ ├── access-api-from-pod.md │ │ ├── configure-pdb.md │ │ ├── delete-stateful-set.md │ │ ├── force-delete-stateful-set-pod.md │ │ ├── horizontal-pod-autoscale-walkthrough.md │ │ ├── horizontal-pod-autoscale.md │ │ ├── run-replicated-stateful-application.md │ │ ├── run-single-instance-stateful-application.md │ │ ├── run-stateless-application-deployment.md │ │ └── scale-stateful-set.md │ ├── tls │ │ ├── _index.md │ │ ├── certificate-rotation.md │ │ ├── managing-tls-in-a-cluster.md │ │ └── manual-rotation-of-ca-certificates.md │ └── tools │ │ ├── _index.md │ │ ├── included │ │ ├── _index.md │ │ ├── kubectl-convert-overview.md │ │ ├── kubectl-whats-next.md │ │ ├── optional-kubectl-configs-bash-linux.md │ │ ├── optional-kubectl-configs-bash-mac.md │ │ ├── optional-kubectl-configs-fish.md │ │ ├── optional-kubectl-configs-pwsh.md │ │ ├── optional-kubectl-configs-zsh.md │ │ └── verify-kubectl.md │ │ ├── install-kubectl-linux.md │ │ ├── install-kubectl-macos.md │ │ └── install-kubectl-windows.md │ └── tutorials │ ├── _index.md │ ├── configuration │ ├── _index.md │ ├── configure-java-microservice │ │ ├── _index.md │ │ └── configure-java-microservice.md │ └── configure-redis-using-configmap.md │ ├── hello-minikube.md │ ├── kubernetes-basics │ ├── create-cluster │ │ └── _index.md │ ├── deploy-app │ │ └── _index.md │ ├── explore │ │ └── _index.md │ ├── expose │ │ └── _index.md │ ├── scale │ │ └── _index.md │ └── update │ │ └── _index.md │ ├── security │ ├── _index.md │ ├── apparmor.md │ ├── cluster-level-pss.md │ ├── ns-level-pss.md │ └── seccomp.md │ ├── services │ ├── _index.md │ ├── connect-applications-service.md │ ├── pods-and-endpoint-termination-flow.md │ └── source-ip.md │ ├── stateful-application │ ├── _index.md │ ├── basic-stateful-set.md │ ├── cassandra.md │ ├── mysql-wordpress-persistent-volume.md │ └── zookeeper.md │ └── stateless-application │ ├── _index.md │ ├── expose-external-ip-address.md │ └── guestbook.md ├── deploy ├── Dockerfile.aio ├── Dockerfile.serving ├── rayjob-vectorstore.yaml └── rayservice-serving.yaml ├── hack └── data_process.py ├── images └── architecture.png ├── k8s-specific-knowledge-base.zip ├── pkg ├── __init__.py ├── const.py ├── dataset.py ├── dataset_test.py ├── embedding.py ├── pipeline.py ├── serve.py └── utils.py └── requirements.txt /.gitattributes: -------------------------------------------------------------------------------- 1 | *.pdf filter=lfs diff=lfs merge=lfs -text 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | /**/.DS_Store 2 | 3 | __pycache__ 4 | 5 | # models should be downloaded previously. 6 | models/ 7 | faiss_index/*.faiss 8 | faiss_index/*.pkl 9 | 10 | tmp/ 11 | _contents/ 12 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | IMAGE_REPO ?= registry.cn-shanghai.aliyuncs.com/kerthcet-public/rayproject 2 | GIT_TAG ?= $(shell git describe --tags --dirty --always) 3 | IMAGE_WITH_TAG ?= $(IMAGE_REPO):ml-$(GIT_TAG) 4 | 5 | .PHONY: build-aio-image 6 | build-aio-image: build-zip 7 | echo $(IMAGE_WITH_TAG) 8 | docker buildx build \ 9 | -f ./deploy/Dockerfile.aio \ 10 | -t $(IMAGE_WITH_TAG) \ 11 | --platform=linux/amd64 \ 12 | --push \ 13 | ./ \ 14 | 15 | .PHONY: build-serving-image 16 | build-serving-image: build-serving-image 17 | echo $(IMAGE_WITH_TAG) 18 | docker buildx build \ 19 | -f ./deploy/Dockerfile.serving \ 20 | -t $(IMAGE_WITH_TAG) \ 21 | --platform=linux/amd64 \ 22 | --push \ 23 | ./ \ 24 | 25 | .PHONY: build-zip 26 | build-zip: 27 | rm -rf ./k8s-specific-knowledge-base.zip 28 | tar --exclude='contents/' \ 29 | --exclude='models/' \ 30 | --exclude='.git/' \ 31 | --exclude='faiss_index/' \ 32 | -zcvf k8s-specific-knowledge-base.zip \ 33 | ./ 34 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # k8s-specific-knowledge-base 2 | 3 | This is a Question-Answering system based on k8s-specific knowledge build on ChatGLM2-6B, serving by Ray. 4 | It's not ready for production, but we'll target for this. 5 | 6 | 7 | 8 | ## Architecture 9 | 10 | ![architecture](./images/architecture.png) 11 | 12 | ## 🤔 What we used ? 13 | 14 | - [LangChain](https://github.com/langchain-ai/langchain) to build LLM applications. 15 | - [Ray](https://github.com/ray-project/ray) for accelerating and serving. 16 | - [ChatGLM2-6B](https://github.com/THUDM/ChatGLM2-6B) as a base model. 17 | - [BAAI/bge-base-zh-v1.5](https://huggingface.co/BAAI/bge-base-zh) for embedding in semantic search. 18 | - [FAISS](https://github.com/facebookresearch/faiss) as a vector database. 19 | 20 | ## 📦 Corpus Including 21 | 22 | - Kubernetes Website 23 | - Kubernetes Blogs 24 | - Kubernetes Books (Only for research usage) 25 | 26 | ## 🔖 What's next ? 27 | 28 | - Containerization, FAISS is for single node. 29 | - More efficient text splitting ways designed for Chinese. 30 | - More approaches to support semantic search, e.g. key-word embeddings. 31 | - Raw data management, like new uploading and deleting. 32 | - Vector data persistent. 33 | - Continuous Pre-Training. 34 | - and so on ... 35 | 36 | ## 📚 Reference 37 | 38 | - [langchain-ray](https://github.com/ray-project/langchain-ray) 39 | -------------------------------------------------------------------------------- /contents/books/kubernetes-guide-5.pdf: -------------------------------------------------------------------------------- 1 | version https://git-lfs.github.com/spec/v1 2 | oid sha256:29ccb0d0c7046403ec4b2febf1451dda131b35b48db72d6b47d5d940700b62d2 3 | size 291978437 4 | -------------------------------------------------------------------------------- /contents/posts/2015-03-00-Kubernetes-Gathering-Videos.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: " Kubernetes 采集视频 " 3 | date: 2015-03-23 4 | slug: kubernetes-gathering-videos 5 | --- 6 | 7 | 8 | 如果你错过了上个月在旧金山举行的 Kubernetes 大会，不要害怕!以下是在 YouTube 上组织成播放列表的晚间演示文稿中的视频。 9 | 10 | [![Kubernetes Gathering](https://img.youtube.com/vi/q8lGZCKktYo/0.jpg)](https://www.youtube.com/playlist?list=PL69nYSiGNLP2FBVvSLHpJE8_6hRHW8Kxe) 11 | -------------------------------------------------------------------------------- /contents/posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Kubernetes 社区每周聚会笔记 - 2015 年 3 月 27 日" 3 | date: 2015-03-28 4 | slug: weekly-kubernetes-community-hangout 5 | --- 6 | 7 | 每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。 8 | 9 | 日程安排： 10 | 11 | 12 | \- Andy - 演示远程执行和端口转发 13 | 14 | \- Quinton - 联邦集群 - 延迟 15 | 16 | \- Clayton - 围绕 Kubernetes 的 UI 代码共享和协作 17 | 18 | 从会议指出： 19 | 20 | 21 | 1\. Andy 从 RedHat： 22 | 23 | 24 | * 演示远程执行 25 | 26 | 27 | * kubectl exec -p $POD -- $CMD 28 | 29 | * 作为代理与主机建立连接，找出 pod 所在的节点，代理与 kubelet 的连接，这一点很有趣。通过 nsenter。 30 | 31 | * 使用 SPDY 通过 HTTP 进行多路复用流式传输 32 | 33 | * 还有互动模式： 34 | 35 | * 假设第一个容器，可以使用 -c $CONTAINER 一个特定的。 36 | 37 | * 如果在容器中预先安装了 gdb，则可以交互地将其附加到正在运行的进程中 38 | 39 | * backtrace、symbol tbles、print 等。 使用gdb可以做的大多数事情。 40 | 41 | * 也可以用精心制作的参数在上面运行 rsync 或者在容器内设置 sshd。 42 | 43 | * 一些聊天反馈： 44 | 45 | 46 | * Andy 还演示了端口转发 47 | * nnsenter 与 docker exec 48 | 49 | 50 | * 想要在主机的控制下注入二进制文件，类似于预启动钩子 51 | 52 | * socat、nsenter，任何预启动钩子需要的 53 | 54 | 55 | * 如果能在博客上发表这方面的文章就太好了 56 | * wheezy 中的 nginx 版本太旧，无法支持所需的主代理功能 57 | 58 | 59 | 2\. Clayton: 我们的社区组织在哪里，例如 kubernetes UI 组件？ 60 | 61 | * google-containers-ui IRC 频道，邮件列表。 62 | * Tim: google-containers 前缀是历史的，应该只做 "kubernetes-ui" 63 | * 也希望将设计资源投入使用，并且 bower 期望自己的仓库。 64 | * 通用协议 65 | 66 | 67 | 3\. Brian Grant: 68 | 69 | * 测试 v1beta3，准备进入。 70 | * Paul 致力于改变命令行的内容。 71 | * 下周初至中旬，尝试默认启用v1beta3 ? 72 | * 对于任何其他更改，请发出文件并抄送 thockin。 73 | 74 | 75 | 4\. 一般认为30分钟比60分钟好 76 | 77 | 78 | * 不应该为了填满时间而人为地延长。 79 | -------------------------------------------------------------------------------- /contents/posts/2015-03-00-Welcome-To-Kubernetes-Blog.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 欢迎来到 Kubernetes 博客! 3 | date: 2015-03-20 4 | slug: welcome-to-kubernetes-blog 5 | --- 6 | 7 | 欢迎来到新的 Kubernetes 博客。关注此博客，了解 Kubernetes 开源项目。我们计划时不时的发布发布说明，操作方法文章，活动，甚至一些非常有趣的话题。 8 | 9 | 如果您正在使用 Kubernetes 或为该项目做出贡献并想要发帖子，[请告诉我](mailto:kitm@google.com)。 10 | 11 | 首先，以下是 Kubernetes 最近在其他网站上发布的文章摘要： 12 | 13 | 14 | - [使用 Vitess 和 Kubernetes 在云中扩展 MySQL](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html) 15 | - [虚拟机上的容器集群](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html) 16 | - [想知道的关于 kubernetes 的一切，却又不敢问](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html) 17 | - [什么构成容器集群？](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html) 18 | - [将 OpenStack 和 Kubernetes 与 Murano 集成](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/) 19 | - [容器介绍，Kubernetes 以及现代云计算的发展轨迹](http://googlecloudplatform.blogspot.com/2015/01/in-coming-weeks-we-will-be-publishing.html) 20 | - [什么是 Kubernetes 以及如何使用它？](http://www.centurylinklabs.com/what-is-kubernetes-and-how-to-use-it/) 21 | - [OpenShift V3，Docker 和 Kubernetes 策略](https://blog.openshift.com/v3-docker-kubernetes-interview/) 22 | - [Kubernetes 简介](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes) 23 | 24 | 快乐的云计算！ 25 | 26 | - Kit Merker - Google 云平台产品经理 27 | -------------------------------------------------------------------------------- /contents/posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: " 通过 RKT 对 Kubernetes 的 AppC 支持 " 3 | date: 2015-05-04 4 | slug: appc-support-for-kubernetes-through-rkt 5 | --- 6 | 7 | 我们最近接受了对 Kubernetes 项目的拉取请求，以增加对 Kubernetes 社区的应用程序支持。  AppC 是由 CoreOS 发起的新的开放容器规范，并通过 CoreOS rkt 容器运行时受到支持。 8 | 9 | 对于Kubernetes项目和更广泛的容器社区而言，这是重要的一步。  它为容器语言增加了灵活性和选择余地，并为Kubernetes开发人员带来了令人信服的新安全性和性能功能。 10 | 11 | 与智能编排技术（例如 Kubernetes 和/或 Apache Mesos）配合使用时，基于容器的运行时（例如 Docker 或 rkt）对开发人员构建和运行其应用程序的方式是一种合法干扰。  尽管支持技术还处于新生阶段，但它们确实为组装，部署，更新，调试和扩展解决方案提供了一些非常强大的新方法。  我相信，世界还没有意识到容器的全部潜力，未来几年将特别令人兴奋！  考虑到这一点，有几个具有不同属性和不同目的的项目才有意义。能够根据给定应用程序的特定需求将不同的部分（无论是容器运行时还是编排工具）插入在一起也是有意义的。 12 | 13 | Docker 在使容器技术民主化并使外界可以访问它们方面做得非常出色，我们希望 Kubernetes 能够无限期地支持 Docker。CoreOS 还开始与 rkt 进行有趣的工作，以创建一个优雅，干净，简单和开放的平台，该平台提供了一些非常有趣的属性。  这看起来蓄势待发，可以为容器提供安全，高性能的操作环境。  Kubernetes 团队已经与 CoreOS 的 appc 团队合作了一段时间，在许多方面，他们都将 Kubernetes 作为简单的可插入运行时组件来构建 rkt。   14 | 15 | 真正的好处是，借助 Kubernetes，您现在可以根据工作负载的需求选择最适合您的容器运行时，无需替换集群环境即可更改运行时，甚至可以将在同一集群中在不同容器中运行的应用程序的不同部分混合在一起。  其他选择无济于事，但最终使最终开发人员受益。 16 | 17 | -- Craig McLuckie 18 | Google 产品经理和 Kubernetes 联合创始人 19 | -------------------------------------------------------------------------------- /contents/posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: " Kubernetes 社区每周聚会笔记- 2015年5月1日 " 3 | date: 2015-05-11 4 | slug: weekly-kubernetes-community-hangout 5 | --- 6 | 7 | 每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。 8 | 9 | 10 | * 简单的滚动更新 - Brendan 11 | 12 | * 滚动更新 = RCs和Pods很好的例子。 13 | 14 | * ...pause… (Brendan 需要 Kelsey 的演示恢复技巧) 15 | 16 | * 滚动更新具有恢复功能:取消更新并重新启动，更新从停止的地方继续。 17 | 18 | * 新控制器获取旧控制器的名称，因此外观是纯粹的更新。 19 | 20 | * 还可以在 update 中命名版本(最后不会重命名)。 21 | 22 | 23 | * Rocket 演示 - CoreOS 的伙计们 24 | 25 | * Rocket 和 docker 之间的主要区别: Rocket 是无守护进程和以 pod 为中心。。 26 | 27 | * Rocket 具有原生的 AppContainer 格式，但也支持 docker 镜像格式。 28 | 29 | * 可以在同一个 pod 中运行 AppContainer 和 docker 容器。 30 | 31 | * 变更接近于合并。 32 | 33 | 34 | * 演示 service accounts 和 secrets 被添加到 pod - Jordan 35 | 36 | * 问题：很难获得与API通信的令牌。 37 | 38 | * 新的API对象："ServiceAccount" 39 | 40 | * ServiceAccount 是命名空间，控制器确保命名空间中至少存在一个个默认 service account。 41 | 42 | * 键入 "ServiceAccountToken"，控制器确保至少有一个默认令牌。 43 | 44 | * 演示 45 | 46 | * * 可以使用 ServiceAccountToken 创建新的 service account。控制器将为它创建令牌。 47 | 48 | * 可以创建一个带有 service account 的 pod, pod 将在 /var/run/secrets/kubernetes.io/… 49 | 50 | 51 | * Kubelet 在容器中运行 - Paul 52 | 53 | * Kubelet 成功地运行了带有 secret 的 pod。 54 | 55 | -------------------------------------------------------------------------------- /contents/posts/2015-06-00-Slides-Cluster-Management-With.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "幻灯片：Kubernetes 集群管理，爱丁堡大学演讲" 3 | date: 2015-06-26 4 | slug: slides-cluster-management-with 5 | --- 6 | 7 | 8 | 2015年6月5日星期五，我在爱丁堡大学给普通听众做了一个演讲，题目是[使用 Kubernetes 进行集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。这次演讲包括一个带有 Kibana 前端 UI 的音乐存储系统的例子，以及一个基于 Elasticsearch 的后端，该后端有助于生成具体的概念，如 pods、复制控制器和服务。 9 | 10 | [Kubernetes 集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。 11 | -------------------------------------------------------------------------------- /contents/posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "宣布首个Kubernetes企业培训课程 " 3 | date: 2015-07-08 4 | slug: announcing-first-kubernetes-enterprise 5 | --- 6 | 7 | 在谷歌，我们依赖 Linux 容器应用程序去运行我们的核心基础架构。所有服务，从搜索引擎到Gmail服务，都运行在容器中。事实上，我们非常喜欢容器，甚至我们的谷歌云计算引擎虚拟机也运行在容器上！由于容器对于我们的业务至关重要，我们已经与社区合作开发许多基本的容器技术（从 cgroups 到 Docker 的 LibContainer）,甚至决定去构建谷歌的下一代开源容器调度技术，Kubernetes。 8 | 9 | 在 Kubernetes 项目进行一年后，在 OSCON 上发布 V1 版本的前夕，我们很高兴的宣布Kubernetes 的主要贡献者 Mesosphere 组织了有史以来第一次正规的以企业为中心的 Kubernetes 培训会议。首届会议将于 6 月 20 日在波特兰的 OSCON 举办，由来自 Mesosphere 的 Zed Shaw 和 Michael Hausenblas 演讲。[Pre-registration](https://mesosphere.com/training/kubernetes/) 对于优先注册者是免费的，但名额有限，立刻行动吧！ 10 | 11 | 这个为期一天的课程将包涵使用 Kubernetes 构建和部署容器化应用程序的基础知识。它将通过完整的流程引导与参会者创建一个 Kubernetes 的应用程序体系结构，创建和配置 Docker 镜像，并把它们部署到 Kubernetes 集群上。用户还将了解在我们的谷歌容器引擎和 Mesosphere 的数据中心操作系统上部署 Kubernetes 应用程序和服务的基础知识。 12 | 13 | 即将推出的 Kubernetes bootcamp 将是学习如何应用 Kubernetes 解决长期部署和应用程序管理问题的一个好途径。相对于我们所预期的，来自于广泛社区的众多培训项目而言，这只是其中一个。 14 | -------------------------------------------------------------------------------- /contents/posts/2017-10-00-Kubernetes-Community-Steering-Committee-Election-Results.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: " Kubernetes 社区指导委员会选举结果 " 3 | date: 2017-10-05 4 | slug: kubernetes-community-steering-committee-election-results 5 | --- 6 | 7 | 自 2015 年 OSCON 发布 Kubernetes 1.0 以来，大家一直在共同努力，在 Kubernetes 社区中共同分享领导力和责任。 8 | 9 | 在 Brandon Philips、Brendan Burns、Brian Grant、Clayton Coleman、Joe Beda、Sarah Novotny 和 Tim Hockin 组成的自举治理委员会的工作下 - 代表 5 家不同公司的长期领导者，他们对 Kubernetes 生态系统进行了大量的人才投资和努力 - 编写了初始的[指导委员会章程](https://github.com/kubernetes/steering/blob/master/charter.md)，并发起了一次社区选举，以选举 Kubernetes 指导委员会成员。 10 | 11 | 引用章程 - 12 | 13 | _指导委员会的最初职责是**实例化 Kubernetes 治理的正式过程**。除定义初始治理过程外，指导委员会还坚信**提供一种方法来迭代指导委员会定义的方法很重要**。我们不相信我们会在第一次或以后把这些做好，也不会一口气完成治理开发工作。指导委员会的作用是成为一个积极响应的机构，可以根据需要进行重构和改造，以适应不断变化的项目和社区。 14 | 15 | 这是将我们隐式治理结构明确化的最大一步。Kubernetes 的愿景一直是成为一个包容而广泛的社区，用我们的软件带给用户容器的便利性。指导委员会将是一个强有力的引领声音，指导该项目取得成功。 16 | 17 | Kubernetes 社区很高兴地宣布 2017 年指导委员会选举的结果。 **请祝贺 Aaron Crickenberger、Derek Carr、Michelle Noorali、Phillip Wittrock、Quinton Hoole 和 Timothy St. Clair**，他们将成为新成立的 Kubernetes 指导委员会的自举治理委员会成员。Derek、Michelle 和 Phillip 将任职 2 年。Aaron、Quinton、和 Timothy 将任职 1 年。 18 | 19 | 该小组将定期开会，以阐明和简化项目的结构和运行。早期的工作将包括选举 CNCF 理事会的代表，发展项目流程，完善和记录项目的愿景和范围，以及授权和委派更多主题社区团体。 20 | 21 | 请参阅[完整的指导委员会待办事项列表](https://github.com/kubernetes/steering/blob/master/backlog.md)以获取更多详细信息。 22 | -------------------------------------------------------------------------------- /contents/posts/2017-11-00-Autoscaling-In-Kubernetes.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: " Kubernetes 中自动缩放 " 3 | date: 2017-11-17 4 | slug: autoscaling-in-kubernetes 5 | --- 6 | 7 | Kubernetes 允许开发人员根据当前的流量和负载自动调整集群大小和 pod 副本的数量。这些调整减少了未使用节点的数量，节省了资金和资源。 8 | 在这次演讲中，谷歌的 Marcin Wielgus 将带领您了解 Kubernetes 中 pod 和 node 自动调焦的当前状态：它是如何工作的，以及如何使用它，包括在生产应用程序中部署的最佳实践。 9 | 10 | 喜欢这个演讲吗？ 12 月 6 日至 8 日，在 Austin 参加 KubeCon 关于扩展和自动化您的 Kubernetes 集群的更令人兴奋的会议。[现在注册](https://www.eventbrite.com/e/kubecon-cloudnativecon-north-america-registration-37824050754?_ga=2.9666039.317115486.1510003873-1623727562.1496428006)。 11 | 12 | 一定要查看由 Ron Lipke， Gannet/USA Today Network, 平台即服务高级开发人员，在[公共云中自动化和测试产品就绪的 Kubernetes 集群](http://sched.co/CU64)。 13 | 14 | -------------------------------------------------------------------------------- /contents/posts/2018-10-15-steering-election-results.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: blog 3 | title: '2018 年督导委员会选举结果' 4 | date: 2018-10-15 5 | slug: 2018-steering-committee-election-results 6 | --- 7 | 8 | **作者**: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google) 9 | 10 | ## 结果 11 | [Kubernetes 督导委员会选举](https://kubernetes.io/blog/2018/09/06/2018-steering-committee-election-cycle-kicks-off/)现已完成，以下候选人获得了立即开始的两年任期： 12 | 13 | * Aaron Crickenberger, Google, [@spiffxp](https://github.com/spiffxp) 14 | * Davanum Srinivas, Huawei, [@dims](https://github.com/dims) 15 | * Tim St. Clair, Heptio, [@timothysc](https://github.com/timothysc) 16 | 17 | ## 十分感谢！ 18 | 19 | * 督导委员会荣誉退休成员 [Quinton Hoole](https://github.com/quinton-hoole)，表扬他在过去一年为社区所作的贡献。我们期待着 20 | * 参加竞选的候选人。愿我们永远拥有一群强大的人，他们希望在每一次选举中都能像你们一样推动社区向前发展。 21 | * 共计 307 名选民参与投票。 22 | * 本次选举由康奈尔大学主办 [CIVS](https://civs.cs.cornell.edu/)！ 23 | 24 | ## 加入督导委员会 25 | 你可以关注督导委员会的[任务清单](https://git.k8s.io/steering/backlog.md)，并通过向他们的[代码仓库](https://github.com/kubernetes/steering)提交 issue 或 PR 的方式来参与。他们也会在[UTC 时间每周三晚 8 点](https://github.com/kubernetes/steering)举行会议，并定期与我们的贡献者见面。 26 | 27 | 督导委员会会议： 28 | 29 | * [YouTube 播放列表](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM) 30 | 31 | 与我们的贡献者会面： 32 | 33 | 34 | * [2018 年 10 月 3 日](https://youtu.be/x6Jm8p0K-IQ) 35 | * [2018 年 7 月 5 日](https://youtu.be/UbxWV12Or58) 36 | -------------------------------------------------------------------------------- /contents/posts/2022-06-01-annual-report-2021.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: blog 3 | title: "2021 年度总结报告" 4 | date: 2022-06-01 5 | slug: annual-report-summary-2021 6 | --- 7 | 8 | **作者：** Paris Pittman（指导委员会） 9 | 10 | 去年，我们发布了第一期 11 | [2020 年度总结报告](/blog/2021/06/28/announcing-kubernetes-community-group-annual-reports/)， 12 | 现在已经是时候发布第二期了！ 13 | 14 | [2021 年度总结报告](https://www.cncf.io/reports/kubernetes-annual-report-2021/) 15 | 16 | 这份总结反映了 2021 年已完成的工作以及 2022 下半年置于台面上的倡议。 17 | 请将这份总结转发给正参与上游活动、计划云原生战略和寻求帮助的那些组织和个人。 18 | 若要查阅特定社区小组的完整报告，请访问 19 | [kubernetes/community 仓库](https://github.com/kubernetes/community)查找各小组的文件夹。例如： 20 | [sig-api-machinery/annual-report-2021.md](https://github.com/kubernetes/community/blob/master/sig-api-machinery/annual-report-2021.md) 21 | 22 | 你将看到这份总结报告本身涵盖的领域在增长。我们准备和制作这份报告大约用了 6 个月的时间。 23 | 作为一个随着长短期需求而快速发展的项目，这么长的制作周期对任何人来说可能帮助都不大， 24 | 报告的价值也有所缩水。我等苦思无良策，请诸君不吝赐教： 25 | https://github.com/kubernetes/steering/issues/242 26 | 27 | 参考： 28 | [年度报告文献](https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md) 29 | -------------------------------------------------------------------------------- /contents/website/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | linktitle: Kubernetes 文档 3 | title: 文档 4 | sitemap: 5 | priority: 1.0 6 | --- 7 | 8 | -------------------------------------------------------------------------------- /contents/website/concepts/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 概念 3 | main_menu: true 4 | content_type: concept 5 | weight: 40 6 | --- 7 | 8 | 9 | 10 | 概念部分帮助你了解 Kubernetes 系统的各个部分以及 11 | Kubernetes 用来表示{{}}的抽象概念， 12 | 并帮助你更深入地理解 Kubernetes 是如何工作的。 13 | 14 | -------------------------------------------------------------------------------- /contents/website/concepts/architecture/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Kubernetes 架构" 3 | weight: 30 4 | description: > 5 | Kubernetes 背后的架构概念。 6 | --- 7 | -------------------------------------------------------------------------------- /contents/website/concepts/architecture/cri.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器运行时接口（CRI） 3 | content_type: concept 4 | weight: 60 5 | --- 6 | 7 | 8 | CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。 9 | 10 | 你需要在集群中的每个节点上都有一个可以正常工作的{{}}， 11 | 这样 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 能启动 12 | {{< glossary_tooltip text="Pod" term_id="pod" >}} 及其容器。 13 | 14 | {{< glossary_definition prepend="容器运行时接口（CRI）是" term_id="container-runtime-interface" length="all" >}} 15 | 16 | ## API {#api} 17 | 18 | {{< feature-state for_k8s_version="v1.23" state="stable" >}} 19 | 20 | 当通过 gRPC 连接到容器运行时，kubelet 将充当客户端。运行时和镜像服务端点必须在容器运行时中可用， 21 | 可以使用 `--image-service-endpoint` 22 | [命令行标志](/zh-cn/docs/reference/command-line-tools-reference/kubelet)在 kubelet 中单独配置。 23 | 24 | 对 Kubernetes v{{< skew currentVersion >}}，kubelet 偏向于使用 CRI `v1` 版本。 25 | 如果容器运行时不支持 CRI 的 `v1` 版本，那么 kubelet 会尝试协商较老的、仍被支持的所有版本。 26 | v{{< skew currentVersion >}} 版本的 kubelet 也可协商 CRI `v1alpha2` 版本，但该版本被视为已弃用。 27 | 如果 kubelet 无法协商出可支持的 CRI 版本，则 kubelet 放弃并且不会注册为节点。 28 | 29 | ## 升级 {#upgrading} 30 | 31 | 升级 Kubernetes 时，kubelet 会尝试在组件重启时自动选择最新的 CRI 版本。 32 | 如果失败，则将如上所述进行回退。如果由于容器运行时已升级而需要 gRPC 重拨， 33 | 则容器运行时还必须支持最初选择的版本，否则重拨预计会失败。 34 | 这需要重新启动 kubelet。 35 | 36 | ## {{% heading "whatsnext" %}} 37 | 38 | - 了解更多有关 CRI [协议定义](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto) 39 | -------------------------------------------------------------------------------- /contents/website/concepts/cluster-administration/certificates.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 证书 3 | content_type: concept 4 | weight: 20 5 | --- 6 | 7 | 8 | 要了解如何为集群生成证书，参阅[证书](/zh-cn/docs/tasks/administer-cluster/certificates/)。 9 | 10 | -------------------------------------------------------------------------------- /contents/website/concepts/cluster-administration/networking.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 集群网络系统 3 | content_type: concept 4 | weight: 50 5 | --- 6 | 7 | 集群网络系统是 Kubernetes 的核心部分，但是想要准确了解它的工作原理可是个不小的挑战。 8 | 下面列出的是网络系统的的四个主要问题： 9 | 10 | 1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pod" term_id="pod" >}} 11 | 和 `localhost` 通信解决了。 12 | 2. Pod 间通信：这是本文档讲述的重点。 13 | 3. Pod 与 Service 间通信：涵盖在 [Service](/zh-cn/docs/concepts/services-networking/service/) 中。 14 | 4. 外部与 Service 间通信：也涵盖在 Service 中。 15 | 16 | 17 | Kubernetes 的宗旨就是在应用之间共享机器。 18 | 通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间 19 | 去大规模地协调端口是件很困难的事情，尤其是还要让用户暴露在他们控制范围之外的集群级别的问题上。 20 | 21 | 动态分配端口也会给系统带来很多复杂度 - 每个应用都需要设置一个端口的参数， 22 | 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 23 | 与其去解决这些问题，Kubernetes 选择了其他不同的方法。 24 | 25 | 要了解 Kubernetes 网络模型，请参阅[此处](/zh-cn/docs/concepts/services-networking/)。 26 | ## 如何实现 Kubernetes 的网络模型 {#how-to-implement-the-kubernetes-network-model} 27 | 28 | 网络模型由每个节点上的容器运行时实现。最常见的容器运行时使用 29 | [Container Network Interface](https://github.com/containernetworking/cni) (CNI) 插件来管理其网络和安全功能。 30 | 许多不同的 CNI 插件来自于许多不同的供应商。其中一些仅提供添加和删除网络接口的基本功能， 31 | 而另一些则提供更复杂的解决方案，例如与其他容器编排系统集成、运行多个 CNI 插件、高级 IPAM 功能等。 32 | 33 | 请参阅[此页面](/zh-cn/docs/concepts/cluster-administration/addons/#networking-and-network-policy)了解 34 | Kubernetes 支持的网络插件的非详尽列表。 35 | 36 | ## {{% heading "whatsnext" %}} 37 | 38 | 网络模型的早期设计、运行原理以及未来的一些计划， 39 | 都在[联网设计文档](https://git.k8s.io/design-proposals-archive/network/networking.md)里有更详细的描述。 40 | -------------------------------------------------------------------------------- /contents/website/concepts/configuration/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "配置" 3 | weight: 80 4 | description: Kubernetes 为配置 Pods 提供的资源。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/concepts/containers/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "容器" 3 | weight: 40 4 | description: 打包应用及其运行依赖环境的技术。 5 | content_type: concept 6 | --- 7 | 8 | 每个运行的容器都是可重复的； 9 | 包含依赖环境在内的标准，意味着无论你在哪里运行它都会得到相同的行为。 10 | 11 | 容器将应用程序从底层的主机设施中解耦。 12 | 这使得在不同的云或 OS 环境中部署更加容易。 13 | 14 | Kubernetes 集群中的每个{{< glossary_tooltip text="节点" term_id="node" >}}都会运行容器， 15 | 这些容器构成分配给该节点的 [Pod](/zh-cn/docs/concepts/workloads/pods/)。 16 | 单个 Pod 中的容器会在共同调度下，于同一位置运行在相同的节点上。 17 | 18 | 19 | ## 容器镜像 {#container-images} 20 | [容器镜像](/zh-cn/docs/concepts/containers/images/)是一个随时可以运行的软件包， 21 | 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。 22 | 23 | 容器旨在设计成无状态且[不可变的](https://glossary.cncf.io/immutable-infrastructure/)： 24 | 你不应更改已经运行的容器的代码。如果有一个容器化的应用程序需要修改， 25 | 正确的流程是：先构建包含更改的新镜像，再基于新构建的镜像重新运行容器。 26 | 27 | ## 容器运行时 {#container-runtimes} 28 | 29 | {{< glossary_definition term_id="container-runtime" length="all" >}} 30 | 31 | 通常，你可以允许集群为一个 Pod 选择其默认的容器运行时。如果你需要在集群中使用多个容器运行时， 32 | 你可以为一个 Pod 指定 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)， 33 | 以确保 Kubernetes 会使用特定的容器运行时来运行这些容器。 34 | 35 | 你还可以通过 RuntimeClass，使用相同的容器运行时，但使用不同设定的配置来运行不同的 Pod。 36 | -------------------------------------------------------------------------------- /contents/website/concepts/containers/container-environment.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器环境 3 | content_type: concept 4 | weight: 20 5 | --- 6 | 7 | 8 | 本页描述了在容器环境里容器可用的资源。 9 | 10 | 11 | ## 容器环境 {#container-environment} 12 | 13 | Kubernetes 的容器环境给容器提供了几个重要的资源： 14 | 15 | * 文件系统，其中包含一个[镜像](/zh-cn/docs/concepts/containers/images/) 16 | 和一个或多个的[卷](/zh-cn/docs/concepts/storage/volumes/) 17 | * 容器自身的信息 18 | * 集群中其他对象的信息 19 | 20 | ### 容器信息 21 | 22 | 一个容器的 **hostname** 是该容器运行所在的 Pod 的名称。通过 `hostname` 命令或者调用 libc 中的 23 | [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数可以获取该名称。 24 | 25 | Pod 名称和命名空间可以通过 26 | [下行 API](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 27 | 转换为环境变量。 28 | 29 | Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。 30 | 31 | ### 集群信息 32 | 33 | 创建容器时正在运行的所有服务都可用作该容器的环境变量。 34 | 这里的服务仅限于新容器的 Pod 所在的名字空间中的服务，以及 Kubernetes 控制面的服务。 35 | 36 | 对于名为 **foo** 的服务，当映射到名为 **bar** 的容器时，定义了以下变量： 37 | 38 | ```shell 39 | FOO_SERVICE_HOST=<其上服务正运行的主机> 40 | FOO_SERVICE_PORT=<其上服务正运行的端口> 41 | ``` 42 | 43 | 服务具有专用的 IP 地址。如果启用了 44 | [DNS 插件](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/)， 45 | 可以在容器中通过 DNS 来访问服务。 46 | 47 | ## {{% heading "whatsnext" %}} 48 | 49 | * 学习更多有关[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)的知识。 50 | * 动手[为容器的生命周期事件设置处理函数](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 51 | 52 | 53 | -------------------------------------------------------------------------------- /contents/website/concepts/extend-kubernetes/api-extension/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 扩展 Kubernetes API 3 | weight: 30 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/concepts/policy/node-resource-managers.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 节点资源管理器 3 | content_type: concept 4 | weight: 50 5 | --- 6 | 7 | 8 | Kubernetes 提供了一组资源管理器，用于支持延迟敏感的、高吞吐量的工作负载。 9 | 资源管理器的目标是协调和优化节点资源，以支持对 CPU、设备和内存（巨页）等资源有特殊需求的 Pod。 10 | 11 | 12 | 主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件， 13 | 它通过[策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)， 14 | 协调全局的资源管理过程。 15 | 16 | 各个管理器的配置方式会在专项文档中详细阐述： 17 | 18 | - [CPU 管理器策略](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/) 19 | - [设备管理器](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) 20 | - [内存管理器策略](/zh-cn/docs/tasks/administer-cluster/memory-manager/) 21 | -------------------------------------------------------------------------------- /contents/website/concepts/security/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "安全" 3 | weight: 85 4 | description: 确保云原生工作负载安全的一组概念。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/concepts/security/pod-security-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Pod 安全策略 3 | content_type: concept 4 | weight: 30 5 | --- 6 | 7 | 8 | {{% alert title="被移除的特性" color="warning" %}} 9 | PodSecurityPolicy 在 Kubernetes v1.21 10 | 中[被弃用](/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation)， 11 | 在 Kubernetes v1.25 中被移除。 12 | {{% /alert %}} 13 | 14 | 作为替代，你可以使用下面任一方式执行类似的限制，或者同时使用下面这两种方式。 15 | 16 | - [Pod 安全准入](/zh-cn/docs/concepts/security/pod-security-admission/) 17 | - 自行部署并配置第三方准入插件 18 | 19 | 有关如何迁移， 20 | 参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。 21 | 有关移除此 API 的更多信息，参阅 22 | [弃用 PodSecurityPolicy：过去、现在、未来](/zh-cn/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。 23 | 24 | 如果所运行的 Kubernetes 不是 v{{< skew currentVersion >}} 版本，则需要查看你所使用的 Kubernetes 版本的对应文档。 25 | -------------------------------------------------------------------------------- /contents/website/concepts/storage/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "存储" 3 | weight: 70 4 | description: 为集群中的 Pods 提供长期和临时存储的方法。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/concepts/windows/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Kubernetes 中的 Windows" 3 | simple_list: true 4 | weight: 200 5 | description: >- 6 | Kubernetes 支持运行 Microsoft Windows 节点。 7 | --- 8 | 9 | 10 | Kubernetes 支持运行 Linux 或 Microsoft Windows 11 | 的工作{{< glossary_tooltip text="节点" term_id="node" >}}。 12 | 13 | {{% thirdparty-content single="true" %}} 14 | 15 | CNCF 及其母公司 Linux 基金会采用供应商中立的方法来实现兼容性。可以将你的 16 | [Windows 服务器](https://www.microsoft.com/en-us/windows-server)作为工作节点加入 17 | Kubernetes 集群。 18 | 19 | 无论你的集群使用什么操作系统， 20 | 都可以[在 Windows 上安装和设置 kubectl](/zh-cn/docs/tasks/tools/install-kubectl-windows/)。 21 | 22 | 如果你使用的是 Windows 节点，你可以阅读： 23 | 24 | * [Windows 上的网络](/zh-cn/docs/concepts/services-networking/windows-networking/) 25 | * [Kubernetes 中的 Windows 存储](/zh-cn/docs/concepts/storage/windows-storage/) 26 | * [Windows 节点的资源管理](/zh-cn/docs/concepts/configuration/windows-resource-management/) 27 | * [为 Windows Pod 和容器配置 RunAsUserName](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername/) 28 | * [创建 Windows HostProcess Pod](/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod/) 29 | * [为 Windows Pod 和容器配置组托管服务帐户](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/) 30 | * [Windows 节点的安全性](/zh-cn/docs/concepts/security/windows-security/) 31 | * [Windows 调试技巧](/zh-cn/docs/tasks/debug/debug-cluster/windows/) 32 | * [在 Kubernetes 中调度 Windows 容器指南](/zh-cn/docs/concepts/windows/user-guide) 33 | 34 | 或者，要了解概览，请阅读： 35 | 36 | 37 | -------------------------------------------------------------------------------- /contents/website/concepts/workloads/controllers/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "工作负载资源" 3 | weight: 20 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/contribute/analytics.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 查看站点分析 3 | content_type: concept 4 | weight: 120 5 | card: 6 | name: contribute 7 | weight: 100 8 | --- 9 | 10 | 11 | 12 | 此页面包含有关 kubernetes.io 分析仪表板的信息。 13 | 14 | 15 | [查看仪表板](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04)。 16 | 17 | 此仪表板使用 Google Data Studio 构建，显示使用 Google Analytics 在 kubernetes.io 上收集的信息。 18 | 19 | ### 使用仪表板 20 | 21 | 默认情况下，仪表板显示过去 30 天收集的所有分析。 22 | 使用日期选择器查看来自不同日期范围的数据。 23 | 其他过滤选项允许你根据用户位置、用于访问站点的设备、所用文档的翻译等查看数据。 24 | 25 | 如果你发现此仪表板存在问题，或者想要请求任何改进， 26 | 请[开启一个问题](https://github.com/kubernetes/website/issues/new/choose)。 27 | -------------------------------------------------------------------------------- /contents/website/contribute/generate-ref-docs/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 更新参考文档 3 | main_menu: true 4 | weight: 80 5 | --- 6 | 7 | 8 | 9 | 本节的主题是描述如何生成 Kubernetes 参考指南。 10 | 要生成参考文档，请参考下面的指南： 11 | 12 | * [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) 13 | 14 | -------------------------------------------------------------------------------- /contents/website/contribute/generate-ref-docs/kubernetes-components.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 为 Kubernetes 组件和工具生成参考文档 3 | content_type: task 4 | weight: 120 5 | --- 6 | 7 | 8 | 9 | 本页面描述如何构造 Kubernetes 组件和工具的参考文档。 10 | 11 | ## {{% heading "prerequisites" %}} 12 | 13 | 阅读参考文档快速入门指南中的[准备工作](/zh-cn/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 14 | 15 | 16 | 按照[参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) 17 | 指引，生成 Kubernetes 组件和工具的参考文档。 18 | 19 | ## {{% heading "whatsnext" %}} 20 | 21 | 22 | * [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) 23 | * [为 kubectll 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) 24 | * [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) 25 | * [为上游 Kubernetes 项目做贡献以改进文档](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/) 26 | 27 | -------------------------------------------------------------------------------- /contents/website/contribute/generate-ref-docs/prerequisites-ref-docs.md: -------------------------------------------------------------------------------- 1 | 2 | ### 需求 {#requirements} 3 | 4 | - 你需要一台 Linux 或 macOS 机器。 5 | 6 | - 你需要安装以下工具： 7 | 8 | - [Python](https://www.python.org/downloads/) v3.7.x 9 | - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) 10 | - [Golang](https://golang.org/doc/install) 1.13+ 版本 11 | - 用来安装 PyYAML 的 [Pip](https://pypi.org/project/pip/) 12 | - [PyYAML](https://pyyaml.org/) v5.1.2 13 | - [make](https://www.gnu.org/software/make/) 14 | - [gcc compiler/linker](https://gcc.gnu.org/) 15 | - [Docker](https://docs.docker.com/engine/installation/) （仅用于 `kubectl` 命令参考） 16 | 17 | - 你的 `PATH` 环境变量必须包含所需要的构建工具，例如 `Go` 程序和 `python`。 18 | 19 | - 你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。 20 | 这牵涉到创建仓库的派生（fork）副本。 21 | 有关信息可进一步查看[基于本地副本开展工作](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 22 | 23 | -------------------------------------------------------------------------------- /contents/website/contribute/review/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 评阅变更 3 | weight: 30 4 | --- 5 | 6 | 本节描述如何对内容进行评阅。 7 | 8 | 9 | -------------------------------------------------------------------------------- /contents/website/contribute/style/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 文档样式概述 3 | main_menu: true 4 | weight: 80 5 | --- 6 | 7 | 8 | 本节的主题是提供有关写作风格、内容格式和组织以及如何使用 9 | 特定于 Kubernetes 文档的 Hugo 定制代码的指导。 10 | -------------------------------------------------------------------------------- /contents/website/contribute/style/hugo-shortcodes/example1.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 例子 #1 3 | --- 4 | 5 | 这是一个内容文件**示例**，位于一个**includes**叶子包中。 6 | 7 | {{< note >}} 8 | 被包含的内容文件也可以包含短代码。 9 | {{< /note >}} 10 | -------------------------------------------------------------------------------- /contents/website/contribute/style/hugo-shortcodes/example2.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 例子 #1 3 | --- 4 | 5 | 这是另一个内容文件**示例**，位于一个**includes**叶子包中。 6 | 7 | -------------------------------------------------------------------------------- /contents/website/home/supported-doc-versions.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubernetes 文档支持的版本 3 | content_type: custom 4 | layout: supported-versions 5 | card: 6 | name: about 7 | weight: 10 8 | title: Kubernetes 文档支持的版本 9 | --- 10 | 11 | 12 | 本网站包含当前版本和之前四个版本的 Kubernetes 文档。 13 | 14 | Kubernetes 版本的文档可用性与当前是否支持该版本是分开的。 15 | 阅读[支持期限](/zh-cn/releases/patch-releases/#support-period)，了解官方支持 Kubernetes 的哪些版本，以及支持多长时间。 16 | -------------------------------------------------------------------------------- /contents/website/reference/command-line-tools-reference/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 组件工具 3 | weight: 120 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/reference/config-api/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 配置 API 3 | weight: 130 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/reference/config-api/apiserver-webhookadmission.v1.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: WebhookAdmission 配置 (v1) 3 | content_type: tool-reference 4 | package: apiserver.config.k8s.io/v1 5 | auto_generated: true 6 | --- 7 | 8 | 9 |

此 API 的版本是 v1。

10 | 11 | ## 资源类型 {#resource-types} 12 | 13 | - [WebhookAdmission](#apiserver-config-k8s-io-v1-WebhookAdmission) 14 | 15 | ## `WebhookAdmission` {#apiserver-config-k8s-io-v1-WebhookAdmission} 16 | 17 |

WebhookAdmission 为 Webhook 准入控制器提供配置信息。

18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | string 27 | 28 | 31 | 32 | 33 | 34 |
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		WebhookAdmission
29 |

字段 kubeConfigFile 包含指向 kubeconfig 文件的路径。

30 |
35 | 36 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/addons.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 附加组件（Add-ons） 3 | id: addons 4 | date: 2019-12-15 5 | full_link: /zh-cn/docs/concepts/cluster-administration/addons/ 6 | short_description: > 7 | 扩展 Kubernetes 功能的资源。 8 | 9 | aka: 10 | tags: 11 | - tool 12 | --- 13 | 14 | 扩展 Kubernetes 功能的资源。 15 | 16 | 17 | [安装附加组件](/zh-cn/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/admission-controller.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 准入控制器（Admission Controller） 3 | id: admission-controller 4 | date: 2019-06-28 5 | full_link: /zh-cn/docs/reference/access-authn-authz/admission-controllers/ 6 | short_description: > 7 | 在对象持久化之前拦截 Kubernetes API 服务器请求的一段代码。 8 | aka: 9 | tags: 10 | - extension 11 | - security 12 | --- 13 | 14 | 在对象持久化之前拦截 Kubernetes API 服务器请求的一段代码。 15 | 16 | 17 | 准入控制器可针对 Kubernetes API 服务器进行配置，可以执行“验证（validating）“、“变更（mutating）“或两者都执行。 18 | 任何准入控制器都可以拒绝访问请求。 19 | 变更控制器可以修改其允许的对象，验证控制器则不可以。 20 | 21 | * [Kubernetes 文档中的准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/affinity.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 亲和性（Affinity） 3 | id: affinity 4 | date: 2019-01-11 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity 6 | short_description: > 7 | 调度程序用于确定在何处放置 Pod（亲和性）的规则。 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 13 | 在 Kubernetes 中 **亲和性（affinity）** 是一组规则，它们为调度程序提供在何处放置 Pod 提示信息。 14 | 15 | 16 | 亲和性有两种： 17 | 18 | * [节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) 19 | * [Pod 间亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) 20 | 21 | 这些规则是使用 Kubernetes {{< glossary_tooltip term_id="label" text="标签">}}（label） 22 | 和 {{< glossary_tooltip term_id="pod" text="Pod" >}} 中指定的 23 | {{< glossary_tooltip term_id="selector" text="选择算符">}}定义的， 24 | 这些规则可以是必需的或首选的，这取决于你希望调度程序执行它们的严格程度。 25 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/aggregation-layer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 聚合层（Aggregation Layer） 3 | id: aggregation-layer 4 | date: 2018-10-08 5 | full_link: /zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 6 | short_description: > 7 | 聚合层允许你在自己的集群上安装额外的 Kubernetes 风格的 API。 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | - extension 13 | - operation 14 | --- 15 | 16 | 聚合层允许你在自己的集群上安装额外的 Kubernetes 风格的 API。 17 | 18 | 19 | 当你配置了 {{< glossary_tooltip text="Kubernetes API 服务器" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)， 20 | 你就可以在 Kubernetes API 中增加 `APIService` 对象来"申领（Claim）"一个 URL 路径。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/annotation.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 注解（Annotation） 3 | id: annotation 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/annotations/ 6 | short_description: > 7 | 注解是以键值对的形式给资源对象附加随机的无法标识的元数据。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 注解是以键值对的形式给资源对象附加随机的无法标识的元数据。 15 | 16 | 17 | 注解中的元数据可大可小，可以是结构化的也可以是非结构化的， 18 | 并且能包含{{< glossary_tooltip text="标签" term_id="label" >}}不允许使用的字符。 19 | 像工具和软件库这样的客户端可以检索这些元数据。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/api-eviction.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: API 发起的驱逐（API-initiated eviction） 3 | id: api-eviction 4 | date: 2021-04-27 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/api-eviction/ 6 | short_description: > 7 | API 发起的驱逐是一个先调用 Eviction API 创建驱逐对象，再由该对象体面地中止 Pod 的过程。 8 | aka: 9 | tags: 10 | - operation 11 | --- 12 | 13 | API 发起的驱逐是一个先调用 14 | [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) 15 | 创建 `Eviction` 对象，再由该对象体面地中止 Pod 的过程。 16 | 17 | 18 | 你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 19 | 当 `Eviction` 对象创建出来之后，该对象将驱动 API 服务器终止选定的 Pod。 20 | 21 | API 发起的驱逐取决于你配置的 [`PodDisruptionBudgets`](/zh-cn/docs/tasks/run-application/configure-pdb/) 22 | 和 [`terminationGracePeriodSeconds`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)。 23 | 24 | API 发起的驱逐不同于 25 | [节点压力引发的驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 26 | 27 | * 有关详细信息，请参阅 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/api-group.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: API Group (API 组) 3 | id: api-group 4 | date: 2019-09-02 5 | full_link: /zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning 6 | short_description: > 7 | Kubernetes API 中的一组相关路径。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - architecture 13 | --- 14 | 15 | Kubernetes API 中的一组相关路径。 16 | 17 | 通过更改 API 服务器的配置，可以启用或禁用每个 API 组 (API Group)。 18 | 你还可以禁用或启用指向特定资源的路径。 19 | API 组使扩展 Kubernetes API 更加的容易。 20 | API 组在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 21 | 22 | * 阅读 [API 组](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/app-container.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 应用程序容器（App Container） 3 | id: app-container 4 | date: 2019-02-12 5 | full_link: 6 | short_description: > 7 | 用于运行部分工作负载的容器。与 Init 容器比较而言。 8 | 9 | aka: 10 | tags: 11 | - workload 12 | --- 13 | 14 | 应用程序容器是在 {{< glossary_tooltip text="Pod" term_id="pod" >}} 15 | 中的{{< glossary_tooltip text="容器" term_id="container" >}}（或 app 容器）， 16 | 在 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}}启动完毕后才开始启动。 17 | 18 | 19 | Init 容器使你可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}}整体而言很重要的初始化细节， 20 | 并且一旦应用容器启动，它不需要继续运行。 21 | 如果 Pod 没有配置 Init 容器，则该 Pod 中的所有容器都是应用程序容器。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/application-architect.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 应用架构师（Application Architect） 3 | id: application-architect 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 应用架构师是负责应用高级设计的人。 8 | 9 | aka: 10 | tags: 11 | - user-type 12 | --- 13 | 14 | 应用架构师是负责应用高级设计的人。 15 | 16 | 17 | 应用架构师确保应用的实现允许它和周边组件进行可扩展的、可持续的交互。 18 | 周边组件包括数据库、日志基础设施和其他微服务。 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/application-developer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 应用开发者（Application Developer） 3 | id: application-developer 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 编写可以在 Kubernetes 集群上运行的应用的人。 8 | 9 | aka: 10 | tags: 11 | - user-type 12 | --- 13 | 14 | 编写可以在 Kubernetes 集群上运行的应用的人。 15 | 16 | 17 | 应用开发者专注于应用的某一部分。他们工作范围的大小有明显的差异。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/applications.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 应用（Applications） 3 | id: applications 4 | date: 2019-05-12 5 | full_link: 6 | short_description: > 7 | 各种容器化应用运行所在的层。 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 13 | 14 | 各种容器化应用运行所在的层。 15 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/approver.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 批准者（Approver） 3 | id: approver 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 可以审核并批准 Kubernetes 代码贡献的人。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 能够审核并批准 Kubernetes 代码贡献的人。 15 | 16 | 17 | 代码审核的重点是代码质量和正确性，而批准的重点是对贡献的整体接受。 18 | 整体接受包括向后/向前兼容性、遵守 API 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。 19 | 批准者状态的作用域是代码库的一部分。审批者以前被称为维护者。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cadvisor.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: cAdvisor 3 | id: cadvisor 4 | date: 2021-12-09 5 | full_link: https://github.com/google/cadvisor/ 6 | short_description: > 7 | 帮助理解容器的资源用量与性能特征的工具。 8 | 9 | aka: 10 | tags: 11 | - tool 12 | --- 13 | 14 | cAdvisor (Container Advisor) 为容器用户提供对其运行中的{{< glossary_tooltip text="容器" term_id="container" >}} 15 | 的资源用量和性能特征的知识。 16 | 17 | 18 | cAdvisor 是一个守护进程，负责收集、聚合、处理并输出运行中容器的信息。 19 | 具体而言，针对每个容器，该进程记录容器的资源隔离参数、历史资源用量、完整历史资源用量和网络统计的直方图。 20 | 这些数据可以按容器或按机器层面输出。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/certificate.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 证书（Certificate） 3 | id: certificate 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/ 6 | short_description: > 7 | 证书是个安全加密文件，用来确认对 Kubernetes 集群访问的合法性。 8 | 9 | aka: 10 | tags: 11 | - security 12 | --- 13 | 14 | 证书是个安全加密文件（cryptographically secure file），用来确认对 Kubernetes 集群访问的合法性。 15 | 16 | 17 | 证书（Certificate）可以让 Kubernetes 集群中运行的应用程序安全的访问 Kubernetes API。证书可以确认客户端是否被允许访问 API。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cgroup.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 控制组（cgroup；control group） 3 | id: cgroup 4 | date: 2019-06-25 5 | full_link: 6 | short_description: > 7 | 一组具有可选资源隔离、审计和限制的 Linux 进程。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 一组具有可选资源隔离、审计和限制的 Linux 进程。 15 | 16 | 17 | cgroup 是一个 Linux 内核特性，对一组进程的资源使用（CPU、内存、磁盘 I/O 和网络等）进行限制、审计和隔离。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cidr.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: CIDR 3 | id: cidr 4 | date: 2019-11-12 5 | full_link: 6 | short_description: > 7 | CIDR 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 8 | 9 | aka: 10 | tags: 11 | - networking 12 | --- 13 | 14 | CIDR（无类域间路由，Classless Inter-Domain Routing）是一种描述 15 | IP 地址块的符号，被广泛使用于各种网络配置中。 16 | 17 | 18 | 在 Kubernetes 的上下文中，每个{{< glossary_tooltip text="节点" term_id="node" >}} 19 | 以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段， 20 | 从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。 21 | 虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cla.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 贡献者许可协议（CLA；Contributor License Agreement） 3 | id: cla 4 | date: 2018-04-12 5 | full_link: https://github.com/kubernetes/community/blob/master/CLA.md 6 | short_description: > 7 | 贡献者对他们在开源项目中所贡献的代码的授权许可条款。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | {{< glossary_tooltip text="贡献者" term_id="contributor" >}}对他们在开源项目中所贡献的代码的授权许可条款。 15 | 16 | 17 | CLA 对解决贡献者在开源社区所贡献的资料和知识产权（IP）导致的法律纠纷很有帮助。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cloud-controller-manager.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 云控制器管理器（Cloud Controller Manager） 3 | id: cloud-controller-manager 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/architecture/cloud-controller/ 6 | short_description: > 7 | 将 Kubernetes 与第三方云提供商进行集成的控制平面组件。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - architecture 13 | - operation 14 | --- 15 | 16 | 一个 Kubernetes {{}}组件， 17 | 嵌入了特定于云平台的控制逻辑。 18 | 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 19 | 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 20 | 21 | 22 | 通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑， 23 | `cloud-controller-manager` 组件使云提供商能够以不同于 Kubernetes 主项目的步调发布新特征。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cloud-provider.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 云提供商（Cloud Provider） 3 | id: cloud-provider 4 | date: 2018-04-12 5 | short_description: > 6 | 一个提供云计算平台的组织。 7 | 8 | aka: 9 | - 云服务提供商（Cloud Service Provider） 10 | tags: 11 | - community 12 | --- 13 | 14 | 一个提供云计算平台的商业机构或其他组织。 15 | 16 | 17 | 云提供商（Cloud provider），有时也称作云服务提供商（CSPs）提供云计算平台或服务。 18 | 19 | 很多云提供商提供托管的基础设施（也称作基础设施即服务或 IaaS）。 20 | 针对托管的基础设施，云提供商负责服务器、存储和网络，而用户（你） 21 | 负责管理其上运行的各层软件，例如运行一个 Kubernetes 集群。 22 | 23 | 你也会看到 Kubernetes 被作为托管服务提供；有时也称作平台即服务或 PaaS。 24 | 针对托管的 Kubernetes，你的云提供商负责 Kubernetes 的控制平面以及 25 | {{< glossary_tooltip term_id="node" text="节点" >}} 及他们所依赖的基础设施： 26 | 网络、存储以及其他一些诸如负载均衡器之类的元素。 27 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cluster-architect.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 集群架构师（Cluster Architect） 3 | id: cluster-architect 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 设计涉及一个或多个 Kubernetes 集群的基础设施的人。 8 | 9 | aka: 10 | tags: 11 | - user-type 12 | --- 13 | 14 | 15 | 设计涉及一个或多个 Kubernetes 集群的基础设施的人。 16 | 17 | 18 | 集群架构师（Cluster Architect）关心分布式系统的最佳实践，例如：高可用性和安全性。 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cluster-infrastructure.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 集群基础设施（Cluster Infrastructure） 3 | id: cluster-infrastructure 4 | date: 2019-05-12 5 | full_link: 6 | short_description: > 7 | 基础设施层提供并维护虚拟机、网络、安全组及其他资源。 8 | 9 | aka: 10 | tags: 11 | - operations 12 | --- 13 | 14 | 15 | 基础设施层提供并维护虚拟机、网络、安全组及其他资源。 16 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cluster-operations.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 集群操作（Cluster Operations） 3 | id: cluster-operations 4 | date: 2019-05-12 5 | full_link: 6 | short_description: > 7 | 管理 Kubernetes 集群所涉及的相关工作。 8 | 9 | aka: 10 | tags: 11 | - operations 12 | --- 13 | 14 | Kubernetes 管理相关工作包括：日常管理操作和协调升级。 15 | 16 | 17 | 集群操作（Cluster Operations）工作的示例包括： 18 | 部署新节点来扩容集群、执行软件升级、实施安全控制、 19 | 添加或删除存储、配置集群网络、管理集群范围的可观测性和响应集群事件。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cluster-operator.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 集群操作者（Cluster Operator） 3 | id: cluster-operator 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 配置、控制、监控集群的人。 8 | 9 | aka: 10 | tags: 11 | - user-type 12 | --- 13 | 14 | 配置、控制、监控集群的人。 15 | 16 | 17 | 他们的主要责任是保持集群正常运行，可能需要进行周期性的维护和升级活动。
18 | 19 | {{< note >}} 20 | **注意：** 集群操作者不同于[操作者模式（Operator Pattern）](https://www.openshift.com/learn/topics/operators)，操作者模式是用来扩展 Kubernetes API 的。 21 | {{< /note >}} 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cluster.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 集群（Cluster） 3 | id: cluster 4 | date: 2019-06-15 5 | full_link: 6 | short_description: > 7 | 一组工作机器，称为节点，会运行容器化应用程序。每个集群至少有一个工作节点。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - operation 13 | --- 14 | 15 | 一组工作机器，称为 {{< glossary_tooltip text="节点" term_id="node" >}}， 16 | 会运行容器化应用程序。每个集群至少有一个工作节点。 17 | 18 | 19 | 工作节点会托管 {{< glossary_tooltip text="Pod" term_id="pod" >}} 20 | ，而 Pod 就是作为应用负载的组件。 21 | {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}管理集群中的工作节点和 Pod。 22 | 在生产环境中，控制平面通常跨多台计算机运行， 23 | 一个集群通常运行多个节点，提供容错性和高可用性。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cncf.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 云原生计算基金会（CNCF；Cloud Native Computing Foundation） 3 | id: cncf 4 | date: 2019-05-26 5 | full_link: https://cncf.io/ 6 | short_description: > 7 | 云原生计算基金会（Cloud Native Computing Foundation） 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 云原生计算基金会（CNCF；Cloud Native Computing Foundation）建立可持续的生态系统， 15 | 并围绕[项目](https://www.cncf.io/projects/)建立社区，对作为微服务架构之组件的容器进行编排。 16 | 17 | Kubernetes 是一个 CNCF 项目。 18 | 19 | 20 | 云原生计算基金会（CNCF）是 [Linux 基金会](https://www.linuxfoundation.org/)的子基金会。 21 | 它的使命是让云原生计算无处不在。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cni.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器网络接口（Container network interface；CNI） 3 | id: cni 4 | date: 2018-05-25 5 | full_link: /zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ 6 | short_description: > 7 | 容器网络接口 (Container network interface；CNI) 插件是遵循 appc/CNI 协议的一类网络插件。 8 | 9 | 10 | aka: 11 | tags: 12 | - networking 13 | --- 14 | 15 | 容器网络接口 (Container network interface；CNI) 插件是遵循 appc/CNI 协议的一类网络插件。 16 | 17 | 18 | * 有关 Kubernetes 和 CNI 的信息，请参考[**网络插件**](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)。 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/code-contributor.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 代码贡献者（Code Contributor） 3 | id: code-contributor 4 | date: 2018-04-12 5 | full_link: https://github.com/kubernetes/community/tree/master/contributors/devel 6 | short_description: > 7 | 为 Kubernetes 开源代码库开发并贡献代码的人。 8 | 9 | aka: 10 | tags: 11 | - community 12 | - user-type 13 | --- 14 | 15 | 为 Kubernetes 开源代码库开发并贡献代码的人。 16 | 17 | 18 | 他们也是加入一个或多个{{< glossary_tooltip text="特别兴趣小组 (Special Interest Groups；SIGs)" term_id="sig" >}}的活跃{{< glossary_tooltip text="成员" term_id="member" >}}。 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/configmap.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: ConfigMap 3 | id: configmap 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/ 6 | short_description: > 7 | ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | --- 13 | 14 | ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， {{< glossary_tooltip text="Pods" term_id="pod" >}} 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。 15 | 16 | 17 | ConfigMap 将你的环境配置信息和 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 解耦，便于应用配置的修改。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/container-env-variables.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器环境变量（Container Environment Variables） 3 | id: container-env-variables 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/containers/container-environment/ 6 | short_description: > 7 | 容器环境变量提供了 name=value 形式的、运行容器化应用所必须的一些重要信息。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 容器环境变量提供了 name=value 形式的、在 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的容器所必须的一些重要信息。 15 | 16 | 17 | 容器环境变量为运行中的容器化应用提供必要的信息，同时还提供与{{< glossary_tooltip text="容器" term_id="container" >}}重要资源相关的其他信息，例如：文件系统信息、容器自身的信息以及其他像服务端点（Service endpoints）这样的集群资源信息。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/container-lifecycle-hooks.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器生命周期钩子（Container Lifecycle Hooks） 3 | id: container-lifecycle-hooks 4 | date: 2018-10-08 5 | full_link: /zh-cn/docs/concepts/containers/container-lifecycle-hooks/ 6 | short_description: > 7 | 生命周期钩子暴露容器管理生命周期中的事件，允许用户在事件发生时运行代码。 8 | 9 | aka: 10 | tags: 11 | - extension 12 | --- 13 | 14 | 生命周期钩子（Lifecycle Hooks）暴露{{< glossary_tooltip text="容器" term_id="container" >}}管理生命周期中的事件，允许用户在事件发生时运行代码。 15 | 16 | 17 | 针对容器暴露了两个钩子： 18 | PostStart 在容器创建之后立即执行， 19 | PreStop 在容器停止之前立即阻塞并被调用。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/container-runtime-interface.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器运行时接口（Container Runtime Interface） 3 | id: container-runtime-interface 4 | date: 2021-11-24 5 | full_link: /zh-cn/docs/concepts/architecture/cri 6 | short_description: > 7 | kubelet 和容器运行时之间通信的主要协议。 8 | 9 | aka: 10 | tags: 11 | - cri 12 | --- 13 | 14 | kubelet 和容器运行时之间通信的主要协议。 15 | 16 | 17 | Kubernetes 容器运行时接口（Container Runtime Interface；CRI）定义了主要 [gRPC](https://grpc.io) 协议， 18 | 用于[集群组件](/zh-cn/docs/concepts/overview/components/#node-components) 19 | {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 和 20 | {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}之间的通信。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/container-runtime.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器运行时（Container Runtime） 3 | id: container-runtime 4 | date: 2019-06-05 5 | full_link: /zh-cn/docs/setup/production-environment/container-runtimes 6 | short_description: > 7 | 容器运行时是负责运行容器的软件。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - workload 13 | --- 14 | 15 | 容器运行环境是负责运行容器的软件。 16 | 17 | 18 | Kubernetes 支持许多容器运行环境，例如 19 | {{< glossary_tooltip term_id="containerd" >}}、 20 | {{< glossary_tooltip term_id="cri-o" >}} 21 | 以及 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 22 | 的其他任何实现。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/container.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器（Container） 3 | id: container 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/what-is-kubernetes/#why-containers 6 | short_description: > 7 | 容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - workload 13 | --- 14 | 15 | 容器是可移植、可执行的轻量级的镜像，包含其中的软件及其相关依赖。 16 | 17 | 18 | 容器使应用和底层的主机基础设施解耦，降低了应用在不同云环境或者操作系统上的部署难度，便于应用扩展。 19 | 在容器内运行的应用程序称为容器化应用程序。 将这些应用程序及其依赖项捆绑到容器映像中的过程称为容器化。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/containerd.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: containerd 3 | id: containerd 4 | date: 2019-05-14 5 | full_link: https://containerd.io/docs/ 6 | short_description: > 7 | 强调简单性、健壮性和可移植性的一种容器运行时 8 | aka: 9 | tags: 10 | - tool 11 | --- 12 | 13 | 强调简单性、健壮性和可移植性的一种容器运行时 14 | 15 | 16 | containerd 是一种{{< glossary_tooltip text="容器" term_id="container" >}}运行时，能在 Linux 或者 Windows 后台运行。 17 | containerd 能取回、存储容器镜像，执行容器实例，提供网络访问等。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/contributor.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 贡献者（Contributor） 3 | id: contributor 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 通过贡献代码、文档或者投入时间等方式来帮助 Kubernetes 项目或社区的人。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 15 | 通过贡献代码、文档或者投入时间等方式来帮助 Kubernetes 项目或社区的人。 16 | 17 | 贡献形式包括提交拉取请求（PRs）、问题报告（Issues）、反馈、参与{{< glossary_tooltip text="特别兴趣小组（SIG）" term_id="sig" >}}或者组织社区活动等等。 18 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/control-plane.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 控制平面（Control Plane） 3 | id: control-plane 4 | date: 2019-05-12 5 | full_link: 6 | short_description: > 7 | 控制平面是指容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 控制平面（Control Plane）是指容器编排层，它暴露 API 和接口来定义、 15 | 部署容器和管理容器的生命周期。 16 | 17 | 18 | 这个编排层是由多个不同的组件组成，例如以下（但不限于）几种： 19 | 20 | * {{< glossary_tooltip text="etcd" term_id="etcd" >}} 21 | * {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 22 | * {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} 23 | * {{< glossary_tooltip text="控制器管理器" term_id="kube-controller-manager" >}} 24 | * {{< glossary_tooltip text="云控制器管理器" term_id="cloud-controller-manager" >}} 25 | 26 | 这些组件可以作为传统的操作系统服务（守护程序）或容器运行。运行这些组件的主机在历史上被称为 {{}}。 27 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/controller.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 控制器（Controller） 3 | id: controller 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/architecture/controller/ 6 | short_description: > 7 | 控制器通过 API 服务器监控集群的公共状态，并致力于将当前状态转变为期望的状态。 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | - fundamental 13 | --- 14 | 15 | 在 Kubernetes 中，控制器通过监控{{< glossary_tooltip text="集群" term_id="cluster" >}} 16 | 的公共状态，并致力于将当前状态转变为期望的状态。 17 | 18 | 19 | 控制器（{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的一部分） 20 | 通过 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}监控你的集群中的公共状态。 21 | 22 | 其中一些控制器是运行在控制平面内部的，对 Kubernetes 来说，他们提供核心控制操作。 23 | 比如：部署控制器（deployment controller）、守护控制器（daemonset controller）、 24 | 命名空间控制器（namespace controller）、持久化数据卷控制器（persistent volume controller）（等） 25 | 都是运行在 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 中的。 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cri-o.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: CRI-O 3 | id: cri-o 4 | date: 2019-05-14 5 | full_link: https://cri-o.io/#what-is-cri-o 6 | short_description: > 7 | 专用于 Kubernetes 的轻量级容器运行时软件 8 | 9 | aka: 10 | tags: 11 | - tool 12 | --- 13 | 该工具可让你通过 Kubernetes CRI 使用 OCI 容器运行时。 14 | 15 | 16 | CRI-O 是 {{< glossary_tooltip text="CRI" term_id="cri" >}} 的一种实现， 17 | 使得你可以使用与开放容器倡议（Open Container Initiative；OCI） 18 | [运行时规范](https://www.github.com/opencontainers/runtime-spec) 19 | 兼容的{{< glossary_tooltip text="容器" term_id="container" >}}。 20 | 21 | 部署 CRI-O 允许 Kubernetes 使用任何符合 OCI 要求的运行时作为容器运行时 22 | 去运行 {{< glossary_tooltip text="Pod" term_id="pod" >}}， 23 | 并从远程容器仓库获取 OCI 容器镜像。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cri.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器运行时接口（Container Runtime Interface；CRI） 3 | id: cri 4 | date: 2019-03-07 5 | full_link: /zh-cn/docs/concepts/overview/components/#container-runtime 6 | short_description: > 7 | 一组与 kubelet 集成的容器运行时 API 8 | 9 | 10 | aka: 11 | tags: 12 | - fundamental 13 | --- 14 | 15 | 容器运行时接口（Container Runtime Interface；CRI）是一组与节点上 kubelet 集成的容器运行时 API。 16 | 17 | 18 | 更多信息， 请参考 [容器运行时接口](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) API 与规格。 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/cronjob.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 周期调度任务（CronJob） 3 | id: cronjob 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/controllers/cron-jobs/ 6 | short_description: > 7 | 周期调度的任务（作业）。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - workload 13 | --- 14 | 15 | 管理定期运行的[任务](/zh-cn/docs/concepts/workloads/controllers/job/)。 16 | 17 | 18 | 与 **crontab** 文件中的一行命令类似，周期调度任务（CronJob）对象使用 19 | [cron](https://zh.wikipedia.org/wiki/Cron) 格式设置排期表。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/csi.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容器存储接口（Container Storage Interface；CSI） 3 | id: csi 4 | date: 2018-06-25 5 | full_link: /zh-cn/docs/concepts/storage/volumes/#csi 6 | short_description: > 7 | 容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。 8 | 9 | 10 | aka: 11 | tags: 12 | - storage 13 | --- 14 | 15 | 容器存储接口（Container Storage Interface；CSI）定义存储系统暴露给容器的标准接口。 16 | 17 | 18 | CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件， 19 | 而无需将这些插件的代码添加到 Kubernetes 代码仓库（外部插件）。 20 | 要使用某个存储提供商的 CSI 驱动，你首先要 21 | [将它部署到你的集群上](https://kubernetes-csi.github.io/docs/deploying.html)。 22 | 然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。 23 | 24 | * [Kubernetes 文档中关于 CSI 的描述](/zh-cn/docs/concepts/storage/volumes/#csi) 25 | * [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/drivers.html) 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/customresourcedefinition.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: CustomResourceDefinition 3 | id: CustomResourceDefinition 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ 6 | short_description: > 7 | 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - operation 13 | - extension 14 | --- 15 | 16 | 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 17 | 18 | 19 | 当 Kubernetes 公开支持的 API 资源不能满足你的需要时， 20 | 定制资源对象（Custom Resource Definitions）让你可以在你的环境上扩展 Kubernetes API。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/daemonset.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: DaemonSet 3 | id: daemonset 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/controllers/daemonset/ 6 | short_description: > 7 | 确保 Pod 的副本在集群中的一组节点上运行。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - core-object 13 | - workload 14 | --- 15 | 16 | 确保 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的副本在{{< glossary_tooltip text="集群" term_id="cluster" >}}中的一组节点上运行。 17 | 18 | 19 | 用来部署系统守护进程，例如日志搜集和监控代理，这些进程通常必须运行在每个{{< glossary_tooltip text="节点" term_id="node" >}}上。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/data-plane.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 数据平面（Data Plane） 3 | id: data-plane 4 | date: 2019-05-12 5 | full_link: 6 | short_description: > 7 | 提供诸如 CPU、内存、网络和存储的能力，以便容器可以运行并连接到网络。 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 13 | 提供诸如 CPU、内存、网络和存储的能力，以便容器可以运行并连接到网络。 14 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/deployment.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Deployment 3 | id: deployment 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/controllers/deployment/ 6 | short_description: > 7 | 管理集群上的多副本应用。 8 | aka: 9 | tags: 10 | - fundamental 11 | - core-object 12 | - workload 13 | --- 14 | 15 | 管理多副本应用的一种 API 对象，通常通过运行没有本地状态的 Pod 来完成工作。 16 | 17 | 18 | 每个副本表现为一个 {{}}， 19 | Pod 分布在集群中的{{}}上。 20 | 对于确实需要本地状态的工作负载，请考虑使用 {{}}。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/developer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 开发者（Developer） 3 | id: developer 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 指的是：应用开发者、代码贡献者、或平台开发者。 8 | 9 | aka: 10 | tags: 11 | - community 12 | - user-type 13 | --- 14 | 15 | 指的是：{{< glossary_tooltip text="应用开发者" term_id="application-developer" >}}、 16 | {{< glossary_tooltip text="代码贡献者" term_id="code-contributor" >}}、 17 | 或{{< glossary_tooltip text="平台开发者" term_id="platform-developer" >}}。 18 | 19 | 20 | 根据上下文的不同，“开发者”这个被多处使用的词条会有不同的含义。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/device-plugin.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 设备插件（Device Plugin） 3 | id: device-plugin 4 | date: 2019-02-02 5 | full_link: /zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ 6 | short_description: > 7 | 一种软件扩展，可以使 Pod 访问由特定厂商初始化或者安装的设备。 8 | aka: 9 | tags: 10 | - fundamental 11 | - extension 12 | --- 13 | 14 | 设备插件在工作{{}}上运行并为 15 | {{}} 提供访问资源的能力， 16 | 例如：本地硬件这类资源需要特定于供应商的初始化或安装步骤。 17 | 18 | 19 | 设备插件向 {{}} 公布资源，以便工作负载 20 | Pod 访问 Pod 运行所在节点上的硬件功能特性。 21 | 你可以将设备插件部署为 {{}}， 22 | 或者直接在每个目标节点上安装设备插件软件。 23 | 24 | 更多信息请查阅[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 25 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/disruption.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 干扰（Disruption） 3 | id: disruption 4 | date: 2019-09-10 5 | full_link: /zh-cn/docs/concepts/workloads/pods/disruptions/ 6 | short_description: > 7 | 导致 Pod 服务停止的事件。 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 13 | 干扰（Disruption）是指导致一个或者多个 {{< glossary_tooltip term_id="pod" text="Pod" >}} 服务停止的事件。 14 | 干扰会影响依赖于受影响的 Pod 的资源，例如 {{< glossary_tooltip term_id="deployment" >}}。 15 | 16 | 17 | 如果你作为一个集群操作人员，销毁了一个从属于某个应用的 Pod， 18 | Kubernetes 视之为**自愿干扰（Voluntary Disruption）**。 19 | 如果由于节点故障或者影响更大区域故障的断电导致 Pod 离线， 20 | Kubernetes 视之为**非愿干扰（Involuntary Disruption）**。 21 | 22 | 更多信息请查阅[干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/)。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/docker.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Docker 3 | id: docker 4 | date: 2018-04-12 5 | full_link: https://docs.docker.com/engine/ 6 | short_description: > 7 | Docker 是一种可以提供操作系统级别虚拟化（也称作容器）的软件技术。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | Docker（这里特指 Docker Engine）是一种可以提供操作系统级别虚拟化 15 | （也称作{{< glossary_tooltip text="容器" term_id="container" >}}）的软件技术。 16 | 17 | 18 | Docker 使用了 Linux 内核中的资源隔离特性（如 cgroup 和内核命名空间）以及支持联合文件系统（如 OverlayFS 和其他）， 19 | 允许多个相互独立的“容器”一起运行在同一 Linux 实例上，从而避免启动和维护虚拟机（Virtual Machines；VM）的开销。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/dockershim.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Dockershim 3 | id: dockershim 4 | date: 2022-04-15 5 | full_link: /zh-cn/dockershim 6 | short_description: > 7 | dockershim 是 Kubernetes v1.23 及之前版本中的一个组件，Kubernetes 系统组件通过它与 Docker Engine 通信。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | dockershim 是 Kubernetes v1.23 及之前版本中的一个组件。 15 | Kubernetes 系统组件通过它与 {{< glossary_tooltip text="Docker Engine" term_id="docker" >}}通信。 16 | 17 | 18 | 从 Kubernetes v1.24 开始，dockershim 已从 Kubernetes 中移除。 19 | 想了解更多信息，可参考[移除 Dockershim 的常见问题](/zh-cn/dockershim)。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/downstream.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 下游（Downstream） 3 | id: downstream 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 可以指：Kubernetes 生态系统中依赖于核心 Kubernetes 代码库或分支代码库的代码。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 可以指：Kubernetes 生态系统中依赖于核心 Kubernetes 代码库或分支代码库的代码。 15 | 16 | 17 | * 在 **Kubernetes 社区**中：**下游(downstream)**在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如，Kubernetes 的一个新特性可以被**下游(downstream)**应用采用，以提升它们的功能性。 18 | * 在 **GitHub** 或 **git** 中：约定用**下游(downstream)**表示分支代码库，源代码库被认为是**上游(upstream)**。 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/downward-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Downward API 3 | id: downward-api 4 | date: 2022-03-21 5 | short_description: > 6 | 将 Pod 和容器字段值暴露给容器中运行的代码的机制。 7 | aka: 8 | full_link: /docs/concepts/workloads/pods/downward-api/ 9 | tags: 10 | - architecture 11 | --- 12 | 13 | Kubernetes 将 Pod 和容器字段值暴露给容器中运行的代码的机制。 14 | 15 | 16 | 在不需要修改容器代码的前提下让容器拥有关于自身的信息是很有用的。修改代码可能使容器直接耦合到 Kubernetes。 17 | 18 | Kubernetes Downward API 允许容器使用它们自己或它们在 Kubernetes 集群中所处环境的信息。 19 | 容器中的应用程序可以访问该信息，而不需要以 Kubernetes API 客户端的形式执行操作。 20 | 21 | 有两种方法可以将 Pod 和容器字段暴露给正在运行的容器： 22 | 23 | * 使用[环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) 24 | * 使用 [`downwardAPI` 卷](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 25 | 26 | 这两种暴露 Pod 和容器字段的方式统称为 **Downward API**。 27 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/dynamic-volume-provisioning.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 动态卷制备（Dynamic Volume Provisioning） 3 | id: dynamicvolumeprovisioning 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/storage/dynamic-provisioning/ 6 | short_description: > 7 | 允许用户请求自动创建存储卷。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - storage 13 | --- 14 | 15 | 允许用户请求自动创建存储{{< glossary_tooltip text="卷" term_id="volume" >}}。 16 | 17 | 18 | 动态制备让集群管理员无需再预先制备存储。这种机制转为通过用户请求自动地制备存储。 19 | 动态卷制备是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的， 20 | StorageClass 可以引用{{< glossary_tooltip text="卷插件（Volume Plugin）" term_id="volume-plugin" >}} 21 | 提供的{{< glossary_tooltip text="卷" term_id="volume" >}}， 22 | 也可以引用传递给卷插件的参数集。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/endpoint-slice.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: EndpointSlice 3 | id: endpoint-slice 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/services-networking/endpoint-slices/ 6 | short_description: > 7 | 一种将网络端点与 Kubernetes 资源组合在一起的方法。 8 | 9 | aka: 10 | tags: 11 | - networking 12 | --- 13 | 14 | 一种将网络端点与 Kubernetes 资源组合在一起的方法。 15 | 16 | 17 | 一种将网络端点组合在一起的可扩缩、可扩展方式。 18 | 它们将被 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 用于在 19 | 每个 {{< glossary_tooltip text="节点" term_id="node">}} 上建立网络路由。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/endpoint.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 端点（Endpoints） 3 | id: endpoints 4 | date: 2020-04-23 5 | full_link: 6 | short_description: > 7 | 端点负责记录与服务（Service）的选择器相匹配的 Pod 的 IP 地址。 8 | 9 | aka: 10 | tags: 11 | - networking 12 | --- 13 | 14 | 端点负责记录与服务的{{< glossary_tooltip text="选择器" term_id="selector" >}}相匹配的 Pod 的 IP 地址。 15 | 16 | 17 | 端点可以手动配置到{{< glossary_tooltip text="服务（Service）" term_id="service" >}}上，而不必指定选择器标识。 18 | 19 | {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} 提供了一种可伸缩、可扩展的替代方案。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/ephemeral-container.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 临时容器（Ephemeral Container） 3 | id: ephemeral-container 4 | date: 2019-08-26 5 | full_link: /zh-cn/docs/concepts/workloads/pods/ephemeral-containers/ 6 | short_description: > 7 | 你可以在 Pod 中临时运行的一种容器类型 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 13 | 你可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型。 14 | 15 | 16 | 如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器（Ephemeral Container）并进行诊断。 17 | 临时容器没有资源或调度保证，因此不应该使用它们来运行工作负载本身的任何部分。 18 | 19 | {{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}} 不支持临时容器。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/etcd.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: etcd 3 | id: etcd 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/ 6 | short_description: > 7 | 一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | - storage 13 | --- 14 | 15 | 一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。 16 | 17 | 18 | 如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 19 | 请确保你针对这些数据有一份 20 | [备份](/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。 21 | 22 | 你可以在官方[文档](https://etcd.io/docs/)中找到有关 etcd 的深入知识。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/event.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 事件（Event） 3 | id: event 4 | date: 2022-01-16 5 | full_link: /zh-cn/docs/reference/kubernetes-api/cluster-resources/event-v1/ 6 | short_description: > 7 | 对集群中某处所发生事件的报告。通常用来表述系统中某种状态变更。 8 | aka: 9 | tags: 10 | - core-object 11 | - fundamental 12 | --- 13 | 14 | 每个 Event 是{{< glossary_tooltip text="集群" term_id="cluster" >}}中某处所发生事件的报告。 15 | 它通常用来表述系统中的某种状态变更。 16 | 17 | 18 | 事件的保留时间有限，随着时间推进，其触发方式和消息都可能发生变化。 19 | 事件用户不应该对带有给定原因（反映下层触发源）的时间特征有任何依赖， 20 | 也不要寄希望于该原因所造成的事件会一直存在。 21 | 22 | 事件应该被视为一种告知性质的、尽力而为的、补充性质的数据。 23 | 24 | 在 Kubernetes 中，[审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/) 25 | 机制会生成一种不同类别的 Event 记录（API 组为 `audit.k8s.io`）。 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/eviction.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 驱逐（Eviction） 3 | id: eviction 4 | date: 2021-05-08 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/ 6 | short_description: > 7 | 终止节点上一个或多个 Pod 的过程。 8 | aka: 9 | tags: 10 | - operation 11 | --- 12 | 13 | 驱逐（Eviction）即终止节点上一个或多个 Pod 的过程。 14 | 15 | 16 | 驱逐的两种类型： 17 | * [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) 18 | * [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/) 19 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/extensions.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 扩展组件（Extensions） 3 | id: Extensions 4 | date: 2019-02-01 5 | full_link: /zh-cn/docs/concepts/extend-kubernetes/#extensions 6 | short_description: > 7 | 扩展组件（Extensions）是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。 8 | aka: 9 | tags: 10 | - fundamental 11 | - extension 12 | --- 13 | 14 | 扩展组件（Extensions）是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。 15 | 16 | 17 | 许多集群管理员会使用托管的 Kubernetes 或其某种发行包，这些集群预装了扩展组件。 18 | 因此，大多数 Kubernetes 用户将不需要安装[扩展组件](/zh-cn/docs/concepts/extend-kubernetes/)， 19 | 需要编写新的扩展组件的用户就更少了。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/feature-gates.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 特性门控（Feature gate） 3 | id: feature-gate 4 | date: 2023-01-12 5 | full_link: /zh-cn/docs/reference/command-line-tools-reference/feature-gates/ 6 | short_description: > 7 | 一种控制是否启用某特定 Kubernetes 特性的方法。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - operation 13 | --- 14 | 15 | 特性门控是一组键（非透明的字符串值），你可以用它来控制在你的集群中启用哪些 Kubernetes 特性。 16 | 17 | 18 | 你可以在每个 Kubernetes 组件中使用 `--feature-gates` 命令行标志来开启或关闭这些特性。 19 | 每个 Kubernetes 组件都可以让你开启或关闭一组与该组件相关的特性门控。 20 | Kubernetes 文档列出了当前所有的[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)及其控制的内容。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/finalizer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Finalizer 3 | id: finalizer 4 | date: 2021-07-07 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/finalizers/ 6 | short_description: > 7 | 一个带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 8 | 再完全删除被标记为删除的资源。 9 | aka: 10 | tags: 11 | - fundamental 12 | - operation 13 | --- 14 | 15 | Finalizer 是带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 16 | 再完全删除被标记为删除的资源。 17 | Finalizer 提醒{{}}清理被删除的对象拥有的资源。 18 | 19 | 20 | 当你告诉 Kubernetes 删除一个指定了 Finalizer 的对象时， 21 | Kubernetes API 通过填充 `.metadata.deletionTimestamp` 来标记要删除的对象， 22 | 并返回 `202` 状态码(HTTP "已接受") 使其进入只读状态。 23 | 此时控制平面或其他组件会采取 Finalizer 所定义的行动， 24 | 而目标对象仍然处于终止中（Terminating）的状态。 25 | 这些行动完成后，控制器会删除目标对象相关的 Finalizer。 26 | 当 `metadata.finalizers` 字段为空时，Kubernetes 认为删除已完成并删除对象。 27 | 28 | 你可以使用 Finalizer 控制资源的{{}}。 29 | 例如，你可以定义一个 Finalizer，在删除目标资源前清理相关资源或基础设施。 30 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/flexvolume.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: FlexVolume 3 | id: flexvolume 4 | date: 2018-06-25 5 | full_link: /zh-cn/docs/concepts/storage/volumes/#flexvolume 6 | short_description: > 7 | FlexVolume 是一个已弃用的接口，用于创建树外卷插件。 8 | {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 9 | 是一个更新的接口，它解决了 FlexVolume 的一些问题。 10 | 11 | aka: 12 | tags: 13 | - storage 14 | --- 15 | 16 | FlexVolume 是一个已弃用的接口，用于创建树外卷插件。 17 | {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 18 | 是一个更新的接口，它解决了 FlexVolume 的一些问题。 19 | 20 | 21 | FlexVolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。 22 | FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。 23 | 这需要 root 权限。如果可能的话，SIG Storage 建议实现 24 | {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序， 25 | 因为它解决了 FlexVolume 的限制。 26 | 27 | * [Kubernetes 文档中的 FlexVolume](/zh-cn/docs/concepts/storage/volumes/#flexvolume) 28 | * [更多关于 FlexVolume 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 29 | * [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) 30 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/garbage-collection.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 垃圾收集（Garbage Collection） 3 | id: garbage-collection 4 | date: 2021-07-07 5 | full_link: /zh-cn/docs/concepts/architecture/garbage-collection/ 6 | short_description: > 7 | Kubernetes 用于清理集群资源的各种机制的统称。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - operation 13 | --- 14 | 15 | 垃圾收集（Garbage Collection）是 Kubernetes 用于清理集群资源的各种机制的统称。 16 | 17 | 18 | Kubernetes 使用垃圾收集机制来清理资源，例如： 19 | [未使用的容器和镜像](/zh-cn/docs/concepts/architecture/garbage-collection/#containers-images)、 20 | [失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)、 21 | [目标资源拥有的对象](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)、 22 | [已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)、 23 | 过期或出错的资源。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/helm-chart.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Helm Chart 3 | id: helm-chart 4 | date: 2018-04-12 5 | full_link: https://helm.sh/docs/topics/charts/ 6 | short_description: > 7 | Helm Chart 是一组预先配置的 Kubernetes 资源所构成的包，可以使用 Helm 工具对其进行管理。 8 | 9 | aka: 10 | tags: 11 | - tool 12 | --- 13 | 14 | Helm Chart 是一组预先配置的 Kubernetes 资源所构成的包，可以使用 Helm 工具对其进行管理。 15 | 16 | 17 | Chart 提供了一种可重现的用来创建和共享 Kubernetes 应用的方法。 18 | 单个 Chart 可用来部署简单的系统（例如：memcached Pod）， 19 | 也可以用来部署复杂的系统（例如：HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈）。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/horizontal-pod-autoscaler.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Pod 水平自动扩缩器（Horizontal Pod Autoscaler） 3 | id: horizontal-pod-autoscaler 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/ 6 | short_description: > 7 | Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 8 | 9 | aka: 10 | - HPA 11 | tags: 12 | - operation 13 | --- 14 | 15 | Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 {{< glossary_tooltip term_id="pod" >}} 副本的数量。 16 | 17 | 18 | HPA 通常用于 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}} 19 | 、{{< glossary_tooltip text="Deployment" term_id="deployment" >}} 20 | 或者 {{< glossary_tooltip text="ReplicaSet" term_id="replica-set" >}} 上。 21 | HPA 不能用于不支持扩缩的对象，例如 {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/host-aliases.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: HostAliases 3 | id: HostAliases 4 | date: 2019-01-31 5 | full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core 6 | short_description: > 7 | 主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 Pod 内的 hosts 文件。 8 | 9 | aka: 10 | tags: 11 | - operation 12 | --- 13 | 14 | 主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 {{< glossary_tooltip text="Pod" term_id="pod" >}} 内的 hosts 文件。 15 | 16 | 17 | 18 | [HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) 19 | 是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。 20 | 该选项仅适用于没有配置 hostNetwork 的 Pod。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/image.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 镜像（Image） 3 | id: image 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 镜像（Image）是保存的容器实例，它打包了应用运行所需的一组软件。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 镜像（Image）是保存的{{< glossary_tooltip text="容器" term_id="container" >}}实例，它打包了应用运行所需的一组软件。 16 | 17 | 18 | 镜像是软件打包的一种方式，可以将镜像存储在容器镜像仓库、拉取到本地系统并作为应用来运行。 19 | 镜像中包含的元数据指明了运行什么可执行程序、是由谁构建的以及其他信息。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 词汇表 3 | layout: glossary 4 | noedit: true 5 | default_active_tag: fundamental 6 | weight: 5 7 | card: 8 | name: reference 9 | weight: 10 10 | title: 词汇表 11 | --- 12 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/ingress.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Ingress 3 | id: ingress 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/services-networking/ingress/ 6 | short_description: > 7 | Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 8 | 9 | aka: 10 | tags: 11 | - networking 12 | - architecture 13 | - extension 14 | --- 15 | 16 | Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 17 | 18 | 19 | Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/init-container.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Init 容器（Init Container） 3 | id: init-container 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 应用容器运行前必须先运行完成的一个或多个 Init 容器（Init Container）。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 应用{{< glossary_tooltip text="容器" term_id="container" >}}运行前必须先运行完成的一个或多个 Init 容器（Init Container）。 16 | 17 | 18 | Init 容器像常规应用容器一样，只有一点不同：Init 容器必须在应用容器启动前运行完成。 19 | Init 容器的运行顺序：一个 Init 容器必须在下一个 Init 容器开始前运行完成。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/istio.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Istio 3 | id: istio 4 | date: 2018-04-12 5 | full_link: https://istio.io/latest/about/service-mesh/#what-is-istio 6 | short_description: > 7 | Istio 是一个（非 Kubernetes 特有的）开放平台，提供了一种统一的方式来集成微服务、管理流量、实施策略和汇总度量数据。 8 | aka: 9 | tags: 10 | - networking 11 | - architecture 12 | - extension 13 | --- 14 | 15 | Istio 是一个（非 Kubernetes 特有的）开放平台，提供了一种统一的方式来集成微服务、管理流量、实施策略和汇总度量数据。 16 | 17 | 18 | 添加 Istio 时不需要修改应用代码。它是基础设施的一层，介于服务和网络之间。 19 | 当它和服务的 Deployment 相结合时，就构成了通常所谓的服务网格（Service Mesh）。 20 | Istio 的控制面抽象掉了底层的集群管理平台，这一集群管理平台可以是 Kubernetes、Mesosphere 等。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/job.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Job 3 | id: job 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/controllers/job/ 6 | short_description: > 7 | Job 是需要运行完成的确定性的或批量的任务。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - core-object 13 | - workload 14 | --- 15 | 16 | 17 | Job 是需要运行完成的确定性的或批量的任务。 18 | 19 | 20 | 创建一个或多个 {{< glossary_tooltip term_id="Pod" >}} 对象，并确保指定数量的 Pod 成功终止。 21 | 随着各 Pod 成功结束，Job 会跟踪记录成功完成的个数。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/jwt.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: JSON Web 令牌 (JWT) 3 | id: jwt 4 | date: 2023-01-17 5 | full_link: https://www.rfc-editor.org/rfc/rfc7519 6 | short_description: > 7 | JWT 是用来表示在两方之间所转移的权限声明的一种方式。 8 | 9 | aka: 10 | tags: 11 | - security 12 | - architecture 13 | --- 14 | 15 | JWT 是用来表示在两方之间所转移的权限声明的一种方式。 16 | 17 | 18 | JWT 可以用数字方式签名和加密。 19 | Kubernetes 将 JWT 用作身份验证令牌，以验证想要在集群中执行一些操作的实体的身份。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kops.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kOps (Kubernetes Operations) 3 | id: kops 4 | date: 2018-04-12 5 | full_link: /docs/setup/production-environment/kops/ 6 | short_description: > 7 | kOps 不仅会帮助你创建、销毁、升级和维护生产级、高可用性的 Kubernetes 集群， 8 | 还会提供必要的云基础设施。 9 | 10 | aka: 11 | tags: 12 | - tool 13 | - operation 14 | --- 15 | 16 | `kOps` 不仅会帮助你创建、销毁、升级和维护生产级、高可用性的 Kubernetes 集群， 17 | 还会提供必要的云基础设施。 18 | 19 | 20 | {{< note >}} 21 | 目前正式支持 AWS（Amazon Web Services），DigitalOcean、GCE 和 OpenStack 22 | 处于 beta 支持阶段，Azure 处于 alpha 阶段。 23 | {{< /note >}} 24 | 25 | `kOps` 是一个自动化的制备系统： 26 | * 全自动安装流程 27 | * 使用 DNS 识别集群 28 | * 自我修复：一切都在自动扩缩组中运行 29 | * 支持多种操作系统（Amazon Linux、Debian、Flatcar、RHEL、Rocky 和 Ubuntu） 30 | * 支持高可用 31 | * 可以直接提供或者生成 terraform 清单 -------------------------------------------------------------------------------- /contents/website/reference/glossary/kube-apiserver.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: API 服务器 3 | id: kube-apiserver 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/components/#kube-apiserver 6 | short_description: > 7 | 提供 Kubernetes API 服务的控制面组件。 8 | 9 | aka: 10 | - kube-apiserver 11 | tags: 12 | - architecture 13 | - fundamental 14 | --- 15 | 16 | API 服务器是 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， 17 | 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 18 | API 服务器是 Kubernetes 控制平面的前端。 19 | 20 | 21 | Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)。 22 | `kube-apiserver` 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 23 | 你可以运行 `kube-apiserver` 的多个实例，并在这些实例之间平衡流量。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kube-controller-manager.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kube-controller-manager 3 | id: kube-controller-manager 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/ 6 | short_description: > 7 | 主节点上运行控制器的组件。 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | - fundamental 13 | --- 14 | 15 | [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 16 | 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， 17 | 负责运行{{< glossary_tooltip text="控制器" term_id="controller" >}}进程。 18 | 19 | 20 | 从逻辑上讲， 21 | 每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程， 22 | 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。 23 | 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kube-proxy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kube-proxy 3 | id: kube-proxy 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-proxy/ 6 | short_description: > 7 | `kube-proxy` 是集群中每个节点上运行的网络代理。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - networking 13 | --- 14 | [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 15 | 是集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}上所运行的网络代理， 16 | 实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。 17 | 18 | 19 | kube-proxy 维护节点上的一些网络规则， 20 | 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。 21 | 22 | 如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 23 | 否则，kube-proxy 仅做流量转发。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kube-scheduler.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kube-scheduler 3 | id: kube-scheduler 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/ 6 | short_description: > 7 | 控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | - scheduler 13 | --- 14 | 15 | 16 | 17 | `kube-scheduler` 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， 18 | 负责监视新创建的、未指定运行{{< glossary_tooltip term_id="node" text="节点（node）">}}的 {{< glossary_tooltip term_id="pod" text="Pods" >}}， 19 | 并选择节点来让 Pod 在上面运行。 20 | 21 | 22 | 23 | 调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 24 | 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。 25 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kubeadm.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubeadm 3 | id: kubeadm 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/reference/setup-tools/kubeadm/ 6 | short_description: > 7 | 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 8 | 9 | aka: 10 | tags: 11 | - tool 12 | - operation 13 | --- 14 | 15 | 16 | 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 17 | 18 | 19 | 你可以使用 kubeadm 安装控制面和 20 | {{< glossary_tooltip text="工作节点" term_id="node" >}} 21 | 组件。 22 | 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kubectl.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubectl 3 | id: kubectl 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/reference/kubectl/ 6 | short_description: > 7 | kubectl 是用来和 Kubernetes 集群进行通信的命令行工具。 8 | 9 | aka: 10 | - kubectl 11 | tags: 12 | - tool 13 | - fundamental 14 | --- 15 | 16 | 17 | 18 | kubectl 是使用 Kubernetes API 与 Kubernetes 19 | 集群的{{}}进行通信的命令行工具。 20 | 21 | 22 | 你可以使用 `kubectl` 创建、检视、更新和删除 Kubernetes 对象。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kubelet.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubelet 3 | id: kubelet 4 | date: 2018-04-12 5 | full_link: /docs/reference/generated/kubelet 6 | short_description: > 7 | 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | `kubelet` 会在集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}上运行。 15 | 它保证{{< glossary_tooltip text="容器（containers）" term_id="container" >}}都运行在 16 | {{< glossary_tooltip text="Pod" term_id="pod" >}} 中。 17 | 18 | 19 | kubelet 接收一组通过各类机制提供给它的 PodSpecs， 20 | 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 21 | kubelet 不会管理不是由 Kubernetes 创建的容器。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/kubernetes-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubernetes API 3 | id: kubernetes-api 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/kubernetes-api/ 6 | short_description: > 7 | Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - architecture 13 | --- 14 | 15 | 16 | 17 | Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。 18 | 19 | 20 | 21 | Kubernetes 资源和"意向记录"都是作为 API 对象储存的，并可以通过调用 RESTful 风格的 API 进行修改。 22 | API 允许以声明方式管理配置。 23 | 用户可以直接和 Kubernetes API 交互，也可以通过 `kubectl` 这样的工具进行交互。 24 | 核心的 Kubernetes API 是很灵活的，可以扩展以支持定制资源。 25 | 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/label.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 标签（Label） 3 | id: label 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/labels/ 6 | short_description: > 7 | 用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 16 | 用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。 17 | 18 | 19 | 20 | 标签是一些关联到 {{< glossary_tooltip text="Pods" term_id="pod" >}} 这类对象上的键值对。 21 | 它们通常用来组织和选择对象子集。 22 | 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/limitrange.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: LimitRange 3 | id: limitrange 4 | date: 2019-04-15 5 | full_link: /docs/concepts/policy/limit-range/ 6 | short_description: > 7 | 提供约束来限制命名空间中每个容器或 Pod 的资源消耗。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - fundamental 13 | - architecture 14 | related: 15 | - pod 16 | - container 17 | 18 | --- 19 | 20 | 21 | 提供约束来限制命名空间中每个 {{< glossary_tooltip text="容器（Containers）" term_id="container" >}} 或 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的资源消耗。 22 | 23 | LimitRange 按照类型来限制命名空间中对象能够创建的数量，以及单个 {{< glossary_tooltip text="容器（Containers）" term_id="container" >}} 或 {{< glossary_tooltip text="Pod" term_id="pod" >}} 可以请求/使用的计算资源量。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/logging.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 日志（Logging） 3 | id: logging 4 | date: 2019-04-04 5 | full_link: /zh-cn/docs/concepts/cluster-administration/logging/ 6 | short_description: > 7 | 日志是集群或应用程序记录的事件列表。 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | - fundamental 13 | --- 14 | 日志是 {{< glossary_tooltip text="集群（cluster）" term_id="cluster" >}} 或应用程序记录的事件列表。 15 | 16 | 17 | 18 | 19 | 应用程序和系统日志可以帮助你了解集群内部发生的情况。日志对于调试问题和监视集群活动非常有用。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/managed-service.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 托管服务 3 | id: managed-service 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 由第三方供应商负责维护的一种软件产品。 8 | 9 | aka: 10 | tags: 11 | - extension 12 | --- 13 | 14 | 15 | 由第三方供应商负责维护的一种软件产品。 16 | 17 | 18 | 托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等， 19 | 不过它们也可以是可以被某应用使用的任何软件交付件。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/manifest.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 清单（Manifest） 3 | id: manifest 4 | date: 2019-06-28 5 | short_description: > 6 | 一个或多个 Kubernetes API 对象的序列化规范。 7 | 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | JSON 或 YAML 格式的 Kubernetes API 对象规范。 13 | 14 | 15 | 16 | 清单指定了在应用该清单时 kubernetes 将维护的对象的期望状态。每个配置文件可包含多个清单。 17 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/master.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Master 3 | id: master 4 | date: 2020-04-16 5 | short_description: > 6 | 遗留术语，作为运行控制平面的节点的同义词使用。 7 | 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 遗留术语，作为运行 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 的 {{< glossary_tooltip text="节点" term_id="node" >}} 的同义词使用。 13 | 14 | 15 | 16 | 该术语仍被一些配置工具使用，如 {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} 以及托管的服务，为 {{< glossary_tooltip text="节点（nodes）" term_id="node" >}} 添加 `kubernetes.io/role` 的 {{< glossary_tooltip text="标签（label）" term_id="label" >}}，以及管理控制平面 Pod 的调度。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/member.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 成员（Member） 3 | id: member 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | K8s 社区中持续活跃的贡献者。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 15 | 16 | K8s 社区中持续活跃的{{< glossary_tooltip text="贡献者（contributor）" term_id="contributor" >}}。 17 | 18 | 19 | 20 | 可以将问题单（issue）和 PR 指派给成员（Member），成员（Member）也可以通过 GitHub 小组加入 {{< glossary_tooltip text="特别兴趣小组 (SIGs)" term_id="sig" >}}。针对成员（Member）所提交的 PR，系统自动运行提交前测试。成员（Member）应该是持续活跃的社区贡献者。 21 | 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/minikube.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Minikube 3 | id: minikube 4 | date: 2018-04-12 5 | full_link: /docs/getting-started-guides/minikube/ 6 | short_description: > 7 | Minikube 是用来在本地运行 Kubernetes 的一种工具。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - tool 13 | --- 14 | 15 | 16 | 17 | Minikube 是用来在本地运行 Kubernetes 的一种工具。 18 | 19 | 20 | 21 | Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 22 | 你可以使用 Minikube 23 | [在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/)。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/mirror-pod.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 镜像 Pod（Mirror Pod） 3 | id: 静态-pod 4 | date: 2019-08-06 5 | short_description: > 6 | API 服务器中的一个对象，用于跟踪 kubelet 上的静态 pod。 7 | 8 | aka: 9 | tags: 10 | - 基本的 11 | --- 12 | 13 | 镜像 Pod（Mirror Pod）是被 kubelet 用来代表{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}} 的 14 | {{< glossary_tooltip text="pod" term_id="pod" >}} 对象。 15 | 16 | 17 | 当 kubelet 在其配置中发现一个静态容器时， 18 | 它会自动地尝试在 Kubernetes API 服务器上为它创建 Pod 对象。 19 | 这意味着 pod 在 API 服务器上将是可见的，但不能在其上进行控制。 20 | 21 | （例如，删除镜像 Pod 也不会阻止 kubelet 守护进程继续运行它）。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/name.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 名称（Name） 3 | id: name 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/names/ 6 | short_description: > 7 | 客户端提供的字符串，用来指代资源 URL 中的对象，如 `/api/v1/pods/some-name`。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 16 | 客户端提供的字符串，引用资源 URL 中的对象，如`/api/v1/pods/some name`。 17 | 18 | 19 | 20 | 某一时刻，只能有一个给定类型的对象具有给定的名称。但是，如果删除该对象，则可以创建同名的新对象。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/namespace.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 名字空间（Namespace） 3 | id: namespace 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/namespaces/ 6 | short_description: > 7 | 名字空间是 Kubernetes 用来支持隔离单个集群中的资源组的一种抽象。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 16 | 名字空间是 Kubernetes 用来支持隔离单个 {{< glossary_tooltip text="集群" term_id="cluster" >}}中的资源组的一种抽象。 17 | 18 | 19 | 20 | 名字空间用来组织集群中对象，并为集群资源划分提供了一种方法。 21 | 同一名字空间内的资源名称必须唯一，但跨名字空间时不作要求。 22 | 基于名字空间的作用域限定仅适用于名字空间作用域的对象（例如 Deployment、Services 等）， 23 | 而不适用于集群作用域的对象（例如 StorageClass、Node、PersistentVolume 等）。 24 | 在一些文档里名字空间也称为命名空间。 25 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/network-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 网络策略 3 | id: network-policy 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/services-networking/network-policies/ 6 | short_description: > 7 | 网络策略是一种规范，规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。 8 | 9 | aka: 10 | tags: 11 | - networking 12 | - architecture 13 | - extension 14 | --- 15 | 16 | 17 | 网络策略是一种规范，规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。 18 | 19 | 20 | 21 | 网络策略帮助你声明式地配置允许哪些 Pod 之间、哪些命名空间之间允许进行通信， 22 | 并具体配置了哪些端口号来执行各个策略。`NetworkPolicy` 资源使用标签来选择 Pod， 23 | 并定义了所选 Pod 可以接受什么样的流量。网络策略由网络提供商提供的并被 Kubernetes 支持的网络插件实现。 24 | 请注意，当没有控制器实现网络资源时，创建网络资源将不会生效。 25 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/node-pressure-eviction.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 节点压力驱逐 3 | id: node-pressure-eviction 4 | date: 2021-05-13 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/ 6 | short_description: > 7 | 节点压力驱逐是 kubelet 主动使 Pod 失败以回收节点上的资源的过程。 8 | aka: 9 | - kubelet eviction 10 | tags: 11 | - operation 12 | --- 13 | 14 | 节点压力驱逐是 {{}} 主动终止 Pod 以回收节点上资源的过程。 15 | 16 | 17 | kubelet 监控集群节点上的 CPU、内存、磁盘空间和文件系统 inode 等资源。 18 | 当这些资源中的一个或多个达到特定消耗水平时， 19 | kubelet 可以主动使节点上的一个或多个 Pod 失效，以回收资源并防止饥饿。 20 | 21 | 节点压力驱逐不用于 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/node.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 节点（Node） 3 | id: node 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/architecture/nodes/ 6 | short_description: > 7 | Kubernetes 中的工作机器称作节点。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | Kubernetes 中的工作机器称作节点。 16 | 17 | 18 | 工作机器可以是虚拟机也可以是物理机，取决于集群的配置。 19 | 其上部署了运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 20 | 所必需的本地守护进程或服务，并由主控组件来管理。 21 | 节点上的守护进程包括 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、 22 | {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 23 | 以及一个 {{< glossary_tooltip term_id="docker" >}} 这种 24 | 实现了 {{< glossary_tooltip text="CRI" term_id="cri" >}} 25 | 的容器运行时。 26 | 27 | 在早期的 Kubernetes 版本中，节点也称作 "Minions"。 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/object.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 对象（Object） 3 | id: object 4 | date: 2020-10-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/#kubernetes-objects 6 | short_description: > 7 | Kubernetes 系统中的实体，代表了集群的部分状态。 8 | aka: 9 | tags: 10 | - fundamental 11 | --- 12 | 13 | Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。 14 | 15 | Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes 16 | {{< glossary_tooltip text="控制平面（Control Plane）" term_id="control-plane" >}} 17 | 不断工作，以确保它代表的项目确实存在。 18 | 创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/operator-pattern.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Operator 模式 3 | id: operator-pattern 4 | date: 2019-05-21 5 | full_link: /zh-cn/docs/concepts/extend-kubernetes/operator/ 6 | short_description: > 7 | 一种用于管理自定义资源的专用控制器 8 | 9 | aka: 10 | tags: 11 | - architecture 12 | --- 13 | 14 | [operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计， 15 | 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 16 | 17 | 除了使用作为 Kubernetes 自身一部分的内置控制器之外，你还可以通过 18 | 将控制器添加到集群中来扩展 Kubernetes。 19 | 20 | 如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控 21 | 那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。 22 | 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/persistent-volume-claim.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 持久卷申领（Persistent Volume Claim） 3 | id: persistent-volume-claim 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims 6 | short_description: > 7 | 声明在持久卷中定义的存储资源，以便可以将其挂载为容器中的卷。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - storage 13 | --- 14 | 15 | 16 | 申领{{< glossary_tooltip text="持久卷（PersistentVolume）" term_id="persistent-volume" >}} 17 | 中定义的存储资源，以便可以将其挂载为{{< glossary_tooltip text="容器（container）" term_id="container" >}}中的卷。 18 | 19 | 20 | 指定存储的数量，如何访问存储（只读、读写或独占）以及如何回收存储（保留、回收或删除）。 21 | 存储本身的详细信息在 PersistentVolume 对象中。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/persistent-volume.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 持久卷（Persistent Volume） 3 | id: persistent-volume 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/storage/persistent-volumes/ 6 | short_description: > 7 | 持久卷是代表集群中一块存储空间的 API 对象。 8 | 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。 9 | 10 | aka: 11 | tags: 12 | - core-object 13 | - storage 14 | --- 15 | 16 | 持久卷是代表集群中一块存储空间的 API 对象。它是通用的、可插拔的、并且不受单个 17 | {{< glossary_tooltip text="Pod" term_id="pod" >}} 生命周期约束的持久化资源。 18 | 19 | 20 | 持久卷（PersistentVolumes，PV）提供了一个 API，该 API 对存储的供应方式细节进行抽象，令其与使用方式相分离。 21 | 在提前创建存储（静态供应）的场景中，PV 可以直接使用。 22 | 在按需提供存储（动态供应）的场景中，需要使用 PersistentVolumeClaims (PVC)。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/platform-developer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 平台开发人员（Platform Developer） 3 | id: platform-developer 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 定制 Kubernetes 平台以满足自己的项目需求的人。 8 | 9 | aka: 10 | tags: 11 | - user-type 12 | --- 13 | 14 | 15 | 16 | 定制 Kubernetes 平台以满足自己的项目需求的人。 17 | 18 | 19 | 20 | 平台开发人员可以使用[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 21 | 或[使用汇聚层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 22 | 来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。 23 | 一些平台开发人员也是 kubernetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}， 24 | 他们会开发贡献给 Kubernetes 社区的扩展。 25 | 另一些平台开发人员则开发封闭源代码的商业扩展或用于特定网站的扩展。 26 | 27 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/pod-disruption-budget.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: pod-disruption-budget 3 | title: Pod Disruption Budget 4 | full-link: /zh-cn/docs/concepts/workloads/pods/disruptions/ 5 | date: 2019-02-12 6 | short_description: > 7 | Pod Disruption Budget 是这样一种对象：它保证在主动中断（ voluntary disruptions）时，多实例应用的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 不会少于一定的数量。 8 | 9 | aka: 10 | - PDB 11 | related: 12 | - pod 13 | - container 14 | tags: 15 | - operation 16 | --- 17 | 18 | 19 | [Pod 干扰预算（Pod Disruption Budget，PDB）](/zh-cn/docs/concepts/workloads/pods/disruptions/) 20 | 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 21 | PDB 无法防止非主动的中断，但是会计入预算（budget）。 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/pod-disruption.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: pod-disruption 3 | title: Pod 干扰 4 | full_link: /zh-cn/docs/concepts/workloads/pods/disruptions/ 5 | date: 2021-05-12 6 | short_description: > 7 | 自愿或非自愿地终止节点上的 Pod 的过程。 8 | 9 | aka: 10 | related: 11 | - pod 12 | - container 13 | tags: 14 | - operation 15 | --- 16 | 17 | [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) 是指节点上的 18 | Pod 被自愿或非自愿终止的过程。 19 | 20 | 21 | 自愿干扰是由应用程序所有者或集群管理员有意启动的。非自愿干扰是无意的， 22 | 可能由不可避免的问题触发，如节点耗尽资源或意外删除。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/pod-lifecycle.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Pod 生命周期 3 | id: pod-lifecycle 4 | date: 2019-02-17 5 | full-link: /zh-cn/docs/concepts/workloads/pods/pod-lifecycle/ 6 | related: 7 | - pod 8 | - container 9 | tags: 10 | - fundamental 11 | short_description: > 12 | 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 13 | --- 14 | 15 | 16 | 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 17 | 18 | 19 | [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 20 | 处于哪个阶段的概述。包含了下面 5 种可能的阶段：Running、Pending、Succeeded、 21 | Failed、Unknown。关于 Pod 的阶段的更高级描述请查阅 22 | [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` 字段。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/pod-priority.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Pod 优先级（Pod Priority） 3 | id: pod-priority 4 | date: 2019-01-31 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority 6 | short_description: > 7 | Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。 8 | 9 | aka: 10 | tags: 11 | - operation 12 | --- 13 | 14 | 15 | Pod 优先级表示一个 {{< glossary_tooltip term_id="pod" >}} 相对于其他 Pod 的重要性。 16 | 17 | 18 | [Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) 19 | 允许用户为 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群 20 | 工作负载而言是一个重要的特性。 21 | 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/pod-security-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Pod 安全策略 3 | id: pod-security-policy 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/security/pod-security-policy/ 6 | short_description: > 7 | 为 Pod 的创建和更新操作启用细粒度的授权。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - fundamental 13 | --- 14 | 15 | 16 | 为 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的创建和更新操作启用细粒度的授权。 17 | 18 | 19 | 20 | Pod 安全策略是集群级别的资源，它控制着 Pod 规约中的安全性敏感的内容。 21 | `PodSecurityPolicy` 对象定义了一组条件以及相关字段的默认值，Pod 22 | 运行时必须满足这些条件。Pod 安全策略控制实现上体现为一个可选的准入控制器。 23 | 24 | PodSecurityPolicy 已于 Kubernetes v1.21 起弃用，并在 v1.25 中删除。 25 | 作为替代方案，请使用 [Pod 安全准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入插件。 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/pod.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Pod 3 | id: pod 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/pods/ 6 | short_description: > 7 | Pod 表示你的集群上一组正在运行的容器。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - fundamental 13 | --- 14 | 15 | 16 | Pod 是 Kubernetes 的原子对象。 17 | Pod 表示你的集群上一组正在运行的{{< glossary_tooltip text="容器（Container）" term_id="container" >}}。 18 | 19 | 20 | 21 | 通常创建 Pod 是为了运行单个主容器。 22 | Pod 还可以运行可选的边车（sidecar）容器，以添加诸如日志记录之类的补充特性。 23 | 通常用 {{< glossary_tooltip term_id="deployment" >}} 来管理 Pod。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/preemption.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 抢占（Preemption） 3 | id: preemption 4 | date: 2019-01-31 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption 6 | short_description: > 7 | Kubernetes 中的抢占逻辑通过驱逐节点上的低优先级 Pod 来帮助悬决的 8 | Pod 找到合适的节点。 9 | 10 | aka: 11 | tags: 12 | - operation 13 | --- 14 | 15 | Kubernetes 中的抢占逻辑通过驱逐{{< glossary_tooltip term_id="node" >}} 16 | 上的低优先级{{< glossary_tooltip term_id="pod" >}} 17 | 来帮助悬决的 Pod 找到合适的节点。 18 | 19 | 20 | 如果一个 Pod 无法调度，调度器会尝试 21 | [抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) 22 | 较低优先级的 Pod，以使得悬决的 Pod 有可能被调度。 23 | 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/proxy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 代理（Proxy） 3 | id: proxy 4 | date: 2019-09-10 5 | short_description: > 6 | 充当客户端和服务器之间的中介的应用程序 7 | 8 | aka: 9 | tags: 10 | - networking 11 | --- 12 | 在计算机领域，代理指的是充当远程服务中介的服务器。 13 | 14 | 15 | 16 | 客户端与代理进行交互；代理将客户端的数据复制到实际服务器；实际服务器回复代理；代理将实际服务器的回复发送给客户端。 17 | 18 | [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。 19 | 20 | 你可以将 kube-proxy 作为普通的用户态代理服务运行。 21 | 如果你的操作系统支持，则可以在混合模式下运行 kube-proxy；该模式使用较少的系统资源即可达到相同的总体效果。 22 | 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/qos-class.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: QoS 类（QoS Class） 3 | id: qos-class 4 | date: 2019-04-15 5 | full_link: /zh-cn/docs/concepts/workloads/pods/pod-qos/ 6 | short_description: > 7 | QoS 类（Quality of Service Class）为 Kubernetes 提供了一种将集群中的 Pod 分为几个类并做出有关调度和驱逐决策的方法。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - fundamental 13 | - architecture 14 | related: 15 | - pod 16 | 17 | --- 18 | 19 | QoS Class（Quality of Service Class）为 Kubernetes 提供了一种将集群中的 Pod 20 | 分为几个类并做出有关调度和驱逐决策的方法。 21 | 22 | 23 | Pod 的 QoS 类是基于 Pod 在创建时配置的计算资源请求和限制。QoS 类用于制定有关 Pod 调度和逐出的决策。 24 | Kubernetes 可以为 Pod 分配以下 QoS 类：`Guaranteed`，`Burstable` 或者 `BestEffort`。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/quantity.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 量纲（Quantity） 3 | id: quantity 4 | date: 2018-08-07 5 | full_link: 6 | short_description: > 7 | 使用全数字来表示较小数值或使用 SI 后缀表示较大数值的表示法。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | --- 13 | 14 | 15 | 使用全数字来表示较小数值或使用 [SI](https://zh.wikipedia.org/wiki/International_System_of_Units) 后缀表示较大数值的表示法。 16 | 17 | 18 | 量纲是使用紧凑的全数字表示法来表示小数值或带有国际计量单位制（SI） 19 | 的大数值的表示法。 20 | 小数用 milli 单位表示，而大数用 kilo、mega 或 giga 单位表示。 21 | 22 | 例如，数字 `1.5` 表示为 `1500m`， 23 | 而数字 `1000` 表示为 `1k`，`1000000` 表示为 `1M`。 24 | 你还可以指定二进制表示法后缀；数字 2048 可以写成 `2Ki`。 25 | 26 | 公认的十进制（10 的幂数）单位是 `m`（milli）、`k`（kilo，有意小写）、 27 | `M`（mega）、`G`（giga）、`T`（terra）、`P`（peta）、`E`（exa）。 28 | 29 | 公认的二进制（2 的幂数）单位是 `Ki` (kibi)、`Mi` (mebi)、`Gi` (gibi)、 30 | `Ti` (tebi)、 `Pi` (pebi)、 `Ei` (exbi)。 31 | 32 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/rbac.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 基于角色的访问控制（RBAC） 3 | id: rbac 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/reference/access-authn-authz/rbac/ 6 | short_description: > 7 | 管理授权决策，允许管理员通过 Kubernetes API 动态配置访问策略。 8 | 9 | aka: 10 | tags: 11 | - security 12 | - fundamental 13 | --- 14 | 15 | 16 | 管理授权决策，允许管理员通过 {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} 动态配置访问策略。 17 | 18 | 19 | RBAC 使用 *角色* (包含权限规则)和 *角色绑定* (将角色中定义的权限授予一组用户)。 20 | 21 | 22 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/replica-set.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: ReplicaSet 3 | id: replica-set 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/controllers/replicaset/ 6 | short_description: > 7 | ReplicaSet 是下一代副本控制器。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - core-object 13 | - workload 14 | --- 15 | 16 | 17 | 18 | ReplicaSet 是下一代副本控制器。 19 | 20 | 21 | 22 | ReplicaSet 就像 ReplicationController 那样，确保一次运行指定数量的 Pod 副本。ReplicaSet 支持新的基于集合的选择器需求（在标签的用户指南中有相关描述），而副本控制器只支持基于等值的选择器需求。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/replication-controller.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 副本控制器（ReplicationController） 3 | id: replication-controller 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 一种管理多副本应用的（已弃用）的 API 对象。 8 | 9 | aka: 10 | tags: 11 | - workload 12 | - core-object 13 | --- 14 | 15 | 16 | 一种管理多副本应用的工作负载资源，能够确保特定个数的 17 | {{< glossary_tooltip text="Pod" term_id="pod" >}} 18 | 实例处于运行状态。 19 | 20 | 21 | 控制平面确保即使某些 Pod 失效、被你手动删除或错误地启动了过多 Pod 时， 22 | 指定数量的 Pod 仍处于运行状态。 23 | 24 | {{< note >}} 25 | ReplicationController 已被弃用。请参见执行类似功能的 26 | {{< glossary_tooltip text="Deployment" term_id="deployment" >}}。 27 | {{< /note >}} 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/resource-quota.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 资源配额（Resource Quotas） 3 | id: resource-quota 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/policy/resource-quotas/ 6 | short_description: > 7 | 资源配额提供了限制每个命名空间的资源消耗总和的约束。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - operation 13 | - architecture 14 | --- 15 | 16 | 资源配额提供了限制每个 {{< glossary_tooltip text="命名空间" term_id="namespace">}} 的资源消耗总和的约束。 17 | 18 | 19 | 限制了命名空间中每种对象可以创建的数量，也限制了项目中可被资源对象利用的计算资源总数。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/reviewer.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 评审者（Reviewer） 3 | id: reviewer 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 评审者是负责评审项目的某部分代码以便提高代码质量和正确性的人。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 15 | 16 | 评审者是负责评审项目的某部分代码以便提高代码质量和正确性的人。 17 | 18 | 19 | 20 | 评审者既要了解代码库又要了解软件工程规范。评审者状态是基于代码库的组成部分来设定的。 21 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/secret.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Secret 3 | id: secret 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/configuration/secret/ 6 | short_description: > 7 | Secret 用于存储敏感信息，如密码、 OAuth 令牌和 SSH 密钥。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - security 13 | --- 14 | 15 | 16 | 17 | Secret 用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。 18 | 19 | 20 | Secret 允许用户对如何使用敏感信息进行更多的控制，并减少信息意外暴露的风险。 21 | 默认情况下，Secret 值被编码为 base64 字符串并以非加密的形式存储，但可以配置为 22 | [静态加密（Encrypt at rest）](/zh-cn/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)。 23 | 24 | {{< glossary_tooltip text="Pod" term_id="pod" >}} 可以通过多种方式引用 Secret， 25 | 例如在卷挂载中引用或作为环境变量引用。Secret 设计用于机密数据，而 26 | [ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 27 | 设计用于非机密数据。 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/security-context.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 安全上下文（Security Context） 3 | id: security-context 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/configure-pod-container/security-context/ 6 | short_description: > 7 | securityContext 字段定义 Pod 或容器的特权和访问控制设置，包括运行时 UID 和 GID。 8 | 9 | aka: 10 | tags: 11 | - security 12 | --- 13 | 14 | 15 | 16 | securityContext 字段定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 或 17 | {{< glossary_tooltip text="容器" term_id="container" >}}的特权和访问控制设置。 18 | 19 | 20 | 21 | 在一个 `securityContext` 字段中，你可以设置进程所属用户和用户组、权限相关设置。你也可以设置安全策略（例如：SELinux、AppArmor、seccomp）。 22 | 23 | 24 | `PodSpec.securityContext` 字段配置会应用到一个 Pod 中的所有的 container 。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/selector.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 选择算符（Selector） 3 | id: selector 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/labels/ 6 | short_description: > 7 | 选择算符允许用户通过标签对一组资源对象进行筛选过滤。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 16 | 17 | 选择算符允许用户通过{{< glossary_tooltip text="标签（labels）" term_id="label" >}}对一组资源对象进行筛选过滤。 18 | 19 | 20 | 21 | 在查询资源列表时，选择算符可以通过标签对资源进行过滤筛选。 22 | 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/service-account.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: ServiceAccount 3 | id: service-account 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/tasks/configure-pod-container/configure-service-account/ 6 | short_description: > 7 | 为在 Pod 中运行的进程提供标识。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - core-object 13 | --- 14 | 15 | 16 | 17 | 为在 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的进程提供标识。 18 | 19 | 20 | 当 Pod 中的进程访问集群时，API 服务器将它们作为特定的服务帐户进行身份验证， 21 | 例如 `default` ，创建 Pod 时，如果你没有指定服务帐户，它将自动被赋予同一个 22 | {{< glossary_tooltip text="名字空间" term_id="namespace" >}}中的 default 服务账户。 23 | 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/service-catalog.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 服务目录（Service Catalog） 3 | id: service-catalog 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 服务目录是一种扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的软件服务，例如云供应商提供的数据仓库服务。 8 | 9 | aka: 10 | tags: 11 | - extension 12 | --- 13 | 14 | 15 | 服务目录是一种过去曾经存在的扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的软件服务，例如云供应商提供的数据仓库服务。 16 | 17 | 18 | 服务目录可以检索、供应并绑定外部{{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service" >}}， 19 | 而无需知道那些服务具体是怎样创建和托管的。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/service.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 服务（Service） 3 | id: service 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/services-networking/service/ 6 | short_description: > 7 | 将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | - core-object 13 | --- 14 | 15 | 16 | 17 | 将运行在一个或一组 {{< glossary_tooltip text="Pod" term_id="pod" >}} 上的网络应用程序公开为网络服务的方法。 18 | 19 | 20 | 服务所针对的 Pod 集（通常）由{{< glossary_tooltip text="选择算符" term_id="selector" >}}确定。 21 | 如果有 Pod 被添加或被删除，则与选择算符匹配的 Pod 集合将发生变化。 22 | 服务确保可以将网络流量定向到该工作负载的当前 Pod 集合。 23 | 24 | 25 | Kubernetes Service 要么使用 IP 网络（IPv4、IPv6 或两者），要么引用位于域名系统 (DNS) 中的外部名称。 26 | 27 | Service 的抽象可以实现其他机制，如 Ingress 和 Gateway。 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/shuffle-sharding.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 混排切片（Shuffle Sharding） 3 | id: shuffle sharding 4 | date: 2020-03-04 5 | full_link: 6 | short_description: > 7 | 一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 16 | 混排切片（Shuffle Sharding）是指一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。 17 | 18 | 19 | 20 | 我们通常会关心不同的请求序列间的相互隔离问题，目的是为了确保密度较高的 21 | 请求序列不会湮没密度较低的序列。 22 | 将请求放入不同队列的一种简单方法是对请求的某些特征值执行哈希函数， 23 | 将结果对队列的个数取模，从而得到要使用的队列的索引。 24 | 这一哈希函数使用请求的与其序列相对应的特征作为其输入。例如，在因特网上， 25 | 这一特征通常指的是由源地址、目标地址、协议、源端口和目标端口所组成的 26 | 五元组。 27 | 28 | 这种简单的基于哈希的模式有一种特性，高密度的请求序列（流）会湮没那些被 29 | 哈希到同一队列的其他低密度请求序列（流）。 30 | 为大量的序列提供较好的隔离性需要提供大量的队列，因此是有问题的。 31 | 混排切片是一种更为灵活的机制，能够更好地将低密度序列与高密度序列隔离。 32 | 混排切片的术语采用了对一叠扑克牌进行洗牌的类比，每个队列可类比成一张牌。 33 | 混排切片技术首先对请求的特定于所在序列的特征执行哈希计算，生成一个长度 34 | 为十几个二进制位或更长的哈希值。 35 | 接下来，用该哈希值作为信息熵的来源，对一叠牌来混排，并对整个一手牌（队列）来洗牌。 36 | 最后，对所有处理过的队列进行检查，选择长度最短的已检查队列作为请求的目标队列。 37 | 在队列数量适中的时候，检查所有已处理的牌的计算量并不大，对于任一给定的 38 | 低密度的请求序列而言，有相当的概率能够消除给定高密度序列的湮没效应。 39 | 当队列数量较大时，检查所有已处理队列的操作会比较耗时，低密度请求序列 40 | 消除一组高密度请求序列的湮没效应的机会也随之降低。因此，选择队列数目 41 | 时要颇为谨慎。 42 | 43 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/sig.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 特别兴趣小组（SIG） 3 | id: sig 4 | date: 2018-04-12 5 | full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups 6 | short_description: > 7 | 共同管理大范畴 Kubernetes 开源项目中某组件或方面的一组社区成员。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 15 | 16 | 17 | 共同管理大范畴 Kubernetes 开源项目中某组件或方面的一组{{< glossary_tooltip text="社区成员" term_id="member" >}}。 18 | 19 | 20 | 21 | SIG 中的成员对推进某个领域（如体系结构、API 机制构件或者文档）具有相同的兴趣。 22 | SIGs 必须遵从 [governance guidelines](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) 的规定， 23 | 不过可以有自己的贡献策略以及通信渠道（方式）。 24 | 25 | 更多的详细信息可参阅 [kubernetes/community](https://github.com/kubernetes/community) 仓库以及 26 | [SIGs 和工作组（Working Groups）](https://github.com/kubernetes/community/blob/master/sig-list.md)的最新列表。 27 | 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/statefulset.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: StatefulSet 3 | id: statefulset 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/workloads/controllers/statefulset/ 6 | short_description: > 7 | StatefulSet 用来管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。 8 | aka: 9 | tags: 10 | - fundamental 11 | - core-object 12 | - workload 13 | - storage 14 | --- 15 | 16 | 17 | StatefulSet 用来管理某 {{< glossary_tooltip text="Pod" term_id="pod" >}} 集合的部署和扩缩， 18 | 并为这些 Pod 提供持久存储和持久标识符。 19 | 20 | 21 | 和 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 类似， 22 | StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， 23 | StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 24 | 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。 25 | 26 | 如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 27 | 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 28 | 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/static-pod.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 静态 Pod（Static Pod） 3 | id: static-pod 4 | date: 2019-02-12 5 | full_link: /zh-cn/docs/tasks/configure-pod-container/static-pod/ 6 | short_description: > 7 | 静态 Pod（Static Pod）是指由特定节点上的 kubelet 守护进程直接管理的 Pod。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 由特定节点上的 kubelet 守护进程直接管理的 {{< glossary_tooltip text="Pod" term_id="pod" >}}， 16 | 17 | API 服务器不了解它的存在。 18 | 19 | 静态 Pod 不支持{{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}}。 20 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/storage-class.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: StorageClass 3 | id: storageclass 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/storage/storage-classes/ 6 | short_description: > 7 | StorageClass 是管理员用来描述可用的不同存储类型的一种方法。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - storage 13 | --- 14 | 15 | 16 | 17 | StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 18 | 19 | 20 | 21 | StorageClass 可以映射到服务质量等级（QoS）、备份策略、或者管理员任意定义的策略。 22 | 每个 StorageClass 对象包含的字段有 `provisioner`、`parameters` 和 `reclaimPolicy`。 23 | 动态制备该存储类别的{{< glossary_tooltip text="持久卷" term_id="persistent-volume" >}}时需要用到这些字段值。 24 | 通过设置 StorageClass 对象的名称，用户可以请求特定存储类别。 -------------------------------------------------------------------------------- /contents/website/reference/glossary/sysctl.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: sysctl 3 | id: sysctl 4 | date: 2019-02-12 5 | full_link: /zh-cn/docs/tasks/administer-cluster/sysctl-cluster/ 6 | short_description: > 7 | 用于获取和设置 Unix 内核参数的接口 8 | 9 | aka: 10 | tags: 11 | - 工具 12 | --- 13 | 14 | 15 | 16 | `sysctl` 是一个半标准化的接口，用于读取或更改正在运行的 Unix 内核的属性。 17 | 18 | 19 | 20 | 在类 Unix 系统上， `sysctl` 既是管理员用于查看和修改这些设置的工具的名称，也是该工具所调用的系统调用的名称。 21 | 22 | 23 | {{< glossary_tooltip text="容器" term_id="container" >}}运行时和网络插件可能对 `sysctl` 的取值有一定的要求。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/taint.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 污点（Taint） 3 | id: taint 4 | date: 2019-01-11 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ 6 | short_description: > 7 | 污点是一种核心对象，包含三个必需的属性：key、value 和 effect。 8 | 污点会阻止在节点或节点组上调度 Pod。 9 | 10 | aka: 11 | tags: 12 | - core-object 13 | - fundamental 14 | --- 15 | 16 | 17 | 污点是一种核心对象，包含三个必需的属性：key、value 和 effect。 18 | 污点会阻止在{{< glossary_tooltip text="节点" term_id="node" >}}或节点组上调度 19 | {{< glossary_tooltip text="Pod" term_id="pod" >}}。 20 | 21 | 22 | 污点和{{< glossary_tooltip text="容忍度" term_id="toleration" >}}一起工作， 23 | 以确保不会将 Pod 调度到不适合的节点上。 24 | 同一{{< glossary_tooltip text="节点" term_id="node" >}}上可标记一个或多个污点。 25 | 节点应该仅调度那些带着能与污点相匹配容忍度的 Pod。 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/toleration.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 容忍度（Toleration） 3 | id: toleration 4 | date: 2019-01-11 5 | full_link: /zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ 6 | short_description: > 7 | 容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。 8 | 容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。 9 | 10 | aka: 11 | tags: 12 | - core-object 13 | - fundamental 14 | --- 15 | 16 | 17 | 容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。容忍度允许将 Pod 18 | 调度到具有对应{{< glossary_tooltip text="污点" term_id="taint" >}}的节点或节点组上。 19 | 20 | 21 | 容忍度和{{< glossary_tooltip text="污点" term_id="taint" >}}共同作用可以确保不会将 Pod 22 | 调度在不适合的节点上。在同一 {{< glossary_tooltip text="Pod" term_id="pod" >}} 23 | 上可以设置一个或者多个容忍度。 24 | 容忍度表示在包含对应{{< glossary_tooltip text="污点" term_id="taint" >}}的节点或节点组上调度 25 | {{< glossary_tooltip text="Pod" term_id="pod" >}}是允许的（但并非必需）。 26 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/uid.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: UID 3 | id: uid 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/overview/working-with-objects/names/ 6 | short_description: > 7 | 由 Kubernetes 系统生成、用来唯一标识对象的字符串。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 15 | 16 | Kubernetes 系统生成的字符串，唯一标识对象。 17 | 18 | 19 | 20 | 在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 UID，它旨在区分类似实体的历史事件。 21 | 22 | 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/upstream.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 上游（Uptream） 3 | id: upstream 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 可以参考：核心 Kubernetes 仓库或作为当前仓库派生来源的来源仓库。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 可能指的是：核心 Kubernetes 仓库或作为当前仓库派生来源的仓库。 15 | 16 | 17 | 18 | * 在 **Kubernetes 社区**：对话中通常使用 *upstream* 来表示核心 Kubernetes 19 | 代码库，也就是更广泛的 Kubernetes 生态系统、其他代码或第三方工具所依赖的仓库。 20 | 例如，[社区成员](#term-member)可能会建议将某个功能特性贡献到 upstream， 21 | 使其位于核心代码库中，而不是维护于插件或第三方工具中。 22 | * 在 **GitHub** 或 **git** 中：惯例是将源仓库称为 *upstream*，而派生的仓库则被视为 *downstream*。 23 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/userns.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 用户名字空间 3 | id: userns 4 | date: 2021-07-13 5 | full_link: https://man7.org/linux/man-pages/man7/user_namespaces.7.html 6 | short_description: > 7 | 一种为非特权用户模拟超级用户特权的 Linux 内核功能特性。 8 | 9 | aka: 10 | tags: 11 | - security 12 | --- 13 | 14 | 15 | 用来模拟 root 用户的内核功能特性。用来支持“Rootless 容器”。 16 | 17 | 18 | 用户名字空间（User Namespace）是一种 Linux 内核功能特性，允许非 root 用户 19 | 模拟超级用户（"root"）的特权，例如用来运行容器却不必成为容器之外的超级用户。 20 | 21 | 用户名字空间对于缓解因潜在的容器逃逸攻击而言是有效的。 22 | 23 | 在用户名字空间语境中，名字空间是 Linux 内核的功能特性而不是 Kubernetes 意义上的 24 | {{< glossary_tooltip text="名字空间" term_id="namespace" >}}概念。 25 | 26 | 27 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/volume-plugin.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 卷插件（Volume Plugin） 3 | id: volumeplugin 4 | date: 2018-04-12 5 | full_link: 6 | short_description: > 7 | 卷插件可以让 Pod 集成存储。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - storage 13 | --- 14 | 15 | 16 | 17 | 卷插件可以让 {{< glossary_tooltip text="Pod" term_id="pod" >}} 集成存储。 18 | 19 | 20 | 21 | 卷插件让你能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。 22 | 卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分， 23 | 并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。 24 | 25 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/volume.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 卷（Volume） 3 | id: volume 4 | date: 2018-04-12 5 | full_link: /zh-cn/docs/concepts/storage/volumes/ 6 | short_description: > 7 | 包含可被 Pod 中容器访问的数据的目录。 8 | 9 | aka: 10 | tags: 11 | - core-object 12 | - fundamental 13 | --- 14 | 15 | 16 | 包含可被 {{< glossary_tooltip text="Pod" term_id="pod" >}} 17 | 中{{< glossary_tooltip text="容器" term_id="container" >}}访问的数据的目录。 18 | 19 | 20 | 21 | 22 | 每个 Kubernetes 卷在所处的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 存在期间保持存在状态。 23 | 因此，卷的生命期会超出 {{< glossary_tooltip text="Pod" term_id="pod" >}} 24 | 中运行的{{< glossary_tooltip text="容器" term_id="container" >}}， 25 | 并且保证{{< glossary_tooltip text="容器" term_id="container" >}}重启之后仍保留数据。 26 | 27 | 更多信息可参考[存储](/zh-cn/docs/concepts/storage/) 28 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/wg.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 工作组（Working Group，WG） 3 | id: wg 4 | date: 2018-04-12 5 | full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list 6 | short_description: > 7 | 工作组是为了方便讨论和（或）推进执行一些短周期、窄范围、或者从委员会和 SIG 分离出来的项目、以及跨 SIG 的活动。 8 | 9 | aka: 10 | tags: 11 | - community 12 | --- 13 | 14 | 15 | 16 | 17 | 工作组是为了方便讨论和（或）推进执行一些短周期、窄范围、或者从委员会和 SIG 分离出来的项目、以及跨 SIG 的活动。 18 | 19 | 20 | 21 | 工作组可以将人们组织起来，一起完成一项分散的任务。 22 | 23 | 更多信息请参考 [kubernetes/community](https://github.com/kubernetes/community) 代码库和当前的 [SIGs 和工作组](https://github.com/kubernetes/community/blob/master/sig-list.md) 列表。 24 | -------------------------------------------------------------------------------- /contents/website/reference/glossary/workload.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 工作负载（Workload） 3 | id: workloads 4 | date: 2019-02-13 5 | full_link: /zh-cn/docs/concepts/workloads/ 6 | short_description: > 7 | 工作负载是在 Kubernetes 上运行的应用程序。 8 | 9 | aka: 10 | tags: 11 | - fundamental 12 | --- 13 | 14 | 工作负载是在 Kubernetes 上运行的应用程序。 15 | 16 | 17 | 代表不同类型或部分工作负载的各种核心对象包括 DaemonSet、Deployment、Job、ReplicaSet 和 StatefulSet。 18 | 19 | 例如，具有 Web 服务器和数据库的工作负载可能在一个 20 | {{< glossary_tooltip term_id="StatefulSet" >}} 中运行数据库， 21 | 而 Web 服务器运行在 {{< glossary_tooltip term_id="Deployment" >}}。 -------------------------------------------------------------------------------- /contents/website/reference/instrumentation/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 插桩 3 | weight: 60 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/reference/instrumentation/cri-pod-container-metrics.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: CRI Pod 和容器指标 3 | content_type: reference 4 | weight: 50 5 | description: >- 6 | 通过 CRI 收集 Pod 和容器指标 7 | --- 8 | 9 | 10 | {{< feature-state for_k8s_version="v1.23" state="alpha" >}} 11 | [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 通过 12 | [cAdvisor](https://github.com/google/cadvisor) 收集 Pod 和容器指标。作为一个 Alpha 特性， 13 | Kubernetes 允许你通过{{< glossary_tooltip term_id="cri" text="容器运行时接口">}}（CRI） 14 | 配置收集 Pod 和容器指标。要使用基于 CRI 的收集机制，你必须启用 `PodAndContainerStatsFromCRI` 15 | [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 16 | 并使用兼容的 CRI 实现（containerd >= 1.6.0, CRI-O >= 1.23.0）。 17 | 18 | 19 | ## CRI Pod 和容器指标 {#cri-pod-container-metrics} 20 | 21 | 当启用 `PodAndContainerStatsFromCRI` 时，Kubelet 轮询底层容器运行时以获取 22 | Pod 和容器统计信息，而不是直接使用 cAdvisor 检查主机系统。同直接使用 cAdvisor 23 | 收集信息相比，依靠容器运行时获取这些信息的好处包括： 24 | 25 | - 潜在的性能改善，如果容器运行时在正常操作中已经收集了这些信息。 26 | 在这种情况下，这些数据可以被重用，而不是由 Kubelet 再次进行聚合。 27 | 28 | - 这种做法进一步解耦了 Kubelet 和容器运行时。 29 | 对于使用 Kubelet 来在主机上运行进程的容器运行时，其行为可用 cAdvisor 观测； 30 | 对于其他运行时（例如，使用虚拟化的容器运行时）而言， 31 | 这种做法提供了允许收集容器运行时指标的可能性。 32 | -------------------------------------------------------------------------------- /contents/website/reference/issues-security/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubernetes 问题和安全 3 | weight: 70 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/reference/issues-security/issues.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubernetes 问题追踪 3 | weight: 10 4 | aliases: [/zh-cn/cve/, /zh-cn/cves/] 5 | --- 6 | 7 | 8 | 要报告安全问题，请遵循 9 | [Kubernetes 安全问题公开流程](/zh-cn/docs/reference/issues-security/security/#report-a-vulnerability)。 10 | 11 | 使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 12 | 跟踪 Kubernetes 编码工作和公开问题。 13 | 14 | * [安全响应委员会（Security Response Committee，SRC）](https://github.com/kubernetes/committee-security-response)已公布的[已知 CVE 官方列表](/zh-cn/docs/reference/issues-security/official-cve-feed/) 15 | * [CVE 相关问题](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) 16 | 17 | 与安全性相关的公告将发送到 18 | [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 19 | 邮件列表。 20 | -------------------------------------------------------------------------------- /contents/website/reference/issues-security/official-cve-feed.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 官方 CVE 订阅源 3 | linkTitle: CVE feed 4 | weight: 25 5 | layout: cve-feed 6 | --- 7 | 8 | {{< feature-state for_k8s_version="v1.27" state="beta" >}} 9 | 10 | 这是由 Kubernetes 安全响应委员会（Security Response Committee, SRC）公布的经社区维护的官方 CVE 列表。 11 | 更多细节请参阅 [Kubernetes 安全和信息披露](/zh-cn/docs/reference/issues-security/security/)。 12 | 13 | Kubernetes 项目以 [JSON Feed](/docs/reference/issues-security/official-cve-feed/index.json) 14 | 和 [RSS feed](/docs/reference/issues-security/official-cve-feed/feed.xml) 15 | 格式就已发布的安全问题提供了可通过程序访问的提要。 16 | 你可以通过执行以下命令来查阅这些安全问题： 17 | 18 | {{< tabs name="CVE feeds" >}} 19 | {{% tab name="JSON feed" %}} 20 | [链接到 JSON 格式](/docs/reference/issues-security/official-cve-feed/index.json) 21 | 22 | ```shell 23 | curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json 24 | ``` 25 | 26 | {{% /tab %}} 27 | {{% tab name="RSS feed" %}} 28 | [链接到 RSS 格式](/docs/reference/issues-security/official-cve-feed/feed.xml) 29 | 30 | ```shell 31 | curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml 32 | ``` 33 | {{% /tab %}} 34 | {{< /tabs >}} 35 | 36 | {{< cve-feed >}} 37 | 38 | 39 | 此订阅源会自动刷新，但从宣布 CVE 到可在此订阅源中找到对应的 CVE 会有一个明显却很小的延迟（几分钟到几小时）。 40 | 41 | 此订阅源的真实来源是一组 GitHub Issue，通过受控和受限的标签 `official-cve-feed` 进行过滤。 42 | 原始数据存放在 Google Cloud Bucket 中，只有社区少数受信任的成员可以写入。 43 | -------------------------------------------------------------------------------- /contents/website/reference/kubectl/conventions.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubectl 的用法约定 3 | content_type: concept 4 | weight: 60 5 | --- 6 | 7 | `kubectl` 的推荐用法约定。 8 | 9 | 10 | 11 | ## 在可重用脚本中使用 `kubectl` {#using-kubectl-in-reusable-scripts} 12 | 13 | 对于脚本中的稳定输出： 14 | 15 | 16 | * 请求一个面向机器的输出格式，例如 `-o name`、`-o json`、`-o yaml`、`-o go template` 或 `-o jsonpath`。 17 | * 完全限定版本。例如 `jobs.v1.batch/myjob`。这将确保 kubectl 不会使用其默认版本，该版本会随着时间的推移而更改。 18 | * 不要依赖上下文、首选项或其他隐式状态。 19 | 20 | ## 子资源 {#subresources} 21 | 22 | 23 | * 你可以将 `--subresource` Beta 标志用于 kubectl 命令，例如 `get`、`patch`、`edit` 和 `replace` 24 | 来获取和更新所有支持子资源的资源的子资源。目前，仅支持 `status` 和 `scale` 子资源。 25 | * 对于 `kubectl edit`，不支持 `scale` 子资源。如果将 `--subresource` 与 `kubectl edit` 一起使用， 26 | 并指定 `scale` 作为子资源，则命令将会报错。 27 | * 针对子资源的 API 协定与完整资源相同。在更新 `status` 子资源为一个新值时，请记住， 28 | 子资源可能是潜在的由控制器调和为不同的值。 29 | 30 | ## 最佳实践 {#best-practices} 31 | 32 | ### `kubectl run` 33 | 34 | 若希望 `kubectl run` 满足基础设施即代码的要求： 35 | 36 | 37 | * 使用特定版本的标签标记镜像，不要将该标签改为新版本。例如使用 `:v1234`、`v1.2.3`、`r03062016-1-4`， 38 | 而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/zh-cn/docs/concepts/configuration/overview/#container-images))。 39 | * 使用基于版本控制的脚本来运行包含大量参数的镜像。 40 | * 对于无法通过 `kubectl run` 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。 41 | 42 | 你可以使用 `--dry-run=client` 参数来预览而不真正提交即将下发到集群的对象实例： 43 | 44 | ### `kubectl apply` 45 | 46 | * 你可以使用 `kubectl apply` 命令创建或更新资源。有关使用 kubectl apply 更新资源的详细信息，请参阅 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 47 | -------------------------------------------------------------------------------- /contents/website/reference/kubectl/kubectl-cmds.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubectl 命令 3 | weight: 20 4 | --- 5 | 6 | 7 | [kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/) 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kubernetes API 3 | weight: 50 4 | --- 5 | 6 | 7 | {{< glossary_definition term_id="kubernetes-api" length="all" >}} 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/authentication-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "身份认证资源" 3 | weight: 4 4 | auto_generated: true 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/authorization-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "鉴权资源" 3 | weight: 5 4 | auto_generated: true 5 | --- 6 | 7 | 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/cluster-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "集群资源" 3 | weight: 8 4 | auto_generated: true 5 | --- 6 | 7 | 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "公共定义" 3 | weight: 9 4 | --- 5 | 6 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/list-meta.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/apimachinery/pkg/apis/meta/v1" 5 | kind: "ListMeta" 6 | content_type: "api_reference" 7 | description: "ListMeta 描述了合成资源必须具有的元数据，包括列表和各种状态对象。" 8 | title: "ListMeta" 9 | weight: 3 10 | auto_generated: true 11 | --- 12 | 13 | 14 | 15 | `import "k8s.io/apimachinery/pkg/apis/meta/v1"` 16 | 17 | `ListMeta` 描述了合成资源必须具有的元数据，包括列表和各种状态对象。 18 | 一个资源仅能有 `{ObjectMeta, ListMeta}` 中的一个。 19 | 20 |
21 | 22 | 23 | - **continue** (string) 24 | 25 | 如果用户对返回的条目数量设置了限制，则 `continue` 可能被设置，表示服务器有更多可用的数据。 26 | 该值是不透明的，可用于向提供此列表服务的端点发出另一个请求，以检索下一组可用的对象。 27 | 如果服务器配置已更改或时间已过去几分钟，则可能无法继续提供一致的列表。 28 | 除非你在错误消息中收到此令牌（token），否则使用此 `continue` 值时返回的 `resourceVersion` 29 | 字段应该和第一个响应中的值是相同的。 30 | 31 | 32 | - **remainingItemCount** (int64) 33 | 34 | `remainingItemCount` 是列表中未包含在此列表响应中的后续项目的数量。 35 | 如果列表请求包含标签或字段选择器，则剩余项目的数量是未知的，并且在序列化期间该字段将保持未设置和省略。 36 | 如果列表是完整的（因为它没有分块或者这是最后一个块），那么就没有剩余的项目，并且在序列化过程中该字段将保持未设置和省略。 37 | 早于 v1.15 的服务器不设置此字段。`remainingItemCount` 的预期用途是*估计*集合的大小。 38 | 客户端不应依赖于设置准确的 `remainingItemCount`。 39 | 40 | 41 | - **resourceVersion** (string) 42 | 43 | 标识该对象的服务器内部版本的字符串，客户端可以用该字段来确定对象何时被更改。 44 | 该值对客户端是不透明的，并且应该原样传回给服务器。该值由系统填充，只读。 45 | 更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency 。 46 | 47 | 48 | - **selfLink** (string) 49 | 50 | selfLink 表示此对象的 URL，由系统填充，只读。 51 | 52 | 已弃用：selfLink 是一个遗留的只读字段，不再由系统填充。 53 | 54 | 55 | 56 | 57 | 58 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/local-object-reference.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/api/core/v1" 5 | kind: "LocalObjectReference" 6 | content_type: "api_reference" 7 | description: "LocalObjectReference 包含足够的信息，可以让你在同一命名空间内找到引用的对象。" 8 | title: "LocalObjectReference" 9 | weight: 4 10 | auto_generated: true 11 | --- 12 | 13 | 14 | `import "k8s.io/api/core/v1"` 15 | 16 | LocalObjectReference 包含足够的信息，可以让你在同一命名空间（namespace）内找到引用的对象。 17 | 18 |
19 | 20 | - **name** (string) 21 | 22 | 被引用者的名称。 23 | 更多信息: https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names。 24 | 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/node-selector-requirement.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/api/core/v1" 5 | kind: "NodeSelectorRequirement" 6 | content_type: "api_reference" 7 | description: 节点选择算符需求是一个选择算符，其中包含值集、主键以及一个将键和值集关联起来的操作符。 8 | title: "NodeSelectorRequirement" 9 | weight: 5 10 | --- 11 | 12 | 13 | `import "k8s.io/api/core/v1"` 14 | 15 | 节点选择算符需求是一个选择算符，其中包含值集、主键以及一个将键和值集关联起来的操作符。 16 | 17 |
18 | 19 | - **key** (string)，必需 20 | 21 | 选择算符所适用的标签主键。 22 | 23 | - **operator** (string)，必需 24 | 25 | 代表主键与值集之间的关系。合法的 operator 值包括 `In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt` 和 `Lt`。 26 | 27 | - **values** ([]string) 28 | 29 | 一个由字符串值组成的数组。如果 operator 是 `In` 或 `NotIn`，则 values 数组不能为空。 30 | 如果 operator 为 `Exists` 或 `DoesNotExist`，则 values 数组只能为空。 31 | 如果 operator 为 `Gt` 或 `Lt`，则 values 数组只能包含一个元素，并且该元素会被解释为整数。 32 | 在执行策略性合并补丁操作时，此数组会被整体替换。 33 | 34 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/object-field-selector.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/api/core/v1" 5 | kind: "ObjectFieldSelector" 6 | content_type: "api_reference" 7 | description: "ObjectFieldSelector 选择对象的 APIVersioned 字段。" 8 | title: "ObjectFieldSelector" 9 | weight: 6 10 | auto_generated: true 11 | --- 12 | 13 | 14 | 15 | 16 | `import "k8s.io/api/core/v1"` 17 | 18 | ObjectFieldSelector 选择对象的 APIVersioned 字段。 19 |
20 | 21 | 22 | - **fieldPath** (string)，必需的 23 | 24 | 在指定 API 版本中要选择的字段的路径。 25 | 26 | - **apiVersion** (string) 27 | 28 | `fieldPath` 写入时所使用的模式版本，默认为 "v1"。 29 | 30 | 31 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/patch.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/apimachinery/pkg/apis/meta/v1" 5 | kind: "Patch" 6 | content_type: "api_reference" 7 | description: "提供 Patch 是为了给 Kubernetes PATCH 请求正文提供一个具体的名称和类型。" 8 | title: "Patch" 9 | weight: 9 10 | auto_generated: true 11 | --- 12 | 13 | 14 | 15 | 16 | 17 | `import "k8s.io/apimachinery/pkg/apis/meta/v1"` 18 | 19 | 20 | 提供 Patch 是为了给 Kubernetes PATCH 请求正文提供一个具体的名称和类型。 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/resource-field-selector.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/api/core/v1" 5 | kind: "ResourceFieldSelector" 6 | content_type: "api_reference" 7 | description: "ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。" 8 | title: "ResourceFieldSelector" 9 | weight: 11 10 | auto_generated: true 11 | --- 12 | 13 | 14 | 15 | 16 | 17 | `import "k8s.io/api/core/v1"` 18 | 19 | 20 | ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。 21 | 22 |
23 | 24 | - **resource** (string)，必选 25 | 26 | 必选：选择的资源 27 | 28 | - **containerName** (string) 29 | 30 | 容器名称：对卷必选，对环境变量可选 31 | 32 | - **divisor** (}}">Quantity) 33 | 34 | 指定所曝光资源的输出格式，默认值为“1” 35 | 36 | 37 | 38 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/common-definitions/typed-local-object-reference.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "" 4 | import: "k8s.io/api/core/v1" 5 | kind: "TypedLocalObjectReference" 6 | content_type: "api_reference" 7 | description: "TypedLocalObjectReference 包含足够的信息，可以让你在同一个名称空间中定位指定类型的引用对象。" 8 | title: "TypedLocalObjectReference" 9 | weight: 13 10 | auto_generated: true 11 | --- 12 | 13 | 14 | 15 | 16 | `import "k8s.io/api/core/v1"` 17 | 18 | 19 | TypedLocalObjectReference 包含足够的信息，可以让你在同一个名称空间中定位特定类型的引用对象。 20 | 21 |
22 | 23 | - **kind** (string)，必需 24 | 25 | Kind 是被引用的资源的类型 26 | 27 | - **name** (string)，必需 28 | 29 | Name 是被引用的资源的名称 30 | 31 | - **apiGroup** (string) 32 | 33 | APIGroup 是被引用资源的组。如果不指定 APIGroup，则指定的 Kind 必须在核心 API 组中。对于任何其它第三方类型，都需要 APIGroup。 34 | 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/config-and-storage-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "配置和存储资源" 3 | weight: 3 4 | auto_generated: true 5 | --- 6 | 7 | 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/extend-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "扩展资源" 3 | weight: 7 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/other-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "其他资源" 3 | weight: 10 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/other-resources/validating-admission-policy-binding-list-v1alpha1.md: -------------------------------------------------------------------------------- 1 | --- 2 | api_metadata: 3 | apiVersion: "admissionregistration.k8s.io/v1alpha1" 4 | import: "k8s.io/api/admissionregistration/v1alpha1" 5 | kind: "ValidatingAdmissionPolicyBindingList" 6 | content_type: "api_reference" 7 | description: "" 8 | title: "ValidatingAdmissionPolicyBindingList v1alpha1" 9 | weight: 1 10 | --- 11 | 12 | 13 | `apiVersion: admissionregistration.k8s.io/v1alpha1` 14 | 15 | `import "k8s.io/api/admissionregistration/v1alpha1"` 16 | 17 | 18 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/policy-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "策略资源" 3 | weight: 6 4 | auto_generated: true 5 | --- 6 | 7 | 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/service-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Service 资源" 3 | weight: 2 4 | auto_generated: true 5 | --- 6 | 7 | 8 | -------------------------------------------------------------------------------- /contents/website/reference/kubernetes-api/workload-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "工作负载资源" 3 | weight: 1 4 | auto_generated: true 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /contents/website/reference/networking/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 网络参考 3 | content_type: reference 4 | weight: 85 5 | --- 6 | 7 | 8 | 9 | Kubernetes 文档的这一部分提供了 Kubernetes 网络的参考详细信息。 10 | 11 | -------------------------------------------------------------------------------- /contents/website/reference/node/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 节点参考信息 3 | weight: 80 4 | no_list: true 5 | --- 6 | 7 | 8 | 本部分包含以下有关节点的参考主题： 9 | 10 | * Kubelet 的 [Checkpoint API](/zh-cn/docs/reference/node/kubelet-checkpoint-api/) 11 | * 一系列[关于 dockershim 移除和使用兼容 CRI 运行时的文章](/zh-cn/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) 12 | 13 | 你还可以从 Kubernetes 文档的其他地方阅读节点的详细参考信息，包括： 14 | 15 | * [节点指标数据](/zh-cn/docs/reference/instrumentation/node-metrics)。 16 | * [CRI Pod & 容器指标](/docs/reference/instrumentation/cri-pod-container-metrics). 17 | -------------------------------------------------------------------------------- /contents/website/reference/node/device-plugin-api-versions.md: -------------------------------------------------------------------------------- 1 | --- 2 | content_type: "reference" 3 | title: Kubelet 设备管理器 API 版本 4 | weight: 10 5 | --- 6 | 7 | 本页详述了 Kubernetes 8 | [设备插件 API](https://github.com/kubernetes/kubelet/tree/master/pkg/apis/deviceplugin) 9 | 与不同版本的 Kubernetes 本身之间的版本兼容性。 10 | 11 | ## 兼容性矩阵 {#compatibility-matrix} 12 | 13 | | | `v1alpha1` | `v1beta1` | 14 | |-----------------|-------------|-------------| 15 | | Kubernetes 1.21 | - | ✓ | 16 | | Kubernetes 1.22 | - | ✓ | 17 | | Kubernetes 1.23 | - | ✓ | 18 | | Kubernetes 1.24 | - | ✓ | 19 | | Kubernetes 1.25 | - | ✓ | 20 | | Kubernetes 1.26 | - | ✓ | 21 | 22 | 简要说明： 23 | 24 | * `✓` 设备插件 API 和 Kubernetes 版本中的特性或 API 对象完全相同。 25 | * `+` 设备插件 API 具有 Kubernetes 集群中可能不存在的特性或 API 对象， 26 | 不是因为设备插件 API 添加了额外的新 API 调用，就是因为服务器移除了旧的 API 调用。 27 | 但它们的共同点是（大多数其他 API）都能工作。 28 | 请注意，Alpha API 可能会在次要版本的迭代过程中消失或出现重大变更。 29 | * `-` Kubernetes 集群具有设备插件 API 无法使用的特性，不是因为服务器添加了额外的 API 调用， 30 | 就是因为设备插件 API 移除了旧的 API 调用。但它们的共同点是（大多数 API）都能工作。 31 | -------------------------------------------------------------------------------- /contents/website/reference/scheduling/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 调度 3 | weight: 140 4 | toc-hide: true 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /contents/website/reference/scheduling/policies.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 调度策略 3 | content_type: concept 4 | sitemap: 5 | priority: 0.2 # Scheduling priorities are deprecated 6 | weight: 30 7 | --- 8 | 9 | 10 | 11 | 在 Kubernetes v1.23 版本之前，可以使用调度策略来指定 **predicates** 和 **priorities** 进程。 12 | 例如，可以通过运行 `kube-scheduler --policy-config-file ` 或者 13 | `kube-scheduler --policy-configmap ` 设置调度策略。 14 | 15 | 但是从 Kubernetes v1.23 版本开始，不再支持这种调度策略。 16 | 同样地也不支持相关的 `policy-config-file`、`policy-configmap`、`policy-configmap-namespace` 和 `use-legacy-policy-config` 标志。 17 | 你可以通过使用[调度配置](/zh-cn/docs/reference/scheduling/config/)来实现类似的行为。 18 | 19 | ## {{% heading "whatsnext" %}} 20 | 21 | 22 | * 了解[调度](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/) 23 | * 了解 [kube-scheduler 配置](/zh-cn/docs/reference/scheduling/config/) 24 | * 阅读 [kube-scheduler 配置参考 (v1)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1/) 25 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 安装工具 3 | weight: 100 4 | --- 5 | 6 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/README.md: -------------------------------------------------------------------------------- 1 | 此目录下的所有文件都是从其他仓库自动生成的。 **不要人工编辑它们。 你必须在上游仓库中编辑它们** 2 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "创建 Kubeadm" 3 | weight: 10 4 | toc_hide: true 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_certs.md: -------------------------------------------------------------------------------- 1 | 处理 Kubernetes 证书的相关命令 2 | 3 | ### 概要 4 | 5 | 处理 Kubernetes 证书相关的命令 6 | 7 | ``` 8 | kubeadm certs [flags] 9 | ``` 10 | 11 | ### 选项 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 |
-h, --help
28 | 29 | ### 继承于父命令的选项 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 |
--rootfs string

[实验] 到'真实'主机根文件系统的路径。

47 | 48 | 49 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md: -------------------------------------------------------------------------------- 1 | 2 | 生成证书密钥 3 | 4 | ### 概要 5 | 6 | 该命令将打印出可以与 "init" 命令一起使用的安全的随机生成的证书密钥。 7 | 8 | 你也可以使用 `kubeadm init --upload-certs` 而无需指定证书密钥； 9 | 命令将为你生成并打印一个证书密钥。 10 | 11 | ``` 12 | kubeadm certs certificate-key [flags] 13 | ``` 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 33 | 34 | 35 | 36 |
-h, --help
29 |

30 | certificate-key 操作的帮助命令 31 |

32 |
37 | 38 | ### 从父命令继承的选项 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 56 | 57 | 58 | 59 |
--rootfs string
52 |

53 | [实验] 到 '真实' 主机根文件系统的路径。 54 |

55 |
60 | 61 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md: -------------------------------------------------------------------------------- 1 | 2 | 为 Kubernetes 集群更新证书 3 | 4 | ### 概要 5 | 6 | 此命令并非设计用来单独运行。请参阅可用子命令列表。 7 | 8 | ``` 9 | kubeadm certs renew [flags] 10 | ``` 11 | 12 | ### 选项 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 30 | 31 | 32 | 33 |
-h, --help
26 |

27 | renew 操作的帮助命令 28 |

29 |
34 | 35 | 36 | ### 从父命令继承的选项 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 54 | 55 | 56 | 57 |
--rootfs string
50 |

51 | [实验] 到 '真实' 主机根文件系统的路径。 52 |

53 |
58 | 59 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md: -------------------------------------------------------------------------------- 1 | 2 | 与 kubeadm 使用的容器镜像交互 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 与 kubeadm 使用的容器镜像交互。 9 | 10 | ``` 11 | kubeadm config images [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 33 | 34 | 35 | 36 |
-h, --help
29 |

30 | images 的帮助命令 31 |

32 |
37 | 38 | 39 | ### 从父命令继承的选项 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 52 | 53 | 54 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 70 | 71 | 72 | 73 |
50 | --kubeconfig string     默认值："/etc/kubernetes/admin.conf" 51 |
55 |

56 | 用于和集群通信的 kubeconfig 文件。如果它没有被设置，那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。 57 |

58 |
--rootfs string
66 |

67 | [实验] 到 '真实' 主机根文件系统的路径。 68 |

69 |
74 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md: -------------------------------------------------------------------------------- 1 | 2 | 打印配置 3 | 4 | ### 概要 5 | 6 | 此命令打印子命令所提供的配置信息。 7 | 相关细节可参阅: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories 8 | 9 | ``` 10 | kubeadm config print [flags] 11 | ``` 12 | 13 | ### 选项 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |
-h, --help
30 | 31 | 32 | ### 从父命令继承而来的选项 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |

与集群通信时使用的 kubeconfig 文件。如此标志未设置，将在一组标准位置中搜索现有的kubeconfig 文件。

--rootfs string

[试验性] 指向“真实”宿主根文件系统的路径。

56 | 57 | 58 | 59 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md: -------------------------------------------------------------------------------- 1 | 2 | 使用此命令可以调用 init 工作流程的单个阶段 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 使用此命令可以调用 init 工作流程的单个阶段 9 | 10 | 11 | ### 选项 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 27 | 28 | 29 | 30 |
-h, --help
25 |

phase 操作的帮助命令

26 |
31 | 32 | 33 | ### 继承于父命令的选择项 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 49 | 50 | 51 | 52 |
--rootfs string
47 |

[实验] 到 '真实' 主机根文件系统的路径。

48 |
53 | 54 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md: -------------------------------------------------------------------------------- 1 | 2 | 安装必要的插件以通过一致性测试 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 此命令并非设计用来单独运行。请参阅可用子命令列表。 9 | 10 | ``` 11 | kubeadm init phase addon [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 33 | 34 | 35 | 36 |
-h, --help
29 |

30 | addon 操作的帮助命令 31 |

32 |
37 | 38 | 39 | ### 继承于父命令的选项 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 57 | 58 | 59 | 60 |
--rootfs string
53 |

54 | [实验] 到 '真实' 主机根文件系统的路径。 55 |

56 |
61 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md: -------------------------------------------------------------------------------- 1 | 2 | 证书生成 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 此命令不应单独运行。请参阅可用子命令列表。 9 | 10 | ``` 11 | kubeadm init phase certs [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 33 | 34 | 35 | 36 |
-h, --help
29 |

30 | certs 操作的帮助命令 31 |

32 |
37 | 38 | 39 | ### 从父指令中继承的选项 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 57 | 58 | 59 | 60 |
--rootfs string
53 |

54 | [实验] 到 '真实' 主机根文件系统的路径。 55 |

56 |
61 | 62 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 生成用来签署服务账号令牌的私钥及其公钥 4 | 5 | 6 | ### 概要 7 | 8 | 生成用来签署服务账号令牌的私钥及其公钥，并将其保存到 sa.key 和 sa.pub 文件中。 9 | 如果两个文件都已存在，则 kubeadm 会跳过生成步骤，而将使用现有文件。 10 | 11 | Alpha 免责声明：此命令当前为 alpha 阶段。 12 | 13 | ``` 14 | kubeadm init phase certs sa [flags] 15 | ``` 16 | 17 | 18 | ### 选项 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 31 | 32 | 33 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 49 | 50 | 51 | 52 |
29 | --cert-dir string     默认值："/etc/kubernetes/pki" 30 |
34 |

35 | 保存和存储证书的路径。 36 |

37 |
-h, --help
45 |

46 | sa 操作的帮助命令 47 |

48 |
53 | 54 | ### 继承于父命令的选项 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 72 | 73 | 74 | 75 |
--rootfs string
68 |

69 | [实验] 到 '真实' 主机根文件系统的路径。 70 |

71 |
76 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md: -------------------------------------------------------------------------------- 1 | 2 | 生成建立控制平面所需的静态 Pod 清单文件 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 此命令并非设计用来单独运行。请参阅可用子命令列表。 9 | 10 | ``` 11 | kubeadm init phase control-plane [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 31 | 32 | 33 | 34 |
-h, --help
29 |

control-plane 操作的帮助命令

30 |
35 | 36 | 37 | ### 继承于父命令的选项 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 53 | 54 | 55 | 56 | 57 |
--rootfs string
51 |

[实验] 到 '真实' 主机根文件系统的路径。

52 |
58 | 59 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 为本地 etcd 生成静态 Pod 的清单文件 4 | 5 | 6 | ### 概要 7 | 8 | 9 | 此命令并非设计用来单独运行。请参阅可用子命令列表。 10 | 11 | ``` 12 | kubeadm init phase etcd [flags] 13 | ``` 14 | 15 | 16 | ### 选项 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 34 | 35 | 36 | 37 |
-h, --help
30 |

31 | etcd 操作的帮助命令 32 |

33 |
38 | 39 | 40 | ### 继承于父命令的选项 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 58 | 59 | 60 | 61 |
--rootfs string
54 |

55 | [实验] 到 '真实' 主机根文件系统的路径。 56 |

57 |
62 | 63 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md: -------------------------------------------------------------------------------- 1 | 2 | 生成所有建立控制平面和管理员（admin）所需的 kubeconfig 文件 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 此命令并非设计用来单独运行。请阅读可用子命令列表。 9 | 10 | ``` 11 | kubeadm init phase kubeconfig [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 31 | 32 | 33 | 34 |
-h, --help
29 |

kubeconfig 操作的帮助命令

30 |
35 | 36 | 37 | ### 从父命令继承的选项 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 53 | 54 | 55 | 56 |
--rootfs string
51 |

[实验] 到 '真实' 主机根文件系统的路径。

52 |
57 | 58 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md: -------------------------------------------------------------------------------- 1 | TLS 引导后更新与 kubelet 相关的设置 2 | 3 | ### 概要 4 | 5 | TLS 引导后更新与 kubelet 相关的设置 6 | 7 | ``` 8 | kubeadm init phase kubelet-finalize [flags] 9 | ``` 10 | 11 | ### 示例 12 | 13 | ``` 14 | # 在 TLS 引导后更新与 kubelet 相关的设置 15 | kubeadm init phase kubelet-finalize all --config 16 | ``` 17 | 18 | ### 选项 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 |
-h, --help

kubelet-finalize 操作的帮助命令

36 | 37 | 38 | ### 继承于父命令的选项 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
--rootfs string

[实验] 到'真实'主机根文件系统的路径。

56 | 57 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_show-join-command.md: -------------------------------------------------------------------------------- 1 | 2 | 显示针对控制平面和工作节点的 join 命令。 3 | 4 | ### 概要 5 | 6 | 显示针对控制平面和工作节点的 join 命令。 7 | 8 | ``` 9 | kubeadm init phase show-join-command [flags] 10 | ``` 11 | 12 | ### 选项 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 27 | 32 | 33 | 34 | 35 |
-h, --help
26 | 28 |

29 | show-join-command 操作的帮助命令 30 |

31 |
36 | 37 | ### 从父命令继承的选项 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 52 | 57 | 58 | 59 | 60 |
--rootfs string
51 | 53 |

54 | [实验] 到 '真实' 主机根文件系统的路径。 55 |

56 |
61 | 62 | 63 | 64 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config.md: -------------------------------------------------------------------------------- 1 | 2 | 上传 kubeadm 和 kubelet 配置到 ConfigMap 中 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 此命令并非设计用来单独运行。请参阅可用的子命令列表。 9 | 10 | ``` 11 | kubeadm init phase upload-config [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 31 | 32 | 33 | 34 |
-h, --help
29 |

upload-config 操作的帮助命令

30 |
35 | 36 | 37 | ### 从父命令中继承的选项 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 53 | 54 | 55 | 56 |
--rootfs string
51 |

[实验] 到 '真实' 主机根文件系统的路径。

52 |
57 | 58 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md: -------------------------------------------------------------------------------- 1 | 2 | 使用此命令来调用 `join` 工作流程的某个阶段 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 使用此命令来调用 `join` 工作流程的某个阶段 9 | 10 | 11 | ### 选项 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 27 | 28 | 29 | 30 |
-h, --help
25 |

phase 操作的帮助命令

26 |
31 | 32 | 33 | ### 从父命令中继承的选项 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 49 | 50 | 51 | 52 |
--rootfs string
47 |

[实验] 指向 '真实' 宿主机根文件系统的路径。

48 |
53 | 54 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md: -------------------------------------------------------------------------------- 1 | 2 | 添加作为控制平面实例的机器 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 添加作为控制平面实例的机器 9 | 10 | ``` 11 | kubeadm join phase control-plane-join [flags] 12 | ``` 13 | 14 | 15 | ### 示例 16 | 17 | 18 | ``` 19 | # 将机器作为控制平面实例加入 20 | kubeadm join phase control-plane-join all 21 | ``` 22 | 23 | 24 | ### 选项 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 42 | 43 | 44 | 45 |
-h, --help
38 |

39 | control-plane-join 操作的帮助命令 40 |

41 |
46 | 47 | 48 | ### 从父命令中继承的选项 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 66 | 67 | 68 | 69 |
--rootfs string
62 |

63 | [实验] 到 '真实' 主机根文件系统的路径。 64 |

65 |
70 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 准备为控制平面服务的机器 4 | 5 | 6 | ### 概要 7 | 8 | 9 | 准备为控制平面服务的机器 10 | 11 | ``` 12 | kubeadm join phase control-plane-prepare [flags] 13 | ``` 14 | 15 | 16 | ### 示例 17 | 18 | ``` 19 | # 准备为控制平面服务的机器 20 | kubeadm join phase control-plane-prepare all 21 | ``` 22 | 23 | 24 | ### 选项 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 42 | 43 | 44 | 45 |
-h, --help
38 |

39 | control-plane-prepare 操作的帮助命令 40 |

41 |
46 | 47 | 48 | ### 从父命令中继承的选项 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 66 | 67 | 68 | 69 |
--rootfs string
62 |

63 | [实验] 指向 '真实' 宿主机根文件系统的路径。 64 |

65 |
70 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md: -------------------------------------------------------------------------------- 1 | 2 | Kubeconfig 文件工具。 3 | 4 | ### 概要 5 | 6 | kubeconfig 文件工具。 7 | 8 | ### 选项 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 24 | 25 | 26 | 27 |
-h, --help
22 | kubeconfig 操作的帮助命令 23 |
28 | 29 | ### 从父命令继承的选项 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 45 | 46 | 47 | 48 | 49 |
--rootfs string
43 | [实验] 到 '真实' 主机根文件系统的路径。 44 |
50 | 51 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md: -------------------------------------------------------------------------------- 1 | 2 | 使用此命令来调用 `reset` 工作流程的某个阶段 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 使用此命令来调用 `reset` 工作流程的某个阶段 9 | 10 | 11 | ### 选项 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 29 | 30 | 31 | 32 |
-h, --help
25 |

26 | phase 操作的帮助命令 27 |

28 |
33 | 34 | 35 | ### 从父命令继承的选项 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 53 | 54 | 55 | 56 |
--rootfs string
49 |

50 | [实验] 指向 '真实' 宿主机根文件系统的路径。 51 |

52 |
57 | 58 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_remove-etcd-member.md: -------------------------------------------------------------------------------- 1 | 2 | 删除本地 etcd 成员。 3 | 4 | ### 概要 5 | 6 | 删除控制平面节点的本地 etcd 成员。 7 | 8 | ``` 9 | kubeadm reset phase remove-etcd-member [flags] 10 | ``` 11 | 12 | ### 选项 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 38 | 39 | 40 | 41 | 42 | 43 | 48 | 49 | 50 | 51 |
--dry-run

26 | 不做任何更改；只输出将要执行的操作。 27 |

-h, --help
35 |

36 | remove-etcd-member 的帮助信息 37 |

44 |

45 | 与集群通信时使用的 Kubeconfig 文件。如果未设置该标志，则可以在默认位置中查找现有的 Kubeconfig 文件。 46 |

47 |
52 | 53 | ### 从父命令继承的选项 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 71 | 72 | 73 | 74 |
--rootfs string
67 |

68 | [实验] 到'真实'主机根文件系统的路径。 69 |

70 |
75 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 此命令能将集群平滑升级到新版本 5 | 6 | 7 | ### 概要 8 | 9 | 10 | 此命令能将集群平滑升级到新版本 11 | 12 | ``` 13 | kubeadm upgrade [flags] 14 | ``` 15 | 16 | 17 | ### 选项 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 33 | 34 | 35 | 36 |
-h, --help
31 |

upgrade 操作的帮助命令

32 |

37 | 38 | 39 | ### 继承于父命令的选项 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 55 | 56 | 57 | 58 |
--rootfs string
53 |

[实验] 指向 '真实' 宿主机根文件系统的路径。

54 |

59 | 60 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase.md: -------------------------------------------------------------------------------- 1 | 2 | 使用此命令调用 node 工作流的某个阶段 3 | 4 | 5 | ### 概要 6 | 7 | 8 | 使用此命令调用 node 工作流的某个阶段 9 | 10 | 11 | ### 选项 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 29 | 30 | 31 | 32 |
-h, --help
25 |

26 | phase 操作的帮助命令 27 |

28 |
33 | 34 | ### 从父命令继承的选项 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 52 | 53 | 54 | 55 |
--rootfs string
48 |

49 | [实验] 指向 '真实' 宿主机根文件系统的路径。 50 |

51 |
56 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md: -------------------------------------------------------------------------------- 1 | 执行升级节点的预检 2 | 3 | ### 概要 4 | 5 | 执行 kubeadm 升级节点的预检。 6 | 7 | ``` 8 | kubeadm upgrade node phase preflight [flags] 9 | ``` 10 | 11 | ### 选项 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 |
-h, --help

preflight 操作的帮助命令

--ignore-preflight-errors strings

错误将显示为警告的检查清单。示例：'IsPrivilegedUser,Swap'。值为'all'表示忽略所有检查的错误。

36 | 37 | ### 继承于父命令的选项 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 |
--rootfs string

[实验] 到'真实'主机根文件系统的路径。

55 | 56 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/generated/kubeadm_version.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 打印 kubeadm 的版本 4 | 5 | 6 | ### 概要 7 | 8 | 打印 kubeadm 的版本 9 | 10 | ``` 11 | kubeadm version [flags] 12 | ``` 13 | 14 | 15 | ### 选项 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 44 | 45 | 46 | 47 |
-h, --help
29 |

30 | version 操作的帮助命令 31 |

32 |
-o, --output string
40 |

41 | 输出格式；可用的选项有 'yaml', 'json' 和 'short' 42 |

43 |
48 | 49 | 50 | ### 从父命令继承的选项 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 68 | 69 | 70 | 71 |
--rootfs string
64 |

65 | [实验] 指向 '真实' 宿主机根文件系统的路径。 66 |

67 |
72 | 73 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-alpha.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm alpha 3 | content_type: concept 4 | weight: 90 5 | --- 6 | 7 | {{< caution >}} 8 | `kubeadm alpha` 提供了一组可用于收集社区反馈的预览性质功能。 9 | 请试用这些功能并给我们提供反馈！ 10 | {{< /caution >}} 11 | 12 | 目前在 `kubeadm alpha` 之下没有试验性质的命令。 13 | 14 | ## {{% heading "whatsnext" %}} 15 | 16 | * 用来启动引导 Kubernetes 控制平面节点的 17 | [kubeadm init](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/) 18 | 命令 19 | * 用来将节点连接到集群的 20 | [kubeadm join](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-join/) 21 | 命令 22 | * 用来还原 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改的 23 | [kubeadm reset](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 24 | 命令 25 | 26 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm kubeconfig 3 | content_type: concept 4 | weight: 90 5 | --- 6 | 7 | `kubeadm kubeconfig` 提供用来管理 kubeconfig 文件的工具。 8 | 9 | 如果希望查看如何使用 `kubeadm kubeconfig user` 的示例，请参阅 10 | [为其他用户生成 kubeconfig 文件](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users). 11 | 12 | ## kubeadm kubeconfig {#cmd-kubeconfig} 13 | 14 | {{< tabs name="tab-kubeconfig" >}} 15 | {{< tab name="overview" include="generated/kubeadm_kubeconfig.md" />}} 16 | {{< /tabs >}} 17 | 18 | ## kubeadm kubeconfig user {#cmd-kubeconfig-user} 19 | 20 | 此命令可用来为其他用户生成一个 kubeconfig 文件。 21 | 22 | {{< tabs name="tab-kubeconfig-user" >}} 23 | {{< tab name="user" include="generated/kubeadm_kubeconfig_user.md" />}} 24 | {{< /tabs >}} 25 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-reset.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm reset 3 | content_type: concept 4 | weight: 60 5 | --- 6 | 7 | 该命令尽力还原由 `kubeadm init` 或 `kubeadm join` 所做的更改。 8 | 9 | 10 | {{< include "generated/kubeadm_reset.md" >}} 11 | 12 | ### Reset 工作流程 {#reset-workflow} 13 | 14 | `kubeadm reset` 负责从使用 `kubeadm init` 或 `kubeadm join` 命令创建的文件中清除节点本地文件系统。 15 | 对于控制平面节点，`reset` 还从 etcd 集群中删除该节点的本地 etcd Stacked 部署的成员。 16 | 17 | `kubeadm reset phase` 可用于执行上述工作流程的各个阶段。 18 | 要跳过阶段列表，你可以使用 `--skip-phases` 参数，该参数的工作方式类似于 `kubeadm join` 和 `kubeadm init` 阶段运行器。 19 | 20 | ### 外部 etcd 清理 21 | 22 | 如果使用了外部 etcd，`kubeadm reset` 将不会删除任何 etcd 中的数据。这意味着，如果再次使用相同的 etcd 端点运行 `kubeadm init`，你将看到先前集群的状态。 23 | 24 | 要清理 etcd 中的数据，建议你使用 etcdctl 这样的客户端，例如： 25 | 26 | ```bash 27 | etcdctl del "" --prefix 28 | ``` 29 | 30 | 更多详情请参考 [etcd 文档](https://github.com/coreos/etcd/tree/master/etcdctl)。 31 | 32 | 33 | ## {{% heading "whatsnext" %}} 34 | 35 | * 参考 [kubeadm init](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/) 来初始化 Kubernetes 主节点。 36 | * 参考 [kubeadm join](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-join/) 来初始化 Kubernetes 工作节点并加入集群。 37 | 38 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-token.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm token 3 | content_type: concept 4 | weight: 70 5 | --- 6 | 7 | 8 | 9 | 如[使用引导令牌进行身份验证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)所描述的，引导令牌用于在即将加入集群的节点和主节点间建立双向认证。 10 | 11 | 12 | `kubeadm init` 创建了一个有效期为 24 小时的令牌，下面的命令允许你管理令牌，也可以创建和管理新的令牌。 13 | 14 | 15 | 16 | ## kubeadm token create {#cmd-token-create} 17 | {{< include "generated/kubeadm_token_create.md" >}} 18 | 19 | ## kubeadm token delete {#cmd-token-delete} 20 | {{< include "generated/kubeadm_token_delete.md" >}} 21 | 22 | ## kubeadm token generate {#cmd-token-generate} 23 | {{< include "generated/kubeadm_token_generate.md" >}} 24 | 25 | ## kubeadm token list {#cmd-token-list} 26 | {{< include "generated/kubeadm_token_list.md" >}} 27 | 28 | 29 | ## {{% heading "whatsnext" %}} 30 | 31 | * [kubeadm join](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-join/) 引导 Kubernetes 工作节点并将其加入集群 32 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm upgrade phase 3 | weight: 90 4 | content_type: concept 5 | --- 6 | 7 | 在 Kubernetes v1.15.0 版本中，kubeadm 引入了对 `kubeadm upgrade node` 阶段的初步支持。其他 `kubeadm upgrade` 子命令如 `apply` 等阶段将在未来发行版中添加。 8 | 9 | 10 | ## kubeadm upgrade node phase {#cmd-node-phase} 11 | 12 | 13 | 使用此阶段，可以选择执行辅助控制平面或工作节点升级的单独步骤。请注意，`kubeadm upgrade apply` 命令仍然必须在主控制平面节点上调用。 14 | 15 | {{< tabs name="tab-phase" >}} 16 | {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} 17 | {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} 18 | {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} 19 | {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} 20 | {{< /tabs >}} 21 | 22 | ## {{% heading "whatsnext" %}} 23 | 24 | * [kubeadm init](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导一个 Kubernetes 控制平面节点 25 | * [kubeadm join](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点加入到集群 26 | * [kubeadm reset](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 还原 `kubeadm init` 或 `kubeadm join` 命令对主机所做的任何更改 27 | * [kubeadm upgrade](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 升级 kubeadm 节点 28 | * [kubeadm alpha](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 29 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-upgrade.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm upgrade 3 | content_type: concept 4 | weight: 40 5 | --- 6 | 7 | `kubeadm upgrade` 是一个对用户友好的命令，它将复杂的升级逻辑包装在一个命令后面，支持升级的规划和实际执行。 8 | 9 | 10 | ## kubeadm upgrade 指南 11 | 12 | [本文档](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)概述 13 | 使用 kubeadm 执行升级的步骤。 14 | 与 kubeadm 旧版本相关的文档，请参阅 Kubernetes 网站的旧版文档。 15 | 16 | 你可以使用 `kubeadm upgrade diff` 来查看将应用于静态 Pod 清单的更改。 17 | 18 | 在 Kubernetes v1.15.0 和更高版本中，`kubeadm upgrade apply` 和 `kubeadm upgrade node` 19 | 也将自动续订该节点上的 kubeadm 托管证书，包括存储在 kubeconfig 文件中的证书。 20 | 要选择退出，可以传递参数 `--certificate-renewal=false`。 21 | 有关证书续订的更多详细信息请参见[证书管理文档](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。 22 | 23 | 24 | {{< note >}} 25 | `kubeadm upgrade apply` 和 `kubeadm upgrade plan` 命令都具有遗留的 `--config` 标志， 26 | 可以在执行特定控制平面节点的规划或升级时重新配置集群。 27 | 请注意，升级工作流不是为这种情况而设计的，并且有意外结果的报告。 28 | {{}} 29 | 30 | ## kubeadm upgrade plan {#cmd-upgrade-plan} 31 | {{< include "generated/kubeadm_upgrade_plan.md" >}} 32 | 33 | ## kubeadm upgrade apply {#cmd-upgrade-apply} 34 | {{< include "generated/kubeadm_upgrade_apply.md" >}} 35 | 36 | ## kubeadm upgrade diff {#cmd-upgrade-diff} 37 | {{< include "generated/kubeadm_upgrade_diff.md" >}} 38 | 39 | ## kubeadm upgrade node {#cmd-upgrade-node} 40 | {{< include "generated/kubeadm_upgrade_node.md" >}} 41 | 42 | ## {{% heading "whatsnext" %}} 43 | 44 | * 如果你使用 kubeadm v1.7.x 或更低版本初始化集群，则可以参考 45 | [kubeadm 配置](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-config/) 46 | 配置集群用于 `kubeadm upgrade`。 47 | 48 | -------------------------------------------------------------------------------- /contents/website/reference/setup-tools/kubeadm/kubeadm-version.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: kubeadm version 3 | content_type: concept 4 | weight: 80 5 | --- 6 | 7 | 8 | 此命令用来输出 kubeadm 的版本。 9 | 10 | {{< include "generated/kubeadm_version.md" >}} 11 | 12 | -------------------------------------------------------------------------------- /contents/website/setup/best-practices/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 最佳实践 3 | weight: 40 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/setup/learning-environment/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 学习环境 3 | weight: 20 4 | --- 5 | 6 | -------------------------------------------------------------------------------- /contents/website/setup/production-environment/tools/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 使用部署工具安装 Kubernetes 3 | weight: 30 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/setup/production-environment/tools/kubeadm/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "使用 kubeadm 引导集群" 3 | weight: 10 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/setup/production-environment/turnkey-solutions.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Turnkey 云解决方案 3 | content_type: concept 4 | weight: 40 5 | --- 6 | 7 | 本页列示 Kubernetes 认证解决方案供应商。 8 | 在每一个供应商分页，你可以学习如何安装和设置生产就绪的集群。 9 | 10 | 11 | {{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}} 12 | -------------------------------------------------------------------------------- /contents/website/tasks/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 任务 3 | main_menu: true 4 | weight: 50 5 | content_type: concept 6 | --- 7 | 8 | 9 | Kubernetes 文档这一部分包含的一些页面展示如何去完成单个任务。 10 | 每个任务页面是一般通过给出若干步骤展示如何执行完成某事。 11 | 12 | 如果你希望编写一个任务页面，参考 13 | [创建一个文档拉取请求](/zh-cn/docs/contribute/new-content/open-a-pr/)。 14 | 15 | -------------------------------------------------------------------------------- /contents/website/tasks/access-application-cluster/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 访问集群中的应用程序 3 | weight: 100 4 | description: 配置负载平衡、端口转发或设置防火墙或 DNS 配置，以访问集群中的应用程序。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/access-application-cluster/configure-dns-cluster.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 为集群配置 DNS 3 | weight: 130 4 | content_type: concept 5 | --- 6 | 7 | 8 | Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。 9 | 在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS， 10 | kubeadm 默认会安装 CoreDNS。 11 | 12 | 要了解关于如何为 Kubernetes 集群配置 CoreDNS 的更多信息，参阅 13 | [定制 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/)。 14 | 关于如何利用 kube-dns 配置 kubernetes DNS 的演示例子，参阅 15 | [Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 16 | 17 | 18 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "管理集群" 3 | weight: 20 4 | description: 了解管理集群的常见任务。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/enable-disable-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 启用/禁用 Kubernetes API 3 | content_type: task 4 | weight: 200 5 | --- 6 | 7 | 本页展示怎么用集群的 8 | {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}. 9 | 启用/禁用 API 版本。 10 | 11 | 12 | 13 | 通过 API 服务器的命令行参数 `--runtime-config=api/` ， 14 | 可以开启/关闭某个指定的 API 版本。 15 | 此参数的值是一个逗号分隔的 API 版本列表。 16 | 此列表中，后面的值可以覆盖前面的值。 17 | 18 | 命令行参数 `runtime-config` 支持两个特殊的值（keys）： 19 | 20 | - `api/all`：指所有已知的 API 21 | - `api/legacy`：指过时的 API。过时的 API 就是明确地 22 | [弃用](/zh-cn/docs/reference/using-api/deprecation-policy/) 23 | 的 API。 24 | 25 | 例如：为了停用除去 v1 版本之外的全部其他 API 版本， 26 | 就用参数 `--runtime-config=api/all=false,api/v1=true` 启动 `kube-apiserver`。 27 | 28 | ## {{% heading "whatsnext" %}} 29 | 30 | 阅读[完整的文档](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/), 31 | 以了解 `kube-apiserver` 组件。 -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 关键插件 Pod 的调度保证 3 | content_type: concept 4 | weight: 220 5 | --- 6 | 7 | 8 | Kubernetes 核心组件（如 API 服务器、调度器、控制器管理器）在控制平面节点上运行。 9 | 但是插件必须在常规集群节点上运行。 10 | 其中一些插件对于功能完备的集群至关重要，例如 Heapster、DNS 和 UI。 11 | 如果关键插件被逐出（手动或作为升级等其他操作的副作用）或者变成挂起状态，集群可能会停止正常工作。 12 | 关键插件进入挂起状态的例子有：集群利用率过高；被逐出的关键插件 Pod 释放了空间，但该空间被之前悬决的 13 | Pod 占用；由于其它原因导致节点上可用资源的总量发生变化。 14 | 15 | 注意，把某个 Pod 标记为关键 Pod 并不意味着完全避免该 Pod 被逐出；它只能防止该 Pod 变成永久不可用。 16 | 被标记为关键性的静态 Pod 不会被逐出。但是，被标记为关键性的非静态 Pod 总是会被重新调度。 17 | 18 | 19 | ### 标记关键 Pod 20 | 21 | 要将 Pod 标记为关键性（critical），设置 Pod 的 priorityClassName 为 `system-cluster-critical` 或者 `system-node-critical`。 22 | `system-node-critical` 是最高级别的可用性优先级，甚至比 `system-cluster-critical` 更高。 23 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/kubeadm/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "用 kubeadm 进行管理" 3 | weight: 10 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/manage-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 管理内存、CPU 和 API 资源 3 | weight: 40 4 | --- 5 | 6 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/network-policy-provider/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 安装网络策略驱动 3 | weight: 50 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 使用 Antrea 提供 NetworkPolicy 3 | content_type: task 4 | weight: 10 5 | --- 6 | 7 | 本页展示了如何在 kubernetes 中安装和使用 Antrea CNI 插件。 8 | 要了解 Antrea 项目的背景，请阅读 [Antrea 介绍](https://antrea.io/docs/)。 9 | 10 | ## {{% heading "prerequisites" %}} 11 | 12 | 你需要拥有一个 kuernetes 集群。 13 | 遵循 [kubeadm 入门指南](/zh-cn/docs/reference/setup-tools/kubeadm/)自行创建一个。 14 | 15 | 16 | ## 使用 kubeadm 部署 Antrea 17 | 遵循[入门](https://github.com/vmware-tanzu/antrea/blob/main/docs/getting-started.md)指南 18 | 为 kubeadm 部署 Antrea 。 19 | 20 | ## {{% heading "whatsnext" %}} 21 | 22 | 一旦你的集群已经运行，你可以遵循 23 | [声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/) 24 | 来尝试 Kubernetes NetworkPolicy。 -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/network-policy-provider/calico-network-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 使用 Calico 提供 NetworkPolicy 3 | content_type: task 4 | weight: 20 5 | --- 6 | 7 | 本页展示了几种在 Kubernetes 上快速创建 Calico 集群的方法。 8 | 9 | ## {{% heading "prerequisites" %}} 10 | 11 | 确定你想部署一个[云版本](#gke-cluster)还是[本地版本](#local-cluster)的集群。 12 | 13 | 14 | ## 在 Google Kubernetes Engine (GKE) 上创建一个 Calico 集群 {#gke-cluster} 15 | 16 | **先决条件**：[gcloud](https://cloud.google.com/sdk/docs/quickstarts) 17 | 18 | 1. 启动一个带有 Calico 的 GKE 集群，需要加上参数 `--enable-network-policy`。 19 | 20 | **语法** 21 | ```shell 22 | gcloud container clusters create [CLUSTER_NAME] --enable-network-policy 23 | ``` 24 | 25 | **示例** 26 | ```shell 27 | gcloud container clusters create my-calico-cluster --enable-network-policy 28 | ``` 29 | 30 | 2. 使用如下命令验证部署是否正确。 31 | 32 | ```shell 33 | kubectl get pods --namespace=kube-system 34 | ``` 35 | 36 | 37 | Calico 的 Pod 名以 `calico` 打头，检查确认每个 Pod 状态为 `Running`。 38 | 39 | ## 使用 kubeadm 创建一个本地 Calico 集群 {#local-cluster} 40 | 41 | 使用 kubeadm 在 15 分钟内得到一个本地单主机 Calico 集群，请参考 42 | [Calico 快速入门](https://projectcalico.docs.tigera.io/getting-started/kubernetes/)。 43 | 44 | ## {{% heading "whatsnext" %}} 45 | 46 | 集群运行后， 47 | 你可以按照[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)去尝试使用 48 | Kubernetes NetworkPolicy。 49 | 50 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 使用 kube-router 提供 NetworkPolicy 3 | content_type: task 4 | weight: 40 5 | --- 6 | 7 | 本页展示如何使用 [Kube-router](https://github.com/cloudnativelabs/kube-router) 提供 NetworkPolicy。 8 | 9 | 10 | ## {{% heading "prerequisites" %}} 11 | 12 | 你需要拥有一个运行中的 Kubernetes 集群。如果你还没有集群，可以使用任意的集群 13 | 安装程序如 Kops、Bootkube、Kubeadm 等创建一个。 14 | 15 | ## 安装 kube-router 插件 {#installing-kube-router-addon} 16 | 17 | kube-router 插件自带一个网络策略控制器，监视来自于 Kubernetes API 服务器的 18 | NetworkPolicy 和 Pod 的变化，根据策略指示配置 iptables 规则和 ipsets 来允许或阻止流量。 19 | 请根据 [通过集群安装程序尝试 kube-router](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 指南安装 kube-router 插件。 20 | 21 | ## {{% heading "whatsnext" %}} 22 | 23 | 在你安装了 kube-router 插件后，可以参考 24 | [声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/) 25 | 去尝试使用 Kubernetes NetworkPolicy。 26 | 27 | -------------------------------------------------------------------------------- /contents/website/tasks/administer-cluster/network-policy-provider/romana-network-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 使用 Romana 提供 NetworkPolicy 3 | content_type: task 4 | weight: 50 5 | --- 6 | 7 | 8 | 9 | 本页展示如何使用 Romana 作为 NetworkPolicy。 10 | 11 | ## {{% heading "prerequisites" %}} 12 | 13 | 完成 [kubeadm 入门指南](/zh-cn/docs/reference/setup-tools/kubeadm/)中的 1、2、3 步。 14 | 15 | ## 使用 kubeadm 安装 Romana 16 | 17 | 按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)， 18 | 使用 kubeadm 安装。 19 | 20 | ## 应用网络策略 21 | 22 | 使用以下的一种方式应用网络策略： 23 | 24 | * [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies) 25 | * [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md) 26 | * NetworkPolicy API 27 | 28 | ## {{% heading "whatsnext" %}} 29 | 30 | Romana 安装完成后，你可以按照 31 | [声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/) 32 | 去尝试使用 Kubernetes NetworkPolicy。 33 | 34 | -------------------------------------------------------------------------------- /contents/website/tasks/configmap-secret/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "管理 Secrets" 3 | weight: 60 4 | description: 使用 Secrets 管理机密配置数据。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/configure-pod-container/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "配置 Pods 和容器" 3 | weight: 30 4 | description: 对 Pod 和容器执行常见的配置任务。 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /contents/website/tasks/debug/debug-application/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "应用故障排除" 3 | description: 调试常见的容器应用问题. 4 | weight: 20 5 | --- 6 | 7 | 8 | 该文档包含一组用于解决容器化应用程序问题的资源。 9 | 它涵盖了诸如 Kubernetes 资源（如 Pod、Service 或 StatefulSets）的常见问题、 10 | 关于理解容器终止消息的建议以及调试正在运行的容器的方法。 11 | -------------------------------------------------------------------------------- /contents/website/tasks/debug/debug-application/debug-statefulset.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 调试 StatefulSet 3 | content_type: task 4 | weight: 30 5 | --- 6 | 7 | 此任务展示如何调试 StatefulSet。 8 | 9 | ## {{% heading "prerequisites" %}} 10 | 11 | * 你需要有一个 Kubernetes 集群，已配置好的 kubectl 命令行工具与你的集群进行通信。 12 | * 你应该有一个运行中的 StatefulSet，以便用于调试。 13 | 14 | 15 | ## 调试 StatefulSet {#debugging-a-statefulset} 16 | 17 | StatefulSet 在创建 Pod 时为其设置了 `app.kubernetes.io/name=MyApp` 标签，列出仅属于某 StatefulSet 18 | 的所有 Pod 时，可以使用以下命令： 19 | 20 | ```shell 21 | kubectl get pods -l app.kubernetes.io/name=MyApp 22 | ``` 23 | 24 | 如果你发现列出的任何 Pod 长时间处于 `Unknown` 或 `Terminating` 状态，请参阅 25 | [删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/delete-stateful-set/) 26 | 了解如何处理它们的说明。 27 | 你可以参考[调试 Pod](/zh-cn/docs/tasks/debug/debug-application/debug-pods/) 28 | 来调试 StatefulSet 中的各个 Pod。 29 | 30 | ## {{% heading "whatsnext" %}} 31 | 32 | 进一步了解如何[调试 Init 容器](/zh-cn/docs/tasks/debug/debug-application/debug-init-containers/)。 33 | 34 | -------------------------------------------------------------------------------- /contents/website/tasks/extend-kubernetes/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "扩展 Kubernetes" 3 | description: 了解针对工作环境需要来调整 Kubernetes 集群的进阶方法。 4 | weight: 110 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/extend-kubernetes/custom-resources/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "使用自定义资源" 3 | weight: 10 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tasks/inject-data-application/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "给应用注入数据" 3 | weight: 70 4 | description: 给你的工作负载 Pod 指定配置和其他数据。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/job/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "运行 Jobs" 3 | weight: 90 4 | description: 使用并行处理运行 Jobs。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/manage-daemon/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "管理集群守护进程" 3 | weight: 130 4 | description: 执行 DaemonSet 管理的常见任务，例如执行滚动更新。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/manage-kubernetes-objects/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "管理 Kubernetes 对象" 3 | weight: 50 4 | description: 用声明式和命令式范型与 Kubernetes API 交互。 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /contents/website/tasks/network/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "网络" 3 | weight: 140 4 | description: 了解如何为你的集群配置网络。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/run-application/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "运行应用" 3 | weight: 80 4 | description: 运行和管理无状态和有状态的应用。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/tls/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "TLS" 3 | weight: 120 4 | description: 了解如何使用传输层安全性（ TLS ）保护集群中的流量。 5 | --- 6 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "内含的工具" 3 | description: "在页面 kubectl-installs-*.md 中包含的代码片段" 4 | headless: true 5 | toc_hide: true 6 | _build: 7 | list: never 8 | render: never 9 | publishResources: false 10 | --- 11 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/kubectl-convert-overview.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "kubectl-convert 概述" 3 | description: >- 4 | 一个 kubectl 插件，允许你将清单从一个 Kubernetes API 版本转换到不同的版本。 5 | headless: true 6 | _build: 7 | list: never 8 | render: never 9 | publishResources: false 10 | --- 11 | 12 | 一个 Kubernetes 命令行工具 `kubectl` 的插件，允许你将清单在不同 API 版本间转换。 13 | 这对于将清单迁移到新的 Kubernetes 发行版上未被废弃的 API 版本时尤其有帮助。 14 | 更多信息请访问[迁移到非弃用 API](/zh-cn/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) 15 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/kubectl-whats-next.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "后续内容" 3 | description: "安装 kubectl 之后，还可以做些什么？" 4 | headless: true 5 | _build: 6 | list: never 7 | render: never 8 | publishResources: false 9 | --- 10 | 11 | * [安装 Minikube](https://minikube.sigs.k8s.io/docs/start/)。 12 | * 有关创建集群的更多信息，请参阅[入门指南](/zh-cn/docs/setup/)。 13 | * [学习如何启动并对外公开你的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。 14 | * 如果你需要访问其他人创建的集群， 15 | 请参阅[共享集群接入文档](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。 16 | * 阅读 [kubectl 参考文档](/zh-cn/docs/reference/kubectl/kubectl/)。 17 | 18 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/optional-kubectl-configs-fish.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "fish 自动补全" 3 | description: "启用 fish 自动补全的可选配置。" 4 | headless: true 5 | _build: 6 | list: never 7 | render: never 8 | publishResources: false 9 | --- 10 | 11 | {{< note >}} 12 | 自动补全 Fish 需要 kubectl 1.23 或更高版本。 13 | {{< /note >}} 14 | 15 | kubectl 通过命令 `kubectl completion fish` 生成 Fish 自动补全脚本。 16 | 在 shell 中导入（Sourcing）该自动补全脚本，将启动 kubectl 自动补全功能。 17 | 18 | 为了在所有的 shell 会话中实现此功能，请将下面内容加入到文件 `~/.config/fish/config.fish` 中。 19 | 20 | ```shell 21 | kubectl completion fish | source 22 | ``` 23 | 24 | 重新加载 shell 后，kubectl 自动补全功能将立即生效。 25 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/optional-kubectl-configs-pwsh.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "PowerShell 自动补全" 3 | description: "powershell 自动补全的一些可选配置。" 4 | headless: true 5 | _build: 6 | list: never 7 | render: never 8 | publishResources: false 9 | --- 10 | 11 | 你可以使用命令 `kubectl completion powershell` 生成 PowerShell 的 kubectl 自动补全脚本。 12 | 13 | 如果需要自动补全在所有 Shell 会话中生效，请将以下命令添加到 `$PROFILE` 文件中： 14 | 15 | ```powershell 16 | kubectl completion powershell | Out-String | Invoke-Expression 17 | ``` 18 | 19 | 此命令将在每次 PowerShell 启动时重新生成自动补全脚本。你还可以将生成的自动补全脚本添加到 `$PROFILE` 文件中。 20 | 21 | 如果需要将自动补全脚本直接添加到 `$PROFILE` 文件中，请在 PowerShell 命令行运行以下命令： 22 | 23 | ```powershell 24 | kubectl completion powershell >> $PROFILE 25 | ``` 26 | 27 | 完成上述操作后重启 Shell，kubectl 的自动补全就可以工作了。 28 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/optional-kubectl-configs-zsh.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "zsh 自动补全" 3 | description: "zsh 自动补全的一些可选配置" 4 | headless: true 5 | _build: 6 | list: never 7 | render: never 8 | publishResources: false 9 | --- 10 | 11 | kubectl 通过命令 `kubectl completion zsh` 生成 Zsh 自动补全脚本。 12 | 在 Shell 中导入（Sourcing）该自动补全脚本，将启动 kubectl 自动补全功能。 13 | 14 | 为了在所有的 Shell 会话中实现此功能，请将下面内容加入到文件 `~/.zshrc` 中。 15 | 16 | ```zsh 17 | source <(kubectl completion zsh) 18 | ``` 19 | 20 | 如果你为 kubectl 定义了别名，kubectl 自动补全将自动使用它。 21 | 22 | 重新加载 Shell 后，kubectl 自动补全功能将立即生效。 23 | 24 | 如果你收到 `2: command not found: compdef` 这样的错误提示，那请将下面内容添加到 25 | `~/.zshrc` 文件的开头： 26 | 27 | ```zsh 28 | autoload -Uz compinit 29 | compinit 30 | ``` 31 | 32 | -------------------------------------------------------------------------------- /contents/website/tasks/tools/included/verify-kubectl.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "验证 kubectl 的安装效果" 3 | description: "如何验证 kubectl。" 4 | headless: true 5 | _build: 6 | list: never 7 | render: never 8 | publishResources: false 9 | --- 10 | 11 | 为了让 kubectl 能发现并访问 Kubernetes 集群，你需要一个 12 | [kubeconfig 文件](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/)， 13 | 该文件在 14 | [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) 15 | 创建集群时，或成功部署一个 Minikube 集群时，均会自动生成。 16 | 通常，kubectl 的配置信息存放于文件 `~/.kube/config` 中。 17 | 18 | 通过获取集群状态的方法，检查是否已恰当地配置了 kubectl： 19 | 20 | ```shell 21 | kubectl cluster-info 22 | ``` 23 | 24 | 如果返回一个 URL，则意味着 kubectl 成功地访问到了你的集群。 25 | 26 | 如果你看到如下所示的消息，则代表 kubectl 配置出了问题，或无法连接到 Kubernetes 集群。 27 | 28 | ``` 29 | The connection to the server was refused - did you specify the right host or port? 30 | （访问 被拒绝 - 你指定的主机和端口是否有误？） 31 | ``` 32 | 33 | 例如，如果你想在自己的笔记本上（本地）运行 Kubernetes 集群，你需要先安装一个 Minikube 34 | 这样的工具，然后再重新运行上面的命令。 35 | 36 | 如果命令 `kubectl cluster-info` 返回了 URL，但你还不能访问集群，那可以用以下命令来检查配置是否妥当： 37 | 38 | ```shell 39 | kubectl cluster-info dump 40 | ``` 41 | -------------------------------------------------------------------------------- /contents/website/tutorials/configuration/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "配置" 3 | weight: 30 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/configuration/configure-java-microservice/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "示例：配置 java 微服务" 3 | weight: 10 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/kubernetes-basics/create-cluster/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 创建集群 3 | weight: 10 4 | --- 5 | 6 | 了解 Kubernetes {{}}并使用 Minikube 7 | 创建一个简单的集群。 8 | -------------------------------------------------------------------------------- /contents/website/tutorials/kubernetes-basics/deploy-app/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 部署应用 3 | weight: 20 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/kubernetes-basics/explore/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 了解你的应用 3 | weight: 30 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/kubernetes-basics/expose/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 公开地暴露你的应用 3 | weight: 40 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/kubernetes-basics/scale/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 扩缩你的应用 3 | weight: 50 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/kubernetes-basics/update/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 更新你的应用 3 | weight: 60 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/security/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "安全" 3 | weight: 40 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/services/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Service" 3 | weight: 70 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/stateful-application/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "有状态的应用" 3 | weight: 50 4 | --- 5 | -------------------------------------------------------------------------------- /contents/website/tutorials/stateless-application/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "无状态的应用" 3 | weight: 40 4 | --- 5 | -------------------------------------------------------------------------------- /deploy/Dockerfile.aio: -------------------------------------------------------------------------------- 1 | FROM rayproject/ray-ml:e23349-py39-gpu 2 | 3 | WORKDIR /workspace 4 | 5 | COPY ../requirements.txt . 6 | RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple 7 | 8 | # This is used for building vector store. 9 | COPY ../contents ./contents 10 | COPY ../pkg ./pkg 11 | 12 | # This is because serve run pkg.serve:deployment doesn't work. 13 | WORKDIR /workspace/pkg 14 | -------------------------------------------------------------------------------- /deploy/Dockerfile.serving: -------------------------------------------------------------------------------- 1 | FROM rayproject/ray-ml:e23349-py39-gpu 2 | 3 | WORKDIR /workspace 4 | 5 | COPY ../requirements.txt . 6 | RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple 7 | 8 | COPY ../pkg ./pkg 9 | 10 | # This is because serve run pkg.serve:deployment doesn't work. 11 | WORKDIR /workspace/pkg 12 | -------------------------------------------------------------------------------- /hack/data_process.py: -------------------------------------------------------------------------------- 1 | """ 2 | This script helps to remove commented-out sentences in markdowns. 3 | Raw contents should be placed under k8s-specific-knowledge-base/_contents. 4 | """ 5 | 6 | import os 7 | 8 | prefix = "" 10 | 11 | 12 | def walk_files(path: str): 13 | for dirpath, dirnames, filenames in os.walk(path): 14 | for filename in filenames: 15 | if not filename.endswith(".md"): 16 | continue 17 | 18 | destPath = dirpath.replace("../_", "../") 19 | if not os.path.exists(destPath): 20 | os.makedirs(destPath) 21 | 22 | with open(destPath + "/" + filename, "w") as f: 23 | with open(dirpath + "/" + filename) as r: 24 | lines = r.readlines() 25 | continue_write = True 26 | for line in lines: 27 | if prefix in line: 28 | continue_write = False 29 | 30 | if continue_write: 31 | f.write(line) 32 | 33 | if suffix in line: 34 | continue_write = True 35 | 36 | 37 | walk_files("../_contents") 38 | -------------------------------------------------------------------------------- /images/architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kerthcet/k8s-specific-knowledge-base/ea7a0384ac4e41dd80b40418284db776d64667dd/images/architecture.png -------------------------------------------------------------------------------- /k8s-specific-knowledge-base.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kerthcet/k8s-specific-knowledge-base/ea7a0384ac4e41dd80b40418284db776d64667dd/k8s-specific-knowledge-base.zip -------------------------------------------------------------------------------- /pkg/__init__.py: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kerthcet/k8s-specific-knowledge-base/ea7a0384ac4e41dd80b40418284db776d64667dd/pkg/__init__.py -------------------------------------------------------------------------------- /pkg/const.py: -------------------------------------------------------------------------------- 1 | # BASE_MODEL = "THUDM/chatglm2-6b" 2 | # See ../deploy/rayservice-serving.yaml for details 3 | BASE_MODEL = "/workspace/models/chatglm2-6b" 4 | EMBEDDING_MODEL = "BAAI/bge-base-zh-v1.5" 5 | FAISS_INDEX_PATH = "faiss_index" 6 | GPU_MAX_NUMBER = 1 7 | # If you want to use GPU, set this to cuda. 8 | DEVICE = "cuda" 9 | -------------------------------------------------------------------------------- /pkg/dataset_test.py: -------------------------------------------------------------------------------- 1 | import unittest 2 | 3 | from ray.data import read_binary_files 4 | from dataset import split_text 5 | 6 | 7 | class DataSetTest(unittest.TestCase): 8 | def test_load_data(self): 9 | ds = read_binary_files("../contents/posts") 10 | ds.flat_map(split_text) 11 | for i in ds.iter_rows(): 12 | print(i) 13 | self.assertEqual(3, 4) 14 | 15 | 16 | if __name__ == "__main__": 17 | unittest.main() 18 | -------------------------------------------------------------------------------- /pkg/pipeline.py: -------------------------------------------------------------------------------- 1 | from typing import Any, List, Optional 2 | 3 | from langchain import HuggingFacePipeline 4 | from transformers import pipeline as hf_pipeline 5 | 6 | 7 | class LocalPipeline(HuggingFacePipeline): 8 | def _call(self, prompt: str, stop: Optional[List[str]] = None) -> str: 9 | response = self.pipeline( 10 | prompt, temperature=0.1, max_new_tokens=256, do_sample=True 11 | ) 12 | 13 | # TODO: support other tasks. 14 | if self.pipeline.task == "text-generation": 15 | # Text generation return includes the starter text. 16 | print(f"Response is: {response}") 17 | text = response[0]["generated_text"][len(prompt):] 18 | else: 19 | raise ValueError(f"Got invalid task {self.pipeline.task}. ") 20 | return text 21 | 22 | @classmethod 23 | def from_model_id( 24 | cls, 25 | model_id: str, 26 | task: str, 27 | device: Optional[str] = None, 28 | trust_remote_code: Optional[bool] = False, 29 | model_kwargs: Optional[dict] = None, 30 | **kwargs: Any, 31 | ): 32 | pipeline = hf_pipeline( 33 | model=model_id, 34 | task=task, 35 | device=device, 36 | trust_remote_code=trust_remote_code, 37 | model_kwargs=model_kwargs, 38 | ) 39 | return cls( 40 | pipeline=pipeline, 41 | model_id=model_id, 42 | model_kwargs=model_kwargs, 43 | **kwargs, 44 | ) 45 | -------------------------------------------------------------------------------- /pkg/utils.py: -------------------------------------------------------------------------------- 1 | import io 2 | import binascii 3 | from typing import List, Dict 4 | 5 | import pypdf 6 | from pypdf import PdfReader 7 | 8 | 9 | def convert_pdf_to_text(pdf: Dict[str, any]) -> List[Dict[str, str]]: 10 | pdf_bytes_io = io.BytesIO(pdf["bytes"]) 11 | 12 | try: 13 | pdf_doc = PdfReader(pdf_bytes_io) 14 | except pypdf.errors.PdfStreamError: 15 | # Skip pdfs that are not readable. 16 | return [] 17 | 18 | pages = [] 19 | for page in pdf_doc.pages: 20 | try: 21 | pages.append({"text": page.extract_text()}) 22 | except binascii.Error: 23 | # Skip all pages that are not parsable due to malformed character. 24 | print("parsing failed") 25 | return pages 26 | 27 | 28 | def convert_md_to_text(md: Dict[str, any]) -> List[Dict[str, str]]: 29 | return [{"text": str(md["bytes"], encoding="utf-8")}] 30 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | langchain==0.0.242 2 | transformers==4.31.0 3 | sentence-transformers==2.2.2 4 | pypdf==3.13.0 5 | faiss-cpu==1.7.4 --------------------------------------------------------------------------------