jiebi/CodeConvo huggingface dataset:
<!--more--> <!-- <del> Kubernetes supports several container runtimes: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) and any implementation of the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). </del> <ins> Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, and any implementation of the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). </ins> --> <del> Kubernetes 支持多个容器运行环境: [Docker](http://www.docker.com)、 [containerd](https://containerd.io)、[cri-o](https://cri-o.io/)、 [rktlet](https://github.com/kubernetes-incubator/rktlet) 以及任何实现 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)。 </del> <ins> Kubernetes 支持多个容器运行环境: {{< glossary_tooltip term_id="docker">}}、 {{< glossary_tooltip term_id="containerd" >}}、{{< glossary_tooltip term_id="cri-o" >}} 以及任何实现 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)。 </ins>
<ins> --- title: "互动教程 - 配置 java 微服务" weight: 20 --- <!-- --- title: "Interactive Tutorial - Configuring a Java Microservice" weight: 20 --- --> <!DOCTYPE html> <html lang="en"> <body> <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet"> <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet"> <script src="https://katacoda.com/embed.js"></script> <div class="layout" id="top"> <main class="content katacoda-content"> <div class="katacoda"> <div class="katacoda__alert"> <!-- To interact with the Terminal, please use the desktop/tablet version --> 如需要与终端交互，请使用台式机/平板电脑版 </div> <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/9" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div> </div> </main> </div> </body> </html> </ins>
<p>Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.</p> <del> {{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times">}} <iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe> <iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe> <br> </del> <ins> {{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}} {{< youtube DqS_IPw-c6o youtube-quote-sm >}} {{< youtube Tm4VfJtOHt8 youtube-quote-sm >}} </ins> "I think once you get over the initial hump, things get a lot easier and actually a lot faster." {{< /case-studies/quote >}}
{{ else }} <div class="quote banner"> {{ end }} <del> <p class="quote-text"> {{ .Inner }} </del> <ins> <div class="quote-text"> {{ .Inner | markdownify }} </ins> {{ if .Get "author" }} <span class="quote-author">&mdash; {{ .Get "author" }}</span> {{ end }} <del> </p> </del> <ins> </div> </ins> </div>
之间的分布，例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。 这样做有助于实现高可用并提升资源利用率。 <ins> <!-- {{< note >}} In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/concepts/overview/components/#kube-apiserver) and the [scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod topology spread constraints. {{< /note >}} --> {{< note >}} 在 v1.19 之前的 Kubernetes 版本中，如果要使用 Pod 拓扑扩展约束，你必须在 [API 服务器](/zh/docs/concepts/overview/components/#kube-apiserver) 和[调度器](/zh/docs/reference/command-line-tools-referene/kube-scheduler/) 中启用 `EvenPodsSpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}} </ins> <!-- body --> <!--
The second element specifies that the value of the Pod's `annotations` field should be stored in a file named `annotations`. --> <del> 在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc` 目录。 </del> <ins> 在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc/podinfo` 目录。 </ins> 查看 `downwardAPI` 下面的 `items` 数组。 每个数组元素都是一个
lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels <del> /etc/..2982_06_02_21_47_53.299460680: </del> <ins> /etc/podinfo/..2982_06_02_21_47_53.299460680: </ins> total 8 -rw-r--r--  ... Feb  6 21:47 annotations -rw-r--r--  ... Feb  6 21:47 labels
Create the Pod: --> <del> 在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。 </del> <ins> 在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。 </ins> 查看 `downwardAPI` 下面的 `items` 数组。每个数组元素都是一个 DownwardAPIVolumeFile。
You can modify Node objects regardless of the setting of `--register-node`. For example, you can set labels on an existing Node, or mark it unschedulable. --> <del> #### 手动节点管理 </del> <ins> ### 手动节点管理 </ins> 你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 来创建和修改 Node 对象。
| `MemoryPressure`    | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` | | `PIDPressure`    | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` | | `NetworkUnavailable`    | `True` if the network for the node is not correctly configured, otherwise `False` | <ins> {{< /table >}} </ins> --> {{< table caption = "节点状况及每种状况适用场景的描述" >}} | 节点状况       | 描述        |
| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | | `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` | | `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | <ins> {{< /table >}} </ins> <!-- If you use command-line tools to print details of a cordoned Node, the Condition includes
Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。 心跳有两种形式：`NodeStatus` 和 [`Lease` 对象] <del> (/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 </del> <ins> (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。 </ins> 每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}} 中都有一个与之关联的 `Lease` 对象。 `Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。
ExpirationSeconds is the requested duration of validity of the service account token. As the token approaches expiration, the kubelet volume plugin will proactively rotate the service account token. The kubelet will start trying to rotate the token if the token is older than 80 percent of its time to live or if the token is older than 24 hours.Defaults to 1 hour and must be at least 10 minutes. <del> ### Local / Temporary Directory {#Local / Temporary Directory} </del> <ins> ### Local / Temporary Directory {#Local-Temporary-Directory} </ins> - **emptyDir** (EmptyDirVolumeSource)
webhooks or validating admission controllers will permit the request to finish. If you disable the MutatingAdmissionWebhook, you must also disable the <del> `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1` </del> <ins> `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` </ins> group/version via the `--runtime-config` flag (both are on by default in versions >= 1.9).
different when read back. * Setting originally unset fields is less likely to cause problems than overwriting fields set in the original request. Avoid doing the latter. <del> * This is a beta feature. Future versions of Kubernetes may restrict the types of mutations these webhooks can make. </del> * Future changes to control loops for built-in resources or third-party resources may break webhooks that work well today. Even when the webhook installation API is finalized, not all possible webhook behaviors will be guaranteed to be supported
### ValidatingAdmissionWebhook {#validatingadmissionwebhook} <del> {{< feature-state for_k8s_version="v1.13" state="beta" >}} </del> This admission controller calls any validating webhooks which match the request. Matching webhooks are called in parallel; if any of them rejects the request, the request fails. This admission controller only runs in the validation phase; the webhooks it calls may not
webhooks or other validating admission controllers will permit the request to finish. If you disable the ValidatingAdmissionWebhook, you must also disable the <del> `ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1` </del> <ins> `ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` </ins> group/version via the `--runtime-config` flag (both are on by default in versions 1.9 and later).
| ---------------------------------------- | ---------- | ------- | ----------- | | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | <del> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | | </del> <ins> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet pods tolerate disk-pressure attributes by default scheduler. | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet pods tolerate memory-pressure attributes by default scheduler. | </ins> | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: <ins> {% include code.html language="yaml" file="bad-nginx-deployment.yaml" ghlink="/docs/user-guide/bad-nginx-deployment.yaml" %} </ins> ```shell $ kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml deployment "nginx-deployment" configured
{{< note >}} While any plugin can access the list of "waiting" Pods and approve them <del> (see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit </del> <ins> (see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit </ins> plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}}
} ``` <del> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](#accessing-the-api-from-within-a-pod). </del> <ins> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod). </ins> #### Python client
* Пробуете или начинаете работу с Kubernetes * Локально разрабатываете и тестируете кластер <del> Выбрать [решение для запуска на локальной машине](/docs/setup/pick-right-solution/#local-machine-solutions). </del> <ins> Выбрать [решение для запуска на локальной машине](/docs/setup/learning-environment/). </ins> ## Управляемые решения
all: build ## Build site with production settings and put deliverables in ./public <del> build: module-check ## Build site with production settings and put deliverables in ./public hugo --minify </del> <ins> build: module-check ## Build site with non-production settings and put deliverables in ./public hugo --minify --environment development </ins> build-preview: module-check ## Build site with drafts and future posts enabled <del> hugo --buildDrafts --buildFuture </del> <ins> hugo --buildDrafts --buildFuture --environment preview </ins> deploy-preview: ## Deploy preview site via netlify <del> hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL) </del> <ins> hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL) </ins> functions-build: $(NETLIFY_FUNC) build functions-src
check-headers-file: scripts/check-headers-file.sh <del> production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added </del> <ins> production-build: module-check ## Build the production site and ensure that noindex headers aren't added hugo --minify --environment production HUGO_ENV=production $(MAKE) check-headers-file </ins> <del> non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo </del> <ins> non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo --environment nonprod </ins> serve: module-check ## Boot the development server. <del> hugo server --buildFuture </del> <ins> hugo server --buildFuture --environment development </ins> docker-image: @echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
--build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" </del> <ins> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development" </ins> container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. <del> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </del> <ins> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </ins> test-examples: scripts/test_examples.sh install
$(MAKE) container-internal-linkcheck container-internal-linkcheck: link-checker-image-pull <del> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture </del> <ins> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test </ins> $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md
<!doctype html> <html lang="{{ .Site.Language.Lang }}" class="{{.Params.class}} no-js"> <del> <head> </del> <ins> {{- if eq hugo.Environment "preview" -}} <!-- deploy preview --> {{- end -}} <head {{- if hugo.IsProduction -}}class="live-site"{{- end -}}> </ins> {{ partial "head.html" . }} </head> <body class="td-{{ .Kind }}{{- if ne (lower .Params.cid) "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">
{{- $isBlogPost := eq .Section "blog" }} {{- $ogType := cond (.IsHome) "website" "article" }} <ins> <!-- per-page robot indexing controls --> {{- if hugo.IsProduction -}} <meta name="ROBOTS" content="INDEX, FOLLOW"> {{- else -}} <meta name="ROBOTS" content="NOINDEX, NOFOLLOW"> {{- end -}} </ins> <!-- Global site tag (gtag.js) - Google Analytics --> <script async src="https://www.googletagmanager.com/gtag/js?id=UA-36037335-10"></script> <script>
<meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> {{ hugo.Generator }} <del> {{ if eq (getenv "HUGO_ENV") "production" }} <META NAME="ROBOTS" CONTENT="INDEX, FOLLOW"> {{ else }} <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW"> {{ end }} </del> {{ range .AlternativeOutputFormats -}} <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}"> {{ end -}}
{{- template "_internal/google_news.html" . -}} {{- template "_internal/schema.html" . -}} {{- template "_internal/twitter_cards.html" . -}} <del> {{ if eq (getenv "HUGO_ENV") "production" }} </del> <ins> {{- if hugo.IsProduction -}} </ins> {{ template "_internal/google_analytics_async.html" . }} {{ end }} {{ partialCached "head-css.html" . "asdf" }}
command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.branch-deploy] <del> command = "git submodule update --init --recursive --depth 1 && make deploy-preview" </del> <ins> command = "git submodule update --init --recursive --depth 1 && make non-production-build" </ins> <del> [context.master] # This context is triggered by the `master` branch and allows search indexing </del> <ins> [context.main] # This context is triggered by the `main` branch and allows search indexing </ins> # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" command = "git submodule update --init --recursive --depth 1 && make production-build" <del> # adding in headers to prevent clickjacking [[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY" X-XSS-Protection = "1; mode=block" </del>
### Migrating to the `systemd` driver in kubeadm managed clusters <del> Follow this [Migration guide](docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </del> <ins> Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </ins> if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. ## Container runtimes
kubernetesVersion: v1.16.0 scheduler: extraArgs: <del> bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml </del> <ins> config: /etc/kubernetes/scheduler-config.yaml extraVolumes: - name: schedulerconfig hostPath: /home/johndoe/schedconfig.yaml mountPath: /etc/kubernetes/scheduler-config.yaml readOnly: true pathType: "File" </ins> ```
the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.
object named `default` for every namespace in your cluster. The `default` service accounts in each namespace get no permissions by default other than the [default API discovery permissions](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) <del> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{<glossary_tooltip text="control plane" term_id="control-plane">}} </del> <ins> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} </ins> replaces it with a new one. If you deploy a Pod in a namespace, and you don't
following methods: * [TokenRequest API](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) <del> (recommended): Request a short-lived service account token using your *application code*. The token expires automatically and can rotate upon expiration. </del> <ins> (recommended): Request a short-lived service account token from within your own *application code*. The token expires automatically and can rotate upon expiration. If you have a legacy application that is not aware of Kubernetes, you could use a sidecar container within the same pod to fetch these tokens and make them available to the application workload. </ins> * [Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) <del> (recommended): In Kubernetes v1.20 and later, use the Pod specification to </del> <ins> (also recommended): In Kubernetes v1.20 and later, use the Pod specification to </ins> tell the kubelet to add the service account token to the Pod as a *projected volume*. Projected tokens expire automatically, and the kubelet rotates the token before it expires.
with static, long-lived credentials. In Kubernetes v1.24 and later, the [LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) prevents Kubernetes from automatically creating these tokens for <del> ServiceAccounts. </del> <ins> ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled by default; in other words, Kubernetes does not create these tokens. </ins> ## Authenticating service account credentials {#authenticating-credentials}
trust relationship exists. Depending on how the token was issued (either time-limited using a `TokenRequest` or using a legacy mechanism with a Secret), a ServiceAccount token might also have an expiry time, an audience, <del> and a time after which the token *starts* being valid. When a process running in a Pod attempts to communicate with the Kubernetes API server, it adds an `Authorization: Bearer <token>` header to the HTTP request. The API server checks the validity of the bearer token as follows: </del> <ins> and a time after which the token *starts* being valid. When a client that is acting as a ServiceAccount tries to communicate with the Kubernetes API server, the client includes an `Authorization: Bearer <token>` header with the HTTP request. The API server checks the validity of that bearer token as follows: </ins> 1. Check the token signature. 1. Check whether the token has expired. <del> 1. Checks whether object references in the token claims are currently valid </del> <ins> 1. Check whether object references in the token claims are currently valid. </ins> 1. Check whether the token is currently valid. 1. Check the audience claims. <ins> The TokenRequest API produces _bound tokens_ for a ServiceAccount. This binding is linked to the lifetime of the client, such as a Pod, that is acting as that ServiceAccount. </ins> For tokens issued using the `TokenRequest` API, the API server also checks that the specific object reference that is using the ServiceAccount still exists, matching by the {{< glossary_tooltip term_id="uid" text="unique ID" >}} of that
For more information about the authentication process, refer to [Authentication](/docs/reference/access-authn-authz/authentication/#service-account-tokens). <del> ### Authenticating service account credentials in your own code {authenticating-in-code} </del> <ins> ### Authenticating service account credentials in your own code {#authenticating-in-code} </ins> If you have services of your own that need to validate Kubernetes service account credentials, you can use the following methods: