Merge pull request #23441 from Vickey-Wu/patch-3

fix: image markdown symbol error

content/de/_index.html

@@ -42,7 +42,6 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Video ansehen</button>
         <br>
         <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Besuche die KubeCon - 13-16 August 2020 in Amsterdam</a>
         <br>
         <br>

content/en/blog/_posts/2020-08-25-kubernetes-release-1.19.md

@@ -0,0 +1,127 @@
+---
+layout: blog 
+title: 'Kubernetes  1.19: Accentuate the Paw-sitive'
+date: 2020-08-25 
+slug: kubernetes-release-1.19-accentuate-the-paw-sitive
+---
+
+**Authors:** [Kubernetes 1.19 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.19/release_team.md)
+
+Finally, we have arrived with Kubernetes 1.19, the second release for 2020, and by far the longest release cycle lasting 20 weeks in total. It consists of 33 enhancements: 12 enhancements are moving to stable, 18 enhancements in beta, and 13 enhancements in alpha. 
+
+The 1.19 release was quite different from a regular release due to COVID-19, the George Floyd protests, and several other global events that we experienced as a release team. Due to these events, we made the decision to adjust our timeline and allow the SIGs, Working Groups, and contributors more time to get things done. The extra time also allowed for people to take time to focus on their lives outside of the Kubernetes project, and ensure their mental wellbeing was in a good place. 
+
+Contributors are the heart of Kubernetes, not the other way around. The Kubernetes code of conduct asks that people be excellent to one another and despite the unrest in our world, we saw nothing but greatness and humility from the community. 
+
+## Major Themes
+### Increase Kubernetes support window to one year
+
+A survey conducted in early 2019 by the [Long Term Support (LTS) working group](https://github.com/kubernetes/community/tree/master/wg-lts#readme) showed that a significant subset of Kubernetes end-users fail to upgrade within the current 9-month support period. 
+This, and other responses from the survey, suggest that 30% of users would be able to keep their deployments on supported versions if the patch support period were extended to 12-14 months. This appears to be true regardless of whether the users are on self build or commercially vendored distributions. An extension would thus lead to more than 80% of users being on supported versions, instead of the 50-60% we have now.
+A yearly support period provides the cushion end-users appear to desire, and is more in harmony with familiar annual planning cycles.
+From Kubernetes version 1.19 on, the support window will be extended to one year.
+
+### Storage capacity tracking 
+
+Traditionally, the Kubernetes scheduler was based on the assumptions that additional persistent storage is available everywhere in the cluster and has infinite capacity. Topology constraints addressed the first point, but up to now pod scheduling was still done without considering that the remaining storage capacity may not be enough to start a new pod. [Storage capacity tracking](/docs/concepts/storage/storage-capacity/), a new alpha feature, addresses that by adding an API for a CSI driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod. This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained.
+
+#### Generic ephemeral volumes
+Kubernetes provides volume plugins whose lifecycle is tied to a pod and can be used as scratch space (e.g. the builtin `emptydir` volume type) or to load some data in to a pod (e.g. the builtin `configmap` and `secret` volume types, or “CSI inline volumes”). The new [generic ephemeral volumes](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) alpha feature allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume with the volume’s lifecycle bound to the Pod.
+It can be used to provide scratch storage that is different from the root disk, for example persistent memory, or a separate local disk on that node.
+All StorageClass parameters for volume provisioning are supported.
+All features supported with PersistentVolumeClaims are supported, such as storage capacity tracking, snapshots and restore, and volume resizing.
+
+#### CSI Volume Health Monitoring
+The alpha version of CSI health monitoring is being released with Kubernetes 1.19. This feature enables CSI Drivers to share abnormal volume conditions from the underlying storage systems with Kubernetes so that they can be reported as events on PVCs or Pods. This feature serves as a stepping stone towards programmatic detection and resolution of individual volume health issues by Kubernetes.
+
+### Ingress graduates to General Availability
+In terms of moving the Ingress API towards GA, the API itself has been available in beta for so long that it has attained de facto GA status through usage and adoption (both by users and by load balancer / ingress controller providers). Abandoning it without a full replacement is not a viable approach. It is clearly a useful API and captures a non-trivial set of use cases. At this point, it seems more prudent to declare the current API as something the community will support as a V1, codifying its status, while working on either a V2 Ingress API or an entirely different API with a superset of features. 
+
+### Structured logging
+Before v1.19, logging in the Kubernetes control plane couldn't guarantee any uniform structure for log messages and references to Kubernetes objects in those logs. This makes parsing, processing, storing, querying and analyzing logs hard and forces administrators and developers to rely on ad-hoc solutions in most cases based on some regular expressions. Due to those problems any analytical solution based on those logs is hard to implement and maintain.
+
+#### New klog methods
+This Kubernetes release introduces new methods to the _klog_ library that provide a more structured interface for formatting log messages. Each existing formatted log method (`Infof`, `Errorf`) is now matched by a structured method (`InfoS`, `ErrorS`). The new logging methods accept log messages as a first argument and a list of key-values pairs as a variadic second argument. This approach allows incremental adoption of structured logging without converting **all** of Kubernetes to a new API at one time.
+
+### Client TLS certificate rotation for kubelet
+
+A kubelet authenticates the kubelet to the kube-apiserver using a private key and certificate. The certificate is supplied to the kubelet when it is first booted, via an out-of-cluster mechanism. Since Kubernetes v1.8, clusters have included a (beta) process for obtaining the initial cert/key pair and rotating it as expiration of the certificate approaches. In Kubernetes v1.19 this graduates to stable. 
+
+During the kubelet start-up sequence, the filesystem is scanned for an existing cert/key pair, which is managed by the certificate manager. In the case that a cert/key is available it will be loaded. If not, the kubelet checks its config file for an encoded certificate value or a file reference in the kubeconfig. If the certificate is a bootstrap certificate, this will be used to generate a key, create a certificate signing request and request a signed certificate from the API server.
+
+When an expiration approaches the cert manager takes care of providing the correct certificate, generating new private keys and requesting new certificates. With the kubelet requesting certificates be signed as part of its boot sequence, and on an ongoing basis, certificate signing requests from the kubelet need to be auto approved to make cluster administration manageable.
+
+## Other Updates 
+### Graduated to Stable
+* [Seccomp](https://github.com/kubernetes/enhancements/issues/135)
+* [Kubelet client TLS certificate rotation](https://github.com/kubernetes/enhancements/issues/266)
+* [Limit node access to API](https://github.com/kubernetes/enhancements/issues/279)
+* [Redesign Event API](https://github.com/kubernetes/enhancements/issues/383)
+* [Graduate Ingress to V1](https://github.com/kubernetes/enhancements/issues/1453)
+* [CertificateSigningRequest API](https://github.com/kubernetes/enhancements/issues/1513)
+* [Building Kubelet without Docker](https://github.com/kubernetes/enhancements/issues/1547)
+
+### Major Changes
+* [Node Topology Manager](https://github.com/kubernetes/enhancements/issues/693)
+* [New Endpoint API](https://github.com/kubernetes/enhancements/issues/752)
+* [Increase Kubernetes support window to one year](https://github.com/kubernetes/enhancements/issues/1498)
+
+### Other Notable Features
+* [Run multiple Scheduling Profiles](https://github.com/kubernetes/enhancements/issues/1451)
+* [CertificateSigningRequest API](https://github.com/kubernetes/enhancements/issues/1513)
+* [Immutable Secrets and ConfigMaps](https://github.com/kubernetes/enhancements/issues/1412)
+
+## Release Notes
+Check out the full details of the Kubernetes 1.19 release in our [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md).
+
+## Availability
+
+Kubernetes 1.19 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/) or run local Kubernetes clusters using Docker container “nodes” with [KinD](https://kind.sigs.k8s.io/) (Kubernetes in Docker). You can also easily install 1.19 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). 
+
+## Release Team
+This release is made possible through the efforts of hundreds of individuals who contributed both technical and non-technical content. Special thanks to the [release team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.19/release_team.md) led by Taylor Dolezal, Senior Developer Advocate at HashiCorp. The 34 release team members coordinated many aspects of the release, from documentation to testing, validation, and feature completeness. 
+
+As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid pace. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. Kubernetes has had over [49,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 3,000 people.
+
+## Release Logo
+All of you inspired this Kubernetes 1.19 release logo! This release was a bit more of a marathon and a testament to when the world is a wild place, we can come together and do unbelievable things. 
+
+![Kubernetes 1.19 Release Logo](/images/blog/2020-08-26-kubernetes-1.19-release-announcement/accentuate.png)
+
+
+"Accentuate the Paw-sitive" was chosen as the release theme because it captures the positive outlook that the release team had, despite the state of the world. The characters pictured in the 1.19 logo represent everyone's personalities on our release team, from emo to peppy, and beyond! 
+
+About the designer: Hannabeth Lagerlof is a Visual Designer based in Los Angeles, California, and she has an extensive background in Environments and Graphic Design. Hannabeth creates art and user experiences that inspire connection. You can find Hannabeth on Twitter as @emanate_design.
+
+## The Long Run
+The release was also different from the enhancements side of things. Traditionally, we have had 3-4 weeks between the call for enhancements and Enhancements Freeze, which ends the phase in which contributors can acknowledge whether a particular feature will be part of the cycle. This release cycle, being unique, we had five weeks for the same milestone. The extended duration gave the contributors more time to plan and decide about the graduation of their respective features.
+
+The milestone until which contributors implement the features was extended from the usual five weeks to 7 weeks. Contributors were provided with 40% more time to work on their features, resulting in reduced fatigue and more to think through about the implementation. We also noticed a considerable reduction in last-minute hustles. There were also a lesser number of exception requests this cycle - 6 compared to 14 the previous release cycle.
+
+## User Highlights
+* The CNCF grants Zalando, Europe’s leading online platform for fashion and lifestyle, the [Top End User Award](https://www.cncf.io/announcement/2020/08/20/cloud-native-computing-foundation-grants-zalando-the-top-end-user-award/). Zalando leverages numerous CNCF projects and open sourced multiple of their own development.
+
+## Ecosystem Updates
+* The CNCF just concluded its very first Virtual KubeCon. All talks are [on-demand]( https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) for anyone registered, it's not too late!
+* The [Certified Kubernetes Security Specialist](https://www.cncf.io/blog/2020/07/15/certified-kubernetes-security-specialist-cks-coming-in-november/) (CKS) coming in November! CKS focuses on cluster & system hardening, minimizing microservice vulnerabilities and the security of the supply chain.
+* CNCF published the second [State of Cloud Native Development](https://www.cncf.io/blog/2020/08/14/state-of-cloud-native-development/), showing the massively growing number of cloud native developer using container and serverless technology.
+* [Kubernetes.dev](https://www.kubernetes.dev), a Kubernetes contributor focused website has been launched. It brings the  contributor documentation, resources and project event information into one central location.  
+
+## Project Velocity
+The [Kubernetes DevStats dashboard](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) illustrates the breakdown of contributions from major company contributors, as well as an impressive set of preconfigured reports on everything from individual contributors to pull request lifecycle times. If you want to gather numbers, facts and figures from Kubernetes and the CNCF community it is the best place to start. 
+
+During this release cycle from April till August, 382 different companies and over 2,464 individuals contributed to Kubernetes. [Check out DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All&from=1585692000000&to=1598392799000) to learn more about the overall velocity of the Kubernetes project and community.
+
+## Upcoming release webinar
+Join the members of the Kubernetes 1.19 release team on September 25th, 2020 to learn about the major features in this release including storage capacity tracking, structured logging, Ingress V1 GA, and many more. Register here: https://www.cncf.io/webinars/kubernetes-1-19/.
+
+## Get Involved
+The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our monthly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support.
+
+* Find out more about contributing to Kubernetes at the new [Kubernetes Contributor website](https://www.kubernetes.dev/)
+* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+* Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
+* Join the community on [Slack](http://slack.k8s.io/)
+* Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
+* Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
+* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)

content/ja/docs/reference/glossary/docker.md

@@ -0,0 +1,17 @@
+---
+title: Docker
+id: docker
+date: 2018-04-12
+full_link: https://docs.docker.com/engine/
+short_description: >
+  Dockerは、コンテナとして知られる、オペレーティングシステムレベルでの仮想化を提供するソフトウェア技術です。
+
+aka:
+tags:
+- fundamental
+---
+Docker(正確にはDocker Engine)は、{{< glossary_tooltip text="コンテナ" term_id="container" >}}としても知られる、オペレーティングシステムレベルでの仮想化を提供するソフトウェア技術です。
+
+<!--more-->
+
+Dockerは、cgroupsやカーネル名前空間などのLinuxカーネルのリソースの隔離機能、OverlayFSなどの統合能力のあるファイルシステム、独立したコンテナを単一のLinuxインスタンス内で実行可能にするその他の機能などを利用して、マシンレベルでの仮想マシン(VM)の起動にかかるオーバーヘッドを回避します。

content/ja/docs/reference/glossary/label.md

@@ -0,0 +1,17 @@
+---
+title: ラベル
+id: label
+date: 2018-04-12
+full_link: /docs/concepts/overview/working-with-objects/labels
+short_description: >
+  ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。
+
+aka: 
+tags:
+- fundamental
+---
+  ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。
+
+<!--more--> 
+
+ラベルは、{{< glossary_tooltip text="Pod" term_id="pod" >}}などのオブジェクトに付与されるキーと値のペアです。オブジェクトのサブセットを組織化したり選択したりするために使われます。

content/ja/docs/reference/glossary/mirror-pod.md

@@ -0,0 +1,18 @@
+---
+title: ミラーPod
+id: mirror-pod
+date: 2019-08-06
+short_description: >
+  kubelet上のstatic Podを追跡するAPIサーバー内のオブジェクトです。
+
+aka: 
+tags:
+- fundamental
+---
+kubeletが{{< glossary_tooltip text="static Pod" term_id="static-pod" >}}を代表するために使用する{{< glossary_tooltip text="Pod" term_id="pod" >}}オブジェクトです。
+
+<!--more--> 
+
+kubeletが設定の中にstatic Podを発見すると、static Podに対応するPodオブジェクトをKubernetes APIサーバー上に自動的に作成しようとします。つまり、APIサーバーからはPodが見えていますが、制御まではできないということです。
+
+(たとえば、ミラーPodを削除しても、kubeletデーモンが対応するPodの実行を停止することはありません。)

content/ja/docs/reference/glossary/selector.md

@@ -4,13 +4,13 @@ id: selector
 date: 2018-04-12
 full_link: /docs/concepts/overview/working-with-objects/labels/
 short_description: >
-  ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。
+  セレクターを利用すると、ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。
 
 aka: 
 tags:
 - fundamental
 ---
- ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。
+ セレクターを利用すると、ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。
 
 <!--more--> 
 

content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -1,30 +1,30 @@
 ---
-title: Guide for scheduling Windows containers in Kubernetes
+title: KubernetesでWindowsコンテナをスケジュールするためのガイド
 content_type: concept
 weight: 75
 ---
 
 <!-- overview -->
 
-Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
+Windowsアプリケーションは、多くの組織で実行されるサービスとアプリケーションの大部分を占めます。このガイドでは、KubernetesでWindowsコンテナを構成してデプロイする手順について説明します。
 
 
 
 <!-- body -->
 
-## Objectives
+## 目的
 
-* Configure an example deployment to run Windows containers on the Windows node
-* (Optional) Configure an Active Directory Identity for your Pod using Group Managed Service Accounts (GMSA)
+* WindowsノードでWindowsコンテナを実行するサンプルのDeploymentを構成します
+* (オプション)Group Managed Service Accounts(GMSA)を使用してPodのActive Directory IDを構成します
 
-## Before you begin
+## 始める前に
 
-* Create a Kubernetes cluster that includes a [master and a worker node running Windows Server](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/)
-* It is important to note that creating and deploying services and workloads on Kubernetes behaves in much the same way for Linux and Windows containers. [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. The example in the section below is provided simply to jumpstart your experience with Windows containers.
+* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/)を含むKubernetesクラスターを作成します
+* Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/docs/reference/kubectl/overview/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。
 
-## Getting Started: Deploying a Windows container
+## はじめに:Windowsコンテナのデプロイ
 
-To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below:
+WindowsコンテナをKubernetesにデプロイするには、最初にサンプルアプリケーションを作成する必要があります。以下のYAMLファイルの例では、簡単なウェブサーバーアプリケーションを作成しています。以下の内容で`win-webserver.yaml`という名前のサービススペックを作成します。:
 
 ```yaml
 apiVersion: v1
@@ -35,7 +35,7 @@ metadata:
     app: win-webserver
 spec:
   ports:
-    # the port that this service should serve on
+    # このサービスが提供するポート
     - port: 80
       targetPort: 80
   selector:
@@ -71,73 +71,74 @@ spec:
 ```
 
 {{< note >}}
-Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service.
+ポートマッピングもサポートされていますが、この例では簡単にするために、コンテナポート80がサービスに直接公開されています。
 {{< /note >}}
 
-1. Check that all nodes are healthy:
+1. すべてのノードが正常であることを確認します。:
 
     ```bash
     kubectl get nodes
     ```
 
-1. Deploy the service and watch for pod updates:
+1. Serviceをデプロイして、Podの更新を確認します。:
 
     ```bash
     kubectl apply -f win-webserver.yaml
     kubectl get pods -o wide -w
     ```
 
-    When the service is deployed correctly both Pods are marked as Ready. To exit the watch command, press Ctrl+C.
+    Serviceが正しくデプロイされると、両方のPodがReadyとして表示されます。watch状態のコマンドを終了するには、Ctrl + Cを押します。
 
-1. Check that the deployment succeeded. To verify:
+1. デプロイが成功したことを確認します。検証するために行うこと:
 
-    * Two containers per pod on the Windows node, use `docker ps`
-    * Two pods listed from the Linux master, use `kubectl get pods`
-    * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response
-    * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec
-    * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods
-    * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)
+    * WindowsノードのPodごとの2つのコンテナに`docker ps`します
+    * Linuxマスターからリストされた2つのPodに`kubectl get pods`します
+    * ネットワークを介したノードとPod間通信、LinuxマスターからのPod IPのポート80に向けて`curl`して、ウェブサーバーの応答をチェックします
+    * docker execまたはkubectl execを使用したPod間通信、Pod間(および複数のWindowsノードがある場合はホスト間)へのpingします
+    * ServiceからPodへの通信、Linuxマスターおよび個々のPodからの仮想Service IP(`kubectl get services`で表示される)に`curl`します
+    * サービスディスカバリ、Kuberntesの[default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)と共にService名に`curl`します
     * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
-    * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
+    * インバウンド接続、Linuxマスターまたはクラスター外のマシンからNodePortに`curl`します
+    * アウトバウンド接続、kubectl execを使用したPod内からの外部IPに`curl`します
 
 {{< note >}}
-Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
+今のところ、Windowsネットワークスタックのプラットフォーム制限のため、Windowsコンテナホストは、ホストされているサービスのIPにアクセスできません。Service IPにアクセスできるのは、Windows Podだけです。
 {{< /note >}}
 
-## Observability
+## 可観測性
 
-### Capturing logs from workloads
+### ワークロードからのログキャプチャ
 
-Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs <pod>`.
+ログは可観測性の重要な要素です。これにより、ユーザーはワークロードの運用面に関する洞察を得ることができ、問題のトラブルシューティングの主要な要素になります。WindowsコンテナとWindowsコンテナ内のワークロードの動作はLinuxコンテナとは異なるため、ユーザーはログの収集に苦労し、運用の可視性が制限されていました。たとえば、Windowsワークロードは通常、ETW(Windowsのイベントトレース)にログを記録するか、アプリケーションイベントログにエントリをプッシュするように構成されます。Microsoftのオープンソースツールである[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)は、Windowsコンテナ内の構成されたログソースを監視するための推奨方法です。LogMonitorは、イベントログ、ETWプロバイダー、カスタムアプリケーションログのモニタリングをサポートしており、それらをSTDOUTにパイプして、`kubectl logs <pod>`で使用できます。
 
-Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT.
+LogMonitor GitHubページの指示に従って、バイナリと構成ファイルをすべてのコンテナにコピーして、LogMonitorがログをSTDOUTにプッシュするために必要なエントリーポイントを追加します。
 
-## Using configurable Container usernames
+## 構成可能なコンテナのユーザー名の使用
 
-Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
+Kubernetes v1.16以降、Windowsコンテナは、イメージのデフォルトとは異なるユーザー名でエントリーポイントとプロセスを実行するように構成できます。これが達成される方法は、Linuxコンテナで行われる方法とは少し異なります。詳しくは[こちら](/docs/tasks/configure-pod-container/configure-runasusername/).
 
-## Managing Workload Identity with Group Managed Service Accounts
+## Group Managed Service AccountsによるワークロードIDの管理
 
-Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
+Kubernetes v1.14以降、Windowsコンテナワークロードは、Group Managed Service Accounts(GMSA)を使用するように構成できます。Group Managed Service Accountsは、自動パスワード管理、簡略化されたサービスプリンシパル名（SPN）管理、および複数のサーバー間で他の管理者に管理を委任する機能を提供する特定の種類のActive Directoryアカウントです。GMSAで構成されたコンテナは、GMSAで構成されたIDを保持しながら、外部Active Directoryドメインリソースにアクセスできます。Windowsコンテナ用のGMSAの構成と使用の詳細は[こちら](/docs/tasks/configure-pod-container/configure-gmsa/)。
 
-## Taints and Tolerations
+## TaintsとTolerations
 
-Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
+今日のユーザーは、LinuxとWindowsのワークロードをそれぞれのOS固有のノードで維持するために、Taintsとノードセレクターのいくつかの組み合わせを使用する必要があります。これはおそらくWindowsユーザーにのみ負担をかけます。推奨されるアプローチの概要を以下に示します。主な目標の1つは、このアプローチによって既存のLinuxワークロードの互換性が損なわれないようにすることです。
 
-### Ensuring OS-specific workloads land on the appropriate container host
+### OS固有のワークロードが適切なコンテナホストに確実に到達するようにする
 
-Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:
+ユーザーは、TaintsとTolerationsを使用して、Windowsコンテナを適切なホストでスケジュールできるようにすることができます。現在、すべてのKubernetesノードには次のデフォルトラベルがあります。:
 
 * kubernetes.io/os = [windows|linux]
 * kubernetes.io/arch = [amd64|arm64|...]
 
-If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
+Podの仕様で`"kubernetes.io/os": windows`のようなnodeSelectorが指定されていない場合、PodをWindowsまたはLinuxの任意のホストでスケジュールすることができます。WindowsコンテナはWindowsでのみ実行でき、LinuxコンテナはLinuxでのみ実行できるため、これは問題になる可能性があります。ベストプラクティスは、nodeSelectorを使用することです。
 
-However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
+ただし、多くの場合、ユーザーには既存の多数のLinuxコンテナのdepolyment、およびコミュニティHelmチャートのような既成構成のエコシステムやOperatorのようなプログラム的にPodを生成するケースがあることを理解しています。このような状況では、nodeSelectorsを追加するための構成変更をためらう可能性があります。代替策は、Taintsを使用することです。kubeletは登録中にTaintsを設定できるため、Windowsだけで実行する時に自動的にTaintを追加するように簡単に変更できます。
 
-For example:  `--register-with-taints='os=windows:NoSchedule'`
+例:`--register-with-taints='os=windows:NoSchedule'`
 
-By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
+すべてのWindowsノードにTaintを追加することにより、それらには何もスケジュールされません（既存のLinuxPodを含む）。Windows PodがWindowsノードでスケジュールされるためには、nodeSelectorがWindowsを選択することと、適切にマッチするTolerationが必要です。
 
 ```yaml
 nodeSelector:
@@ -150,28 +151,27 @@ tolerations:
       effect: "NoSchedule"
 ```
 
-### Handling multiple Windows versions in the same cluster
+### 同じクラスター内の複数Windowsバージョンの管理
 
-The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
-Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
+各Podで使用されるWindows Serverのバージョンは、ノードのバージョンと一致している必要があります。
+同じクラスター内で複数のWindows Serverバージョンを使用したい場合は、追加のノードラベルとnodeSelectorsを設定する必要があります。
 
-Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
+Kubernetes 1.17では、これを簡単するために新しいラベル`node.kubernetes.io/windows-build`が自動的に追加されます。古いバージョンを実行している場合は、このラベルをWindowsノードに手動で追加することをお勧めします。
 
-This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
+このラベルは、互換性のために一致する必要があるWindowsのメジャー、マイナー、およびビルド番号を反映しています。以下は、Windows Serverの各バージョンで現在使用されている値です。
 
-| Product Name                         |   Build Number(s)      |
+| 製品番号                         　　 |   ビルド番号            |
 |--------------------------------------|------------------------|
 | Windows Server 2019                  | 10.0.17763             |
 | Windows Server version 1809          | 10.0.17763             |
 | Windows Server version 1903          | 10.0.18362             |
 
 
-### Simplifying with RuntimeClass
+### RuntimeClassによる簡素化
 
-[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
+[RuntimeClass]は、TaintsとTolerationsを使用するプロセスを簡略化するために使用できます。クラスター管理者は、これらのTaintsとTolerationsをカプセル化するために使用する`RuntimeClass`オブジェクトを作成できます。
 
-
-1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
+1. このファイルを`runtimeClasses.yml`に保存します。これには、Windows OS、アーキテクチャ、およびバージョンに適切な`nodeSelector`が含まれています。
 
 ```yaml
 apiVersion: node.k8s.io/v1beta1
@@ -191,10 +191,10 @@ scheduling:
     value: "windows"
 ```
 
-1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
-1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
+1. クラスター管理者として使用する`kubectl create -f runtimeClasses.yml`を実行します
+1. Podの仕様に応じて`runtimeClassName: windows-2019`を追加します
 
-For example:
+例:
 
 ```yaml
 apiVersion: apps/v1
@@ -241,4 +241,4 @@ spec:
     app: iis-2019
 ```
 
-[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
+[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/

content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md

@@ -0,0 +1,115 @@
+---
+title: Node Affinityを利用してPodをノードに割り当てる
+min-kubernetes-server-version: v1.10
+content_type: task
+weight: 120
+---
+
+<!-- overview -->
+このページでは、Node Affinityを利用して、PodをKubernetesクラスター内の特定のノードに割り当てる方法を説明します。
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+## ノードにラベルを追加する
+
+1. クラスター内のノードを一覧表示して、ラベルを確認します。
+
+    ```shell
+    kubectl get nodes --show-labels
+    ```
+
+    出力は次のようになります。
+
+    ```shell
+    NAME      STATUS    ROLES    AGE     VERSION        LABELS
+    worker0   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker0
+    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
+    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
+    ```
+1. ノードを選択して、ラベルを追加します。
+
+    ```shell
+    kubectl label nodes <your-node-name> disktype=ssd
+    ```
+
+    ここで、`<your-node-name>`は選択したノードの名前で置換します。
+
+1. 選択したノードに`disktype=ssd`ラベルがあることを確認します。
+
+    ```shell
+    kubectl get nodes --show-labels
+    ```
+
+    出力は次のようになります。
+
+    ```
+    NAME      STATUS    ROLES    AGE     VERSION        LABELS
+    worker0   Ready     <none>   1d      v1.13.0        ...,disktype=ssd,kubernetes.io/hostname=worker0
+    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
+    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
+    ```
+
+    この出力を見ると、`worker0`ノードに`disktype=ssd`というラベルが追加されたことがわかります。
+
+## required node affinityを使用してPodをスケジューリングする
+
+以下に示すマニフェストには、`requiredDuringSchedulingIgnoredDuringExecution`に`disktype: ssd`というnode affinityを使用したPodが書かれています。このように書くと、Podは`disktype=ssd`というラベルを持つノードにだけスケジューリングされるようになります。
+
+{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}}
+
+1. マニフェストを適用して、選択したノード上にスケジューリングされるPodを作成します。
+    
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml
+    ```
+
+1. Podが選択したノード上で実行されていることを確認します。
+
+    ```shell
+    kubectl get pods --output=wide
+    ```
+
+    出力は次のようになります。
+    
+    ```
+    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+    ```
+    
+## preferred node affinityを使用してPodをスケジューリングする
+
+以下に示すマニフェストには、`preferredDuringSchedulingIgnoredDuringExecution`に`disktype: ssd`というnode affinityを使用したPodが書かれています。このように書くと、Podは`disktype=ssd`というラベルを持つノードに優先的にスケジューリングされるようになります。
+
+{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}}
+
+1. マニフェストを適用して、選択したノード上にスケジューリングされるPodを作成します。
+    
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml
+    ```
+
+1. Podが選択したノード上で実行されていることを確認します。
+
+    ```shell
+    kubectl get pods --output=wide
+    ```
+
+    出力は次のようになります。
+    
+    ```
+    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+    ```
+
+## {{% heading "whatsnext" %}}
+
+[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)についてさらに学ぶ。
+

content/ja/docs/tasks/configure-pod-container/static-pod.md

@@ -0,0 +1,206 @@
+---
+title: static Podを作成する
+weight: 170
+content_type: task
+---
+
+<!-- overview -->
+
+
+*Static Pod*とは、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}が監視せず、特定のノード上のkubeletデーモンによって直接管理されるPodです。コントロールプレーンに管理されるPod(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}}など)とは異なり、kubeletがそれぞれのstatic Podを監視(および障害時には再起動)します。
+
+Static Podは、常に特定のノード上の1つの{{< glossary_tooltip term_id="kubelet" >}}に紐付けられます。
+
+kubeletは、各static Podに対して、自動的にKubernetes APIサーバー上に{{< glossary_tooltip text="ミラーPod" term_id="mirror-pod" >}}の作成を試みます。つまり、ノード上で実行中のPodはAPIサーバーから検出されますが、APIサーバー自身から制御されることはないということです。
+
+{{< note >}}
+複数ノードからなるKubernetesクラスターを実行していて、Podをすべてのノード上で実行するためにstatic Podを使用している場合、おそらくstatic Podの代わりに{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}を使用するべきでしょう。
+{{< /note >}}
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+このページの説明では、Podを実行するために{{< glossary_tooltip term_id="docker" >}}を使用しており、ノード上のOSがFedoraであることを前提としています。他のディストリビューションやKubernetesのインストール方法によっては、操作が異なる場合があります。
+
+<!-- steps -->
+
+## static Podを作成する {#static-pod-creation}
+
+static Podは、[ファイルシステム上でホストされた設定ファイル](#configuration-files)または[ウェブ上でホストされた設定ファイル](/#pods-created-via-http)を使用して設定できます。
+
+### ファイルシステム上でホストされたstatic Podマニフェスト {#configuration-files}
+
+マニフェストは、JSONまたはYAML形式の標準のPod定義で、特定のディレクトリに置きます。[kubeletの設定ファイル](/docs/tasks/administer-cluster/kubelet-config-file)の中で、`staticPodPath: <ディレクトリの場所>`というフィールドを使用すると、kubeletがこのディレクトリを定期的にスキャンして、YAML/JSONファイルが作成/削除されるたびに、static Podの作成/削除が行われるようになります。指定したディレクトリをスキャンする際、kubeletはドットから始まる名前のファイルを無視することに注意してください。
+
+例として、単純なウェブサーバーをstatic Podとして実行する方法を示します。
+
+1. static Podを実行したいノードを選択します。この例では、`my-node1`です。
+
+    ```shell
+    ssh my-node1
+    ```
+
+2. ディレクトリを選び(ここでは`/etc/kubelet.d`とします)、ここにウェブサーバーのPodの定義を置きます。たとえば、`/etc/kubelet.d/static-web.yaml`に置きます。
+
+    ```shell
+    # このコマンドは、kubeletが実行中のノード上で実行してください
+    mkdir /etc/kubelet.d/
+    cat <<EOF >/etc/kubelet.d/static-web.yaml
+    apiVersion: v1
+    kind: Pod
+    metadata:
+      name: static-web
+      labels:
+        role: myrole
+    spec:
+      containers:
+        - name: web
+          image: nginx
+          ports:
+            - name: web
+              containerPort: 80
+              protocol: TCP
+    EOF
+    ```
+
+3. ノード上のkubeletがこのディレクトリを使用するようにするために、`--pod-manifest-path=/etc/kubelet.d/`引数を付けてkubeletを実行するように設定します。Fedoraの場合、次の行が含まれるように`/etc/kubernetes/kubelet`を編集します。
+
+    ```
+    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
+    ```
+
+    あるいは、[kubeletの設定ファイル](/docs/tasks/administer-cluster/kubelet-config-file)に、`staticPodPath: <ディレクトリの場所>`フィールドを追加することでも設定できます。
+
+4. kubeletを再起動します。Fedoraの場合、次のコマンドを実行します。
+
+    ```shell
+    # このコマンドは、kubeletが実行中のノード上で実行してください
+    systemctl restart kubelet
+    ```
+
+### ウェブ上でホストされたstatic Podマニフェスト {#pods-created-via-http}
+
+kubeletは、`--manifest-url=<URL>`引数で指定されたファイルを定期的にダウンロードし、Podの定義が含まれたJSON/YAMLファイルとして解釈します。kubeletは、[ファイルシステム上でホストされたマニフェスト](#configuration-files)での動作方法と同じように、定期的にマニフェストを再取得します。static Podのリスト中に変更が見つかると、kubeletがその変更を適用します。
+
+このアプローチを採用する場合、次のように設定します。
+
+1. YAMLファイルを作成し、kubeletにファイルのURLを渡せるようにするために、ウェブサーバー上に保存する。
+
+    ```yaml
+    apiVersion: v1
+    kind: Pod
+    metadata:
+      name: static-web
+      labels:
+        role: myrole
+    spec:
+      containers:
+        - name: web
+          image: nginx
+          ports:
+            - name: web
+              containerPort: 80
+              protocol: TCP
+    ```
+
+2. 選択したノード上のkubeletを`--manifest-url=<manifest-url>`を使用して実行することで、このウェブ上のマニフェストを使用するように設定する。Fedoraの場合、`/etc/kubernetes/kubelet`に次の行が含まれるように編集します。
+
+    ```
+    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<マニフェストのURL"
+    ```
+
+3. kubeletを再起動する。Fedoraの場合、次のコマンドを実行します。
+
+    ```shell
+    # このコマンドは、kubeletが実行中のノード上で実行してください
+    systemctl restart kubelet
+    ```
+
+## static Podの動作を観察する {#behavior-of-static-pods}
+
+kubeletが起動すると、定義されたすべてのstatic Podを起動します。ここまででstatic Podを設定してkubeletを再起動したため、すでに新しいstatic Podが実行中になっているはずです。
+
+次のコマンドを(ノード上で)実行することで、(static Podを含む)実行中のコンテナを確認できます。
+
+```shell
+# このコマンドは、kubeletが実行中のノード上で実行してください
+docker ps
+```
+
+出力は次のようになります。
+
+```
+CONTAINER ID IMAGE         COMMAND  CREATED        STATUS         PORTS     NAMES
+f6d05272b57e nginx:latest  "nginx"  8 minutes ago  Up 8 minutes             k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
+```
+
+APIサーバー上では、ミラーPodを確認できます。
+
+```shell
+kubectl get pods
+```
+```
+NAME                       READY     STATUS    RESTARTS   AGE
+static-web-my-node1        1/1       Running   0          2m
+```
+
+{{< note >}}
+kubeletにAPIサーバー上のミラーPodを作成する権限があることを確認してください。もし権限がない場合、APIサーバーによって作成のリクエストが拒否されてしまいます。詳しくは、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)を参照してください。
+{{< /note >}}
+
+
+static Podに付けた{{< glossary_tooltip term_id="label" text="ラベル" >}}はミラーPodに伝搬します。ミラーPodに付けたラベルは、通常のPodと同じように{{< glossary_tooltip term_id="selector" text="セレクター" >}}などから利用できます。
+
+もし`kubectl`を使用してAPIサーバーからミラーPodを削除しようとしても、kubeletはstatic Podを削除*しません*。
+
+```shell
+kubectl delete pod static-web-my-node1
+```
+```
+pod "static-web-my-node1" deleted
+```
+
+Podはまだ実行中であることがわかります。
+
+```shell
+kubectl get pods
+```
+```
+NAME                       READY     STATUS    RESTARTS   AGE
+static-web-my-node1        1/1       Running   0          12s
+```
+
+kubeletが実行中のノードに戻り、Dockerコンテナを手動で停止してみることができます。しばらくすると、kubeletが変化に気づき、Podを自動的に再起動することがわかります。
+
+```shell
+# このコマンドは、kubeletが実行中のノード上で実行してください
+docker stop f6d05272b57e # 実際のコンテナIDと置き換えてください
+sleep 20
+docker ps
+```
+```
+CONTAINER ID        IMAGE         COMMAND                CREATED       ...
+5b920cbaf8b1        nginx:latest  "nginx -g 'daemon of   2 seconds ago ...
+```
+
+## static Podの動的な追加と削除
+
+実行中のkubeletは設定ディレクトリ(この例では`/etc/kubelet.d`)の変更を定期的にスキャンし、このディレクトリ内にファイルが追加/削除されると、Podの追加/削除を行います。
+
+```shell
+# This assumes you are using filesystem-hosted static Pod configuration
+# このコマンドは、kubeletが実行中のノード上で実行してください
+#
+mv /etc/kubelet.d/static-web.yaml /tmp
+sleep 20
+docker ps
+# You see that no nginx container is running
+mv /tmp/static-web.yaml  /etc/kubelet.d/
+sleep 20
+docker ps
+```
+```
+CONTAINER ID        IMAGE         COMMAND                CREATED           ...
+e7a62e3427f1        nginx:latest  "nginx -g 'daemon of   27 seconds ago
+```

content/ja/examples/pods/pod-nginx-preferred-affinity.yaml

@@ -0,0 +1,19 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  affinity:
+    nodeAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 1
+        preference:
+          matchExpressions:
+          - key: disktype
+            operator: In
+            values:
+            - ssd
+  containers:
+  - name: nginx
+    image: nginx
+    imagePullPolicy: IfNotPresent

content/ja/examples/pods/pod-nginx-required-affinity.yaml

@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+        - matchExpressions:
+          - key: disktype
+            operator: In
+            values:
+            - ssd
+  containers:
+  - name: nginx
+    image: nginx
+    imagePullPolicy: IfNotPresent

content/ko/docs/concepts/services-networking/ingress.md

@@ -544,6 +544,6 @@ Events:
 
 ## {{% heading "whatsnext" %}}
 
-* [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
+* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)

content/zh/docs/setup/production-environment/tools/kubeadm/ha-topology.md

@@ -102,7 +102,7 @@ on control plane nodes when using `kubeadm init` and `kubeadm join --control-pla
 <!--
 ![Stacked etcd topology](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
 -->
-！[堆叠的 etcd 拓扑](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
+![堆叠的 etcd 拓扑](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
 
 <!--
 ## External etcd topology
@@ -136,7 +136,7 @@ A minimum of three hosts for control plane nodes and three hosts for etcd nodes
 <!--
 ![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
 -->
-！[外部 etcd 拓扑](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
+![外部 etcd 拓扑](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
 
 
 

i18n/pt.toml

@@ -176,6 +176,9 @@ other = "Objetivos"
 [prerequisites_heading]
 other = "Antes de você começar"
 
+[subscribe_button]
+other = "Se inscrever"
+
 [ui_search_placeholder]
 other = "Procurar"