## 1. Project Overview & Quickstart (kubernetes/client-go)

## File: README.md

> ⚠️ **This is an automatically published [staged repository](https://git.k8s.io/kubernetes/staging#external-repository-staging-area) for Kubernetes**.   
> Contributions, including issues and pull requests, should be made to the main Kubernetes repository: [https://github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).  
> This repository is read-only for importing, and not used for direct contributions.  
> See [CONTRIBUTING.md](./CONTRIBUTING.md) for more details.

# client-go

Go clients for talking to a [kubernetes](http://kubernetes.io/) cluster.

We recommend using the `v0.x.y` tags for Kubernetes releases >= `v1.17.0` and
`kubernetes-1.x.y` tags for Kubernetes releases < `v1.17.0`.

The fastest way to add this library to a project is to run `go get k8s.io/client-go@latest` with go1.16+.
See [INSTALL.md](/INSTALL.md) for detailed installation instructions and troubleshooting.

[![GoDocWidget]][GoDocReference]

[GoDocWidget]: https://godoc.org/k8s.io/client-go?status.svg
[GoDocReference]:https://godoc.org/k8s.io/client-go 

## Table of Contents

- [What's included](#whats-included)
- [Versioning](#versioning)
  - [Compatibility: your code <-> client-go](#compatibility-your-code---client-go)
  - [Compatibility: client-go <-> Kubernetes clusters](#compatibility-client-go---kubernetes-clusters)
  - [Compatibility matrix](#compatibility-matrix)
  - [Why do the 1.4 and 1.5 branch contain top-level folder named after the version?](#why-do-the-14-and-15-branch-contain-top-level-folder-named-after-the-version)
- [Kubernetes tags](#kubernetes-tags)
- [How to get it](#how-to-get-it)
- [How to use it](#how-to-use-it)
- [Dependency management](#dependency-management)
- [Contributing code](#contributing-code)

### What's included

* The `kubernetes` package contains the clientset to access Kubernetes API.
* The `discovery` package is used to discover APIs supported by a Kubernetes API server.
* The `dynamic` package contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects.
* The `plugin/pkg/client/auth` packages contain optional authentication plugins for obtaining credentials from external sources.
* The `transport` package is used to set up auth and start a connection.
* The `tools/cache` package is useful for writing controllers.

### Versioning

- For each `v1.x.y` Kubernetes release, the major version (first digit)
would remain `0`.

- Bugfixes will result in the patch version (third digit) changing. PRs that are
cherry-picked into an older Kubernetes release branch will result in an update
to the corresponding branch in `client-go`, with a corresponding new tag
changing the patch version.

#### Branches and tags.

We will create a new branch and tag for each increment in the minor version
number. We will create only a new tag for each increment in the patch
version number. See [semver](http://semver.org/) for definitions of major,
minor, and patch.

The HEAD of the master branch in client-go will track the HEAD of the master
branch in the main Kubernetes repo.

#### Compatibility: your code <-> client-go

The `v0.x.y` tags indicate that go APIs may change in incompatible ways in
different versions.

See [INSTALL.md](INSTALL.md) for guidelines on requiring a specific
version of client-go.

#### Compatibility: client-go <-> Kubernetes clusters

Since Kubernetes is backwards compatible with clients, older `client-go`
versions will work with many different Kubernetes cluster versions.

We will backport bugfixes--but not new features--into older versions of
`client-go`.


#### Compatibility matrix

|                               | Kubernetes 1.29 | Kubernetes 1.30 | Kubernetes 1.31 | Kubernetes 1.32 | Kubernetes 1.33 | Kubernetes 1.34 |
| ----------------------------- | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- |
| `kubernetes-1.29.0`/`v0.29.0` | ✓               | +-              | +-              | +-              | +-              | +-              |
| `kubernetes-1.30.0`/`v0.30.0` | +-              | ✓               | +-              | +-              | +-              | +-              |
| `kubernetes-1.31.0`/`v0.31.0` | +-              | +-              | ✓               | +-              | +-              | +-              |
| `kubernetes-1.32.0`/`v0.32.0` | +-              | +-              | +-              | ✓               | +-              | +-              |
| `kubernetes-1.33.0`/`v0.33.0` | +-              | +-              | +-              | +-              | ✓               | +-              |
| `kubernetes-1.34.0`/`v0.34.0` | +-              | +-              | +-              | +-              | +-              | ✓               |
| `HEAD`                        | +-              | +-              | +-              | +-              | +-              | +-              |

Key:

* `✓` Exactly the same features / API objects in both client-go and the Kubernetes
  version.
* `+` client-go has features or API objects that may not be present in the
  Kubernetes cluster, either due to that client-go has additional new API, or
  that the server has removed old API. However, everything they have in
  common (i.e., most APIs) will work. Please note that alpha APIs may vanish or
  change significantly in a single release.
* `-` The Kubernetes cluster has features the client-go library can't use,
  either due to the server has additional new API, or that client-go has
  removed old API. However, everything they share in common (i.e., most APIs)
  will work.

See the [CHANGELOG](./CHANGELOG.md) for a detailed description of changes
between client-go versions.

| Branch         | Canonical source code location      | Maintenance status |
| -------------- | ----------------------------------- | ------------------ |
| `release-1.25` | Kubernetes main repo, 1.25 branch   | =-                 |
| `release-1.26` | Kubernetes main repo, 1.26 branch   | =-                 |
| `release-1.27` | Kubernetes main repo, 1.27 branch   | =-                 |
| `release-1.28` | Kubernetes main repo, 1.28 branch   | =-                 |
| `release-1.29` | Kubernetes main repo, 1.29 branch   | =-                 |
| `release-1.30` | Kubernetes main repo, 1.30 branch   | =-                 |
| `release-1.31` | Kubernetes main repo, 1.31 branch   | =                  |
| `release-1.32` | Kubernetes main repo, 1.32 branch   | ✓                  |
| `release-1.33` | Kubernetes main repo, 1.33 branch   | ✓                  |
| `release-1.34` | Kubernetes main repo, 1.34 branch   | ✓                  |
| client-go HEAD | Kubernetes main repo, master branch | ✓                  |

Key:

* `✓` Changes in main Kubernetes repo are actively published to client-go by a bot
* `=` Maintenance is manual, only severe security bugs will be patched.
* `-` Deprecated; please upgrade.

#### Deprecation policy

We will maintain branches for at least six months after their first stable tag
is cut. (E.g., the clock for the release-2.0 branch started ticking when we
tagged v2.0.0, not when we made the first alpha.) This policy applies to
every version greater than or equal to 2.0.

#### Why do the 1.4 and 1.5 branch contain top-level folder named after the version?

For the initial release of client-go, we thought it would be easiest to keep
separate directories for each minor version. That soon proved to be a mistake.
We are keeping the top-level folders in the 1.4 and 1.5 branches so that
existing users won't be broken.

### Kubernetes tags

This repository is still a mirror of
[k8s.io/kubernetes/staging/src/client-go](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/client-go),
the code development is still done in the staging area.

Since Kubernetes `v1.8.0`, when syncing the code from the staging area,
we also sync the Kubernetes version tags to client-go, prefixed with
`kubernetes-`. From Kubernetes `v1.17.0`, we also create matching semver
`v0.x.y` tags for each `v1.x.y` Kubernetes release.

For example, if you check out the `kubernetes-1.17.0` or the `v0.17.0` tag in
client-go, the code you get is exactly the same as if you check out the `v1.17.0`
tag in Kubernetes, and change directory to `staging/src/k8s.io/client-go`.

The purpose is to let users quickly find matching commits among published repos,
like [sample-apiserver](https://github.com/kubernetes/sample-apiserver),
[apiextension-apiserver](https://github.com/kubernetes/apiextensions-apiserver),
etc. The Kubernetes version tag does NOT claim any backwards compatibility
guarantees for client-go. Please check the [semantic versions](#versioning) if
you care about backwards compatibility.

### How to get it

To get the latest version, use go1.16+ and fetch using the `go get` command. For example:

```
go get k8s.io/client-go@latest
```

To get a specific version, use go1.11+ and fetch the desired version using the `go get` command. For example:

```
go get k8s.io/client-go@v0.20.4
```

See [INSTALL.md](/INSTALL.md) for detailed instructions and troubleshooting.

### How to use it

If your application runs in a Pod in the cluster, please refer to the
in-cluster [example](examples/in-cluster-client-configuration), otherwise please
refer to the out-of-cluster [example](examples/out-of-cluster-client-configuration).

### Dependency management

For details on how to correctly use a dependency management for installing client-go, please see [INSTALL.md](INSTALL.md).

### Contributing code
Please send pull requests against the client packages in the Kubernetes main [repository](https://github.com/kubernetes/kubernetes). Changes in the staging area will be published to this repository every day.

---

## File: examples/out-of-cluster-client-configuration/README.md

# Authenticating outside the cluster

This example shows you how to configure a client with client-go to authenticate
to the Kubernetes API from an application running outside the Kubernetes
cluster.

You can use your kubeconfig file that contains the context information
of your cluster to initialize a client. The kubeconfig file is also used
by the `kubectl` command to authenticate to the clusters.

## Running this example

Make sure your `kubectl` is configured and pointed to a cluster. Run
`kubectl get nodes` to confirm.

Run this application with:

    cd out-of-cluster-client-configuration
    go build -o app .
    ./app

Running this application will use the kubeconfig file and then authenticate to the
cluster, and print the number of pods in the cluster every 10 seconds:

    ./app
    There are 3 pods in the cluster
    There are 3 pods in the cluster
    There are 3 pods in the cluster
    ...

Press <kbd>Ctrl</kbd>+<kbd>C</kbd> to quit this application.

> **Note:** You can use the `-kubeconfig` option to use a different config file. By default
this program picks up the default file used by kubectl (when `KUBECONFIG`
environment variable is not set).

---

## File: examples/leader-election/README.md

# Leader Election Example

This example demonstrates how to use the leader election package.

## Running

Run the following three commands in separate terminals. Each terminal needs a unique `id`.

```bash
# first terminal
go run main.go -kubeconfig=/path/to/kubeconfig -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=1

# second terminal
go run main.go -kubeconfig=/path/to/kubeconfig -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=2

# third terminal
go run main.go -kubeconfig=/path/to/kubeconfig -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=3
```

> You can ignore the `-kubeconfig` flag if you are running these commands in the Kubernetes cluster.

Now kill the existing leader. You will see from the terminal outputs that one of the remaining two processes will be elected as the new leader.

---

## File: examples/in-cluster-client-configuration/README.md

# Authenticating inside the cluster

This example shows you how to configure a client with client-go to authenticate
to the Kubernetes API from an application running inside the Kubernetes cluster.

client-go uses the [Service Account token][sa] mounted inside the Pod at the
`/var/run/secrets/kubernetes.io/serviceaccount` path when the
`rest.InClusterConfig()` is used.

## Running this example

First compile the application for Linux:

    cd in-cluster-client-configuration
    GOOS=linux go build -o ./app .

Then package it to a docker image using the provided Dockerfile to run it on
Kubernetes.

If you are running a [Minikube][mk] cluster, you can build this image directly
on the Docker engine of the Minikube node without pushing it to a registry. To
build the image on Minikube:

    eval $(minikube docker-env)
    docker build -t in-cluster .

If you are not using Minikube, you should build this image and push it to a registry
that your Kubernetes cluster can pull from.

If you have RBAC enabled on your cluster, use the following
snippet to create role binding which will grant the default service account view
permissions.

```
kubectl create clusterrolebinding default-view --clusterrole=view --serviceaccount=default:default
```

Then, run the image in a Pod with a single instance Deployment:

    kubectl run --rm -i demo --image=in-cluster

    There are 4 pods in the cluster
    There are 4 pods in the cluster
    There are 4 pods in the cluster
    ...

The example now runs on Kubernetes API and successfully queries the number of
pods in the cluster every 10 seconds.

### Clean up

To stop this example and clean up the pod, press <kbd>Ctrl</kbd>+<kbd>C</kbd> on
the `kubectl run` command and then run:

    kubectl delete deployment demo

[sa]: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens
[mk]: https://kubernetes.io/docs/getting-started-guides/minikube/

---

## File: examples/fake-client/README.md

# Fake Client Example

This example demonstrates how to use a fake client with SharedInformerFactory in tests.

It covers:
 * Creating the fake client
 * Setting up real informers
 * Injecting events into those informers

## Running

```
go test -v k8s.io/client-go/examples/fake-client
```

---

## File: examples/dynamic-create-update-delete-deployment/README.md

# Create, Update & Delete Deployment with the Dynamic Package

This example program demonstrates the fundamental operations for managing on
[Deployment][1] resources, such as `Create`, `List`, `Update` and `Delete` using client-go's `dynamic` package.

## Typed Vs. Dynamic
The code in this directory is based on a similar [example that uses Kubernetes typed client sets][2]. The typed client sets make it simple to communicate with the API server using pre-generated local API objects to achieve an RPC-like programming experience.  Typed clients uses program compilations to enforce data safety and some validation.  However, when using typed clients, programs are forced to be tightly coupled with the version and the types used.


The `dynamic` package on the other hand, uses a simple type, `unstructured.Unstructured`, to represent all object values from the API server. Type `Unstructured` uses a collection of nested `map[string]interface{}` values to create an internal structure that closely resemble the REST payload from the server.  

The dynamic package defers all data bindings until runtime.  This means programs that use the dynamic client will not get any of the benefits of type validation until the program is running.  This may be a problem for certain types of applications that require strong data type check and validation.

Being loosely coupled, however, means that programs that uses the `dynamic` package do not require recompilation when the client API changes.  The client program has more flexibility in handling updates to the API surface without knowing ahead of time what those changes are. 


## Running this example

Make sure you have a Kubernetes cluster and `kubectl` is configured:
```
kubectl get nodes
```

Compile this example on your workstation:

```
cd dynamic-create-update-delete-deployment
go build -o ./app
```

Now, run this application on your workstation with your local kubeconfig file:

```
./app
# or specify a kubeconfig file with flag
./app -kubeconfig=$HOME/.kube/config
```

Running this command will execute the following operations on your cluster:

1. **Create Deployment:** This will create a 2 replica Deployment. Verify with
   `kubectl get pods`.
2. **Update Deployment:** This will update the Deployment resource created in
   previous step by setting the replica count to 1 and changing the container
   image to `nginx:1.13`. You are encouraged to inspect the retry loop that
   handles conflicts. Verify the new replica count and container image with
   `kubectl describe deployment demo`.
3. **List Deployments:** This will retrieve Deployments in the `default`
   namespace and print their names and replica counts.
4. **Delete Deployment:** This will delete the Deployment object and its
   dependent ReplicaSet resource. Verify with `kubectl get deployments`.

Each step is separated by an interactive prompt. You must hit the
<kbd>Return</kbd> key to proceed to the next step. You can use these prompts as
a break to take time to run `kubectl` and inspect the result of the operations
executed.

You should see an output like the following:

```
Creating deployment...
Created deployment "demo-deployment".
-> Press Return key to continue.

Updating deployment...
Updated deployment...
-> Press Return key to continue.

Listing deployments in namespace "default":
 * demo-deployment (1 replicas)
-> Press Return key to continue.

Deleting deployment...
Deleted deployment.
```

## Cleanup

Successfully running this program will clean the created artifacts. If you
terminate the program without completing, you can clean up the created
deployment with:

    kubectl delete deploy demo-deployment

## Troubleshooting

If you are getting the following error, make sure Kubernetes version of your
cluster is v1.13 or higher in `kubectl version`:

    panic: the server could not find the requested resource

[1]: https://kubernetes.io/docs/user-guide/deployments/
[2]: ../create-update-delete-deployment

---

## File: examples/create-update-delete-deployment/README.md

# Create, Update & Delete Deployment

This example program demonstrates the fundamental operations for managing on
[Deployment][1] resources, such as `Create`, `List`, `Update` and `Delete`.

You can adopt the source code from this example to write programs that manage
other types of resources through the Kubernetes API.

## Running this example

Make sure you have a Kubernetes cluster and `kubectl` is configured:

    kubectl get nodes

Compile this example on your workstation:

```
cd create-update-delete-deployment
go build -o ./app
```

Now, run this application on your workstation with your local kubeconfig file:

```
./app
# or specify a kubeconfig file with flag
./app -kubeconfig=$HOME/.kube/config
```

Running this command will execute the following operations on your cluster:

1. **Create Deployment:** This will create a 2 replica Deployment. Verify with
   `kubectl get pods`.
2. **Update Deployment:** This will update the Deployment resource created in
   previous step by setting the replica count to 1 and changing the container
   image to `nginx:1.13`. You are encouraged to inspect the retry loop that
   handles conflicts. Verify the new replica count and container image with
   `kubectl describe deployment demo`.
3. **List Deployments:** This will retrieve Deployments in the `default`
   namespace and print their names and replica counts.
4. **Delete Deployment:** This will delete the Deployment object and its
   dependent ReplicaSet resource. Verify with `kubectl get deployments`.

Each step is separated by an interactive prompt. You must hit the
<kbd>Return</kbd> key to proceed to the next step. You can use these prompts as
a break to take time to run `kubectl` and inspect the result of the operations
executed.

You should see an output like the following:

```
Creating deployment...
Created deployment "demo-deployment".
-> Press Return key to continue.

Updating deployment...
Updated deployment...
-> Press Return key to continue.

Listing deployments in namespace "default":
 * demo-deployment (1 replicas)
-> Press Return key to continue.

Deleting deployment...
Deleted deployment.
```

## Cleanup

Successfully running this program will clean the created artifacts. If you
terminate the program without completing, you can clean up the created
deployment with:

    kubectl delete deploy demo-deployment

## Troubleshooting

If you are getting the following error, make sure Kubernetes version of your
cluster is v1.6 or above in `kubectl version`:

    panic: the server could not find the requested resource

[1]: https://kubernetes.io/docs/user-guide/deployments/

---

## File: examples/workqueue/README.md

# Workqueue Example

This example demonstrates how to write a controller which follows the states
of watched resources.

It demonstrates how to:
 * combine the workqueue with a cache to a full controller
 * synchronize the controller on startup

The example is based on https://git.k8s.io/community/contributors/devel/sig-api-machinery/controllers.md.

## Running

```
# if outside of the cluster
go run *.go -kubeconfig=/my/config
```

---

## File: examples/README.md

# client-go Examples

This directory contains examples that cover various use cases and functionality
for client-go.

### Auth plugins

Client configuration is typically loaded from kubeconfig files containing server and credential configuration.
Several plugins for obtaining credentials from external sources are available, but are not loaded by default.
To enable these plugins in your program, import them in your main package.

You can load all auth plugins:
```go
import _ "k8s.io/client-go/plugin/pkg/client/auth"
```

Or you can load specific auth plugins:
```go
import _ "k8s.io/client-go/plugin/pkg/client/auth/azure"
import _ "k8s.io/client-go/plugin/pkg/client/auth/gcp"
import _ "k8s.io/client-go/plugin/pkg/client/auth/oidc"
```

### Configuration

- [**Authenticate in cluster**](./in-cluster-client-configuration): Configure a
  client while running inside the Kubernetes cluster.
- [**Authenticate out of cluster**](./out-of-cluster-client-configuration):
  Configure a client to access a Kubernetes cluster from outside.

### Basics

- [**Managing resources with API**](./create-update-delete-deployment): Create,
  get, update, delete a Deployment resource.

### Advanced Concepts

- [**Work queues**](./workqueue): Create a hotloop-free controller with the
  rate-limited workqueue and the [informer framework][informer].
- [**Custom Resource Definition (CRD)**](https://git.k8s.io/apiextensions-apiserver/examples/client-go):
  Register a custom resource type with the API, create/update/query this custom
  type, and write a controller that drives the cluster state based on the changes to
  the custom resources.
- [**Leader election**](./leader-election): Demonstrates the use of the leader election package, which can be used to implement HA controllers.

[informer]: https://godoc.org/k8s.io/client-go/tools/cache#NewInformer

### Testing

- [**Fake Client**](./fake-client): Use a fake client in tests.

## 2. Official Technical Reference & Guides (kubernetes/kubernetes.github.io)

# The Kubernetes documentation

[](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [](https://github.com/kubernetes/website/releases/latest)

This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!

- [Contributing to the docs](#contributing-to-the-docs)
- [Localization READMEs](#localization-readmes)

## Using this repository

You can run the website locally using [Hugo (Extended version)](https://gohugo.io/), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.

## Prerequisites

To use this repository, you need the following installed locally:

- [npm](https://www.npmjs.com/)
- [Go](https://go.dev/)
- [Hugo (Extended version)](https://gohugo.io/)
- A container runtime, like [Docker](https://www.docker.com/).

> [!NOTE]
Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L11) file.

Before you start, install the dependencies. Clone the repository and navigate to the directory:

```bash
git clone https://github.com/kubernetes/website.git
cd website
```

The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme),
which can be installed via npm. You can also download a pre-configured
development container image that includes Hugo and Docsy. Additionally, a Git
submodule is used for tools that generate the reference documentation.

### Windows

```powershell
# fetch submodule dependencies
git submodule update --init --recursive --depth 1
```

### Linux / other Unix

```bash
# fetch submodule dependencies
make module-init
```

## Running the website using a container

To build the site in a container, run the following:

```bash
# You can set $CONTAINER_ENGINE to the name of any Docker-like container tool

# Render the full website
make container-serve

# Render only a specific language segment (e.g., English)
make container-serve segments=en

# Render multiple languages (e.g., English and Korean)
make container-serve segments=en,ko
```

**💡 Tip:** Using _Hugo segments_ speeds up local preview builds, by rendering only selected language(s).

If you see errors, it probably means that the Hugo container did not have enough computing resources available. To solve it, increase the amount of allowed CPU and memory usage for Docker on your machine ([macOS](https://docs.docker.com/desktop/settings/mac/) and [Windows](https://docs.docker.com/desktop/settings/windows/)).

Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.

## Running the website locally using Hugo

To install dependencies, deploy and test the site locally, run:

- For macOS and Linux

  ```bash
  npm ci

  # Render the full site (default)
  make serve

  # Render only a specific language segment
  make serve segments=en

  # Render multiple language segments
  make serve segments=en,ko
  ```

**💡 Tip:** Hugo segments are defined in `hugo.toml` and allow faster rendering by limiting the scope to specific language(s).

- For Windows (PowerShell)

  ```powershell
  npm ci
  hugo.exe server --config hugo.toml,hugo.server.toml --buildFuture --environment development
  ```

This will start the local Hugo server on port 1313. Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.


## Building the API reference pages

The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, also known as OpenAPI specification, using <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.

To update the reference pages for a new Kubernetes release follow these steps:

1. Pull in the `api-ref-generator` submodule:

   ```bash
   git submodule update --init --recursive --depth 1
   ```

2. Update the Swagger specification:

   ```bash
   curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
   ```

3. In `api-ref-assets/config/`, adapt the files `toc.yaml` and `fields.yaml` to reflect the changes of the new release.

4. Next, build the pages:

   ```bash
   make api-reference
   ```

   You can test the results locally by building and serving the site from a container:

   ```bash
   make container-serve
   ```

   In a web browser, go to <http://localhost:1313/docs/reference/kubernetes-api/> to view the API reference.

5. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages.

## Troubleshooting

If you experience any issues with running website locally, please refer
to the [Troubleshooting section](https://kubernetes.io/docs/contribute/new-content/preview-locally/#troubleshooting) of the contributing documentation.

## Get involved with SIG Docs

Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/main/sig-docs#meetings).

You can also reach the maintainers of this project at:

- [Slack](https://kubernetes.slack.com/messages/sig-docs)
  - [Get an invite for this Slack](https://slack.k8s.io/)
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)

## Contributing to the docs

You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a _fork_. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.

Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**

Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.

Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.

For more information about contributing to the Kubernetes documentation, see:

- [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
- [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
- [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
- [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
- [Introduction to Kubernetes Docs](https://www.youtube.com/watch?v=pprMgmNzDcw)

### New contributor ambassadors

If you need help at any point when contributing, the [New Contributor Ambassadors](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador) are a good point of contact. These are SIG Docs approvers whose responsibilities include mentoring new contributors and helping them through their first few pull requests. The best place to contact the New Contributors Ambassadors would be on the [Kubernetes Slack](https://slack.k8s.io/). Current New Contributors Ambassadors for SIG Docs:

| Name                       | Slack                      | GitHub                     |
| -------------------------- | -------------------------- | -------------------------- |
| Sreeram Venkitesh          | @sreeram.venkitesh         | @sreeram-venkitesh         |

## Localization READMEs

| Language                   | Language                   |
| -------------------------- | -------------------------- |
| [Bengali](./content/bn/README.md)    | [Korean](./content/ko/README.md)    |
| [Chinese](./content/zh-cn/README.md)    | [Polish](./content/pl/README.md)    |
| [French](./content/fr/README.md)     | [Portuguese](./content/pt-br/README.md)    |
| [German](./content/de/README.md)     | [Russian](./content/ru/README.md)    |
| [Hindi](./content/hi/README.md)      | [Spanish](./content/es/README.md)    |
| [Indonesian](./content/id/README.md) | [Ukrainian](./content/uk/README.md) |
| [Italian](./content/it/README.md)    | [Vietnamese](./content/vi/README.md) |
| [Japanese](./content/ja/README.md)   | |

## Code of conduct

Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).

## Thank you

Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!