This page assumes that you understand how to contribute to new content and review others' work, and are ready to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. Propose improvements SIG Docs members can propose improvements. After you've been contributing to the Kubernetes documentation for a while, you may have ideas for improving the Style Guide , the Content Guide, the toolchain used to build the documentation, the website style, the processes for reviewing and merging pull requests, or other aspects of the documentation.

This page shows how to update the Kubernetes API reference documentation. The Kubernetes API reference documentation is built from the Kubernetes OpenAPI spec using the kubernetes-sigs/reference-docs generation code. If you find bugs in the generated documentation, you need to fix them upstream. If you need only to regenerate the reference documentation from the OpenAPI spec, continue reading this page. Before you begin Requirements: You need a machine that is running Linux or macOS.

Requirements: You need a machine that is running Linux or macOS. You need to have these tools installed: Python v3.7.x+ Git Golang version 1.13+ Pip used to install PyYAML PyYAML v5.1.2 make gcc compiler/linker Docker (Required only for kubectl command reference) Your PATH environment variable must include the required build tools, such as the Go binary and python. You need to know how to create a pull request to a GitHub repository.

Resource Types CredentialProviderConfig CredentialProviderConfig CredentialProviderConfig is the configuration containing information about each exec credential provider. Kubelet reads this configuration from disk and enables each provider as specified by the CredentialProvider type. FieldDescription apiVersionstringkubelet.config.k8s.io/v1 kindstringCredentialProviderConfig providers [Required] []CredentialProvider providers is a list of credential provider plugins that will be enabled by the kubelet. Multiple providers may match against a single image, in which case credentials from all providers will be returned to the kubelet.

Package v1beta1 is the v1beta1 version of the API. Resource Types AuthenticationConfiguration AuthorizationConfiguration EgressSelectorConfiguration TracingConfiguration TracingConfiguration Appears in: KubeletConfiguration TracingConfiguration TracingConfiguration TracingConfiguration provides versioned configuration for OpenTelemetry tracing clients. FieldDescription endpoint string Endpoint of the collector this component will report traces to. The connection is insecure, and does not currently support TLS. Recommended is unset, and endpoint is the otlp grpc default, localhost:4317. samplingRatePerMillion int32 SamplingRatePerMillion is the number of samples to collect per million spans.

Package v1beta1 is the v1beta1 version of the external metrics API. Resource Types ExternalMetricValue ExternalMetricValueList ExternalMetricValue Appears in: ExternalMetricValueList ExternalMetricValue is a metric value for external metric A single metric value is identified by metric name and a set of string labels. For one metric there can be multiple values with different sets of labels. FieldDescription apiVersionstringexternal.metrics.k8s.io/v1beta1 kindstringExternalMetricValue metricName [Required] string the name of the metric metricLabels [Required] map[string]string a set of labels that identify a single time series for the metric

Overview Package v1beta4 defines the v1beta4 version of the kubeadm configuration file format. This version improves on the v1beta3 format by fixing some minor issues and adding a few new fields. A list of changes since v1beta3: v1.33: Add an EtcdUpgrade field to UpgradeConfiguration.plan that can be used to control whether the etcd upgrade plan should be displayed. v1.31: Support custom environment variables in control plane components under ClusterConfiguration. Use apiServer.

If you notice an issue with Kubernetes documentation or have an idea for new content, then open an issue. All you need is a GitHub account and a web browser. In most cases, new work on Kubernetes documentation begins with an issue in GitHub. Kubernetes contributors then review, categorize and tag issues as needed. Next, you or another member of the Kubernetes community open a pull request with changes to resolve the issue.

Case studies highlight how organizations are using Kubernetes to solve real-world problems. The Kubernetes marketing team and members of the CNCF collaborate with you on all case studies. Case studies require extensive review before they're approved. Submit a case study Have a look at the source for the existing case studies. Refer to the case study guidelines and submit your request as outlined in the guidelines.

Production-Grade Container Orchestration