jiebi/CodeConvo huggingface dataset:
## {{% heading "whatsnext" %}} <del> [크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은 </del> <ins> [크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은 </ins> 크론잡 `schedule` 필드의 포맷을 문서화 한다. 크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
- Visit the Netlify page preview for a PR to make sure things look good before approving. - Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this <del> rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) </del> <ins> rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/). </ins> for more details. ### Becoming an approver
2. Assign the PR to one or more current SIG Docs approvers. <del> If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. </del>  No newline at end of file <ins> If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. ## {{% heading "whatsnext" %}} - Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation. </ins>  No newline at end of file
nssm set kube-proxy DependOnService kubelet nssm start kube-proxy <del> # Register kube-proxy.exe (overlay / vxlan) </del> <ins> # kube-proxy.exeを登録する (overlay / vxlan) </ins> nssm install kube-proxy C:kkube-proxy.exe nssm set kube-proxy AppDirectory c:k nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:kconfig --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
- containerPort: 80 ``` <del> ### Deployment with kubeadm and cluster API </del> <ins> ### kubeadmとクラスターAPIを使用したデプロイ </ins> <del> Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned. </del> <ins> Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 </ins> <del> ### A few other key features * Beta support for Group Managed Service Accounts * More CNIs * More Storage Plugins </del> <ins> ### その他の主な機能 * グループ管理サービスアカウントのベータサポート * その他のCNI * その他のストレージプラグイン </ins>
convert your old configuration files to a newer version. `kubeadm config images list` and `kubeadm config images pull` can be used to list and pull the images that kubeadm requires. <ins> For more information navigate to [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). </ins> In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) has to be used.
It's possible to configure `kubeadm init` with a configuration file instead of command line flags, and some more advanced features may only be available as <del> configuration file options. This file is passed with the `--config` option. </del> <ins> configuration file options. This file is passed using the `--config` flag and it must contain a `ClusterConfiguration` structure and optionally more structures separated by `---n` Mixing `--config` with others flags may not be allowed in some cases. </ins> The default configuration can be printed out using the [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. <del> It is **recommended** that you migrate your old `v1beta1` configuration to `v1beta2` using </del> <ins> If your configuration is not using the latest version it is **recommended** that you migrate using </ins> the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. <del> For more details on each field in the `v1beta2` configuration you can navigate to our [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2). </del> <ins> For more information on the fields and usage of the configuration you can navigate to our API reference page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories). </ins> ### Adding kube-proxy parameters {#kube-proxy}
It's possible to configure `kubeadm join` with a configuration file instead of command line flags, and some more advanced features may only be available as configuration file options. This file is passed using the `--config` flag and it must <del> contain a `JoinConfiguration` structure. </del> <ins> contain a `JoinConfiguration` structure. Mixing `--config` with others flags may not be allowed in some cases. </ins> <del> To print the default values of `JoinConfiguration` run the following command: </del> <ins> The default configuration can be printed out using the [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. </ins> <del> ```shell kubeadm config print join-defaults ``` </del> <ins> If your configuration is not using the latest version it is **recommended** that you migrate using the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. </ins> <del> For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration). </del> <ins> For more information on the fields and usage of the configuration you can navigate to our API reference page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories). </ins> ## {{% heading "whatsnext" %}}
For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/). <del> For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). </del> <ins> To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). </ins> To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
However, the particular path specified in the custom recycler Pod template in the `volumes` part is replaced with the particular path of the volume that is being recycled. <ins> ### Reserving a PersistentVolume The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) in the cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them. By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a binding between that specific PV and PVC. If the PersistentVolume exists and has not reserved PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and PersistentVolumeClaim will be bound. The binding happens regardless of some volume matching criteria, including node affinity. The control plane still checks that [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid. ``` apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: foo spec: volumeName: foo-pv ... ``` This method does not guarantee any binding privileges to the PersistentVolume. If other PersistentVolumeClaims could use the PV that you specify, you first need to reserve that storage volume. Specify the relevant PersistentVolumeClaim in the `claimRef` field of the PV so that other PVCs can not bind to it. ``` apiVersion: v1 kind: PersistentVolume metadata: name: foo-pv spec: claimRef: name: foo-pvc namespace: foo ... ``` This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set to `Retain`, including cases where you are reusing an existing PV. </ins> ### Expanding Persistent Volumes Claims {{< feature-state for_k8s_version="v1.11" state="beta" >}}
(ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory. <del> 1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager. </del> <ins> 1. Update {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}'s `--root-ca-file` to include both old and new CA. Then restart the component. </ins> Any service account created after this point will get secrets that include both old and new CAs. {{< note >}} <del> Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle. </del> <ins> The files specified by the kube-controller-manager flags `--client-ca-file` and `--cluster-signing-cert-file` cannot be CA bundles. If these flags and `--root-ca-file` point to the same `ca.crt` file which is now a bundle (includes both old and new CA) you will face an error. To workaround this problem you can copy the new CA to a separate file and make the flags `--client-ca-file` and `--cluster-signing-cert-file` point to the copy. Once `ca.crt` is no longer a bundle you can restore the problem flags to point to `ca.crt` and delete the copy. </ins> {{< /note >}} 1. Update all service account tokens to include both old and new CA certificates.
and if `concurrencyPolicy` is set to `Allow`, the jobs will always run at least once. <ins> {{< caution >}} If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob may not be scheduled. This is because the CronJob controller checks things every 10 seconds. {{< /caution >}} </ins> For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error ````
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) <del> * Kube-proxy running in mode IPVS </del> * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster {{< version-check >}}
<ins> --- title: コンテンツの改善を提案する slug: suggest-improvements content_type: concept weight: 10 card: name: contribute weight: 20 --- <!-- overview --> Kubernetesのドキュメントに何か問題を見つけたり、新しいコンテンツに関してアイデアを思い付いたときは、issueを作ってください。必要なものは、[GitHubアカウント](https://github.com/join)とウェブブラウザーだけです。 Kubernetesのドキュメント上の新しい作業は、ほとんどの場合、GitHubのissueから始まります。Kubernetesのコントリビューターは、必要に応じてレビュー、分類、タグ付けを行います。次に、あなたやKubernetesコミュニティの他のメンバーが、そのissueを解決するための変更を加えるpull requestを開きます。 <!-- body --> ## issueを作る 既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。 1. ページの右側のサイドバーにある**ドキュメントのissueを作成**ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。 2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。 3. **Submit new issue**ボタンをクリックします。 送信後、定期的にissueを確認するか、GitHubの通知を設定してください。レビュアや他のコミュニティメンバーが、issueに対して作業を行うために、あなたに何か質問をするかもしれません。 ## 新しいコンテンツの提案 新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。 - コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**ボタンをクリックする。 - [GitHub](https://github.com/kubernetes/website/issues/new/)に移動し、直接issueを作る。 ## よいissueを作るには issueを作るときは、以下のことを心に留めてください。 - 明確なissueの説明を書く。不足している点、古くなっている点、誤っている点、改善が必要な点など、どの点がそうであるか明確に書く。 - issueがユーザーに与える具体的な影響を説明する。 - 合理的な作業単位になるように、特定のissueのスコープを制限する。スコープの大きな問題については、小さな複数のissueに分割する。たとえば、"Fix the security docs"(セキュリティのドキュメントを修正する)というのはスコープが大きすぎますが、"Add details to the 'Restricting network access' topic"(トピック「ネットワークアクセスの制限」に詳細情報を追加する)であれば十分に作業可能な大きさです。 - すでにあるissueを検索し、関連または同様のissueがないかどうか確認する。 - 新しいissueがほかのissueやpull requestと関係する場合は、完全なURLを参照するか、issueやpull requestの数字の前に`#`の文字を付けて参照する。例えば、`Introduced by #987654`のように書きます。 - [行動規範](/ja/community/code-of-conduct/)に従って、仲間のコントリビューターに敬意を払いましょう。たとえば、"The docs are terrible"(このドキュメントは最悪だ)のようなコメントは、役に立つ敬意のあるフィードバックではありません。 </ins>
/docs/reference/glossary/maintainer/    /docs/reference/glossary/approver/ 301 <ins> /docs/reference/kubectl/kubectl-cmds/     /docs/reference/generated/kubectl/kubectl-commands/ 301! </ins> /docs/reference/kubectl/kubectl/kubectl_*.md    /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/    /docs/reference/scheduling/config/#profiles 301
from the community. Please try it out and give us feedback! {{< /caution >}} <ins> ## kubeadm alpha certs {#cmd-certs} A collection of operations for operating Kubernetes certificates. {{< tabs name="tab-certs" >}} {{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs renew {#cmd-certs-renew} You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.
{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.
{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} <ins> ## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the `all` subcommand to run all `kubelet-finalize` phases. {{< tabs name="tab-kubelet-finalize" >}} {{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} {{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} {{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} {{< /tabs >}} </ins> ## kubeadm init phase addon {#cmd-phase-addon}
{{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}
<ins> --- title: 对象 id: object date: 2020-10-12 full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects short_description: > Kubernetes 系统中的实体, 代表了集群的部分状态。 aka: tags: - fundamental --- <!-- --- title: Object id: object date: 2020-10-12 full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects short_description: > A entity in the Kubernetes system, representing part of the state of your cluster. aka: tags: - fundamental --- --> <!-- An entity in the Kubernetes system. The Kubernetes API uses these entities to represent the state of your cluster. --> Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。 <!--more--> <!-- A Kubernetes object is typically a “record of intent”—once you create the object, the Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} works constantly to ensure that the item it represents actually exists. By creating an object, you're effectively telling the Kubernetes system what you want that part of your cluster's workload to look like; this is your cluster's desired state. --> Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 不断工作，以确保它代表的项目确实存在。 创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。 </ins>  No newline at end of file
--- reviewers: <del> title: Configuring kubelet Garbage Collection </del> <ins> title: Garbage collection for container images </ins> content_type: concept weight: 70 --- <!-- overview --> <del> Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. </del> <ins> Garbage collection is a helpful function of kubelet that will clean up unused [images](/docs/concepts/containers/#container-images) and unused [containers](/docs/concepts/containers/). Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. </ins> External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.
You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: --> <del> ## Service 安全 </del> <ins> ## 保护 Service {#securing-the-service} </ins> <del> 到现在为止，我们只在集群内部访问了 Nginx server。在将 Service 暴露到 Internet 之前，我们希望确保通信信道是安全的。对于这可能需要： </del> <ins> 到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。 为实现这一目的，可能需要： </ins> <del> * https 自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx server </del> <ins> * 用于 HTTPS 的自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx 服务器 </ins> * 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) <del> 可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下： </del> <ins> 你可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/) 获取所有上述内容。你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照 后文所述的手动执行步骤执行操作。简要过程如下： </ins> ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
<!-- Following are the manual steps to follow in case you run into problems running make (on windows for example): --> <del> 以下是您在运行make时遇到问题时要遵循的手动步骤（例如，在Windows上）： </del> <ins> 以下是你在运行 make 时遇到问题时要遵循的手动步骤（例如，在 Windows 上）： </ins> ```shell # Create a public private key pair
<!-- Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line. --> <del> 使用前面命令的输出来创建yaml文件，如下所示。 base64编码的值应全部放在一行上。 </del> <ins> 使用前面命令的输出来创建 yaml 文件，如下所示。 base64 编码的值应全部放在一行上。 </ins> ```yaml apiVersion: "v1"
<!-- Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): --> <del> 现在修改 Nginx 副本，启动一个使用在秘钥中的证书的 https 服务器和 Servcie，都暴露端口（80 和 443）： </del> <ins> 现在修改 nginx 副本，启动一个使用在秘钥中的证书的 HTTPS 服务器和 Servcie，暴露端口（80 和 443）： </ins> {{< codenew file="service/networking/nginx-secure-app.yaml" >}}
- Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`. This is setup *before* the nginx server is started. --> <ins> 关于 nginx-secure-app 清单，值得注意的几点如下： </ins> <del> 关于 nginx-secure-app manifest 值得注意的点如下： - 它在相同的文件中包含了 Deployment 和 Service 的规格 - [Nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443  端口上的 https 流量，Nginx Service 暴露了这两个端口。 - 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。 </del> <ins> - 它在相同的文件中包含了 Deployment 和 Service 的规约 - [nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf) 处理 80 端口上的 HTTP 流量，以及 443  端口上的 HTTPS 流量，Nginx Service 暴露了这两个端口。 - 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx 服务器启动之前安装好。 </ins> ```shell kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
so we have to tell curl to ignore the CName mismatch. By creating a Service we linked the CName used in the certificate with the actual DNS name used by pods during Service lookup. Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service): --> <del> 注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时， 我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。 </del> <ins> 注意最后一步我们是如何提供 `-k` 参数执行 curl 命令的，这是因为在证书生成时， 我们不知道任何关于运行 nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod 使用的实际 DNS 名字。 </ins> 让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）： {{< codenew file="service/networking/curlpod.yaml" >}}
Let's now recreate the Service to use a cloud load balancer, just change the `Type` of `my-nginx` Service from `NodePort` to `LoadBalancer`: --> <del> 让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。 </del> <ins> 让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。 </ins> ```shell kubectl edit svc my-nginx
在开始本教程之前，你应该熟悉以下 Kubernetes 的概念： <del> * [Pods](/zh/docs/user-guide/pods/single-container/) </del> <ins> * [Pods](/zh/docs/concepts/workloads/pods/) </ins> * [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) * [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) * [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
即使你已经删除了 StatefulSet 和它的全部 Pod，这些 Pod 将会被重新创建并挂载它们的 PersistentVolumes，并且 `web-0` 和 `web-1` 将仍然使用它们的主机名提供服务。 <del> 最后删除 `web` StatefulSet 和 `nginx` service。 </del> <ins> 最后删除 `nginx` service... </ins> ```shell kubectl delete service nginx <ins> ``` ``` </ins> service "nginx" deleted <ins> ``` ... 并且删除 `web` StatefulSet: ```shell </ins> kubectl delete statefulset web <ins> ``` ``` </ins> statefulset "web" deleted ```
<ins> <script src="/js/popper-1.14.3.min.js" integrity="sha384-ZMP7rVo3mIykV+2+9J3UJ46jBk0WLaUAdn689aCwoqbBJiSnjAK/l8WvCWPIPm49" crossorigin="anonymous"></script> <script src="/js/bootstrap-4.3.1.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script> {{ if .Site.Params.mermaid.enable }} <script src="/js//mermaid.min.js" crossorigin="anonymous"></script> {{ end }} {{ $jsBase := resources.Get "js/base.js" }} {{ $jsAnchor := resources.Get "js/anchor.js" }} {{ $jsSearch := resources.Get "js/search.js" | resources.ExecuteAsTemplate "js/search.js" .Site.Home }} {{ $jsMermaid := resources.Get "js/mermaid.js" | resources.ExecuteAsTemplate "js/mermaid.js" . }} {{ if .Site.Params.offlineSearch }} {{ $jsSearch = resources.Get "js/offline-search.js" }} {{ end }} {{ $js := (slice $jsBase $jsAnchor $jsSearch $jsMermaid) | resources.Concat "js/main.js" }} {{ if .Site.IsServer }} <script src="{{ $js.RelPermalink }}"></script> {{ else }} {{ $js := $js | minify | fingerprint }} <script src="{{ $js.RelPermalink }}" integrity="{{ $js.Data.Integrity }}" crossorigin="anonymous"></script> {{ end }} {{ with .Site.Params.prism_syntax_highlighting }} <!-- scripts for prism --> <script src='/js/prism.js'></script> {{ end }} {{ partial "hooks/body-end.html" . }} </ins>