[zh] Resync concepts pages for services-networking\dual-stack.md

* Resync with english version in 'Dual-stack docs correction kubernetes#26386' * Update in 'administer-cluster\safely-drain-node.md' kubernetes#25996 * Fix rebase in services-networking\dual-stack.md Signed-off-by: ydFu <[email protected]>
ydFu · Feb 19, 2021 · ec12d2b · ec12d2b
2 parents c83e64e + fd8ee1d
commit ec12d2b
Show file tree

Hide file tree

Showing 151 changed files with 5,480 additions and 3,085 deletions.
diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
@@ -92,15 +92,21 @@ aliases:
     - daminisatya
     - mittalyashu
   sig-docs-id-owners: # Admins for Indonesian content
+    - ariscahyadi
+    - danninov
     - girikuncoro
+    - habibrosyad
     - irvifa
+    - phanama
+    - wahyuoi
   sig-docs-id-reviews: # PR reviews for Indonesian content
+    - ariscahyadi
+    - danninov
     - girikuncoro
     - habibrosyad
     - irvifa
-    - wahyuoi
     - phanama
-    - danninov
+    - wahyuoi
   sig-docs-it-owners: # Admins for Italian content
     - fabriziopandini
     - Fale

diff --git a/README-pt.md b/README-pt.md
@@ -2,11 +2,11 @@
 
 [![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
-Bem vindos! Este repositório abriga todos os recursos necessários para criar o [website e documentação do Kubernetes](https://kubernetes.io/). Estamos muito satisfeitos por você querer contribuir!
+Bem-vindos! Este repositório contém todos os recursos necessários para criar o [website e documentação do Kubernetes](https://kubernetes.io/). Estamos muito satisfeitos por você querer contribuir!
 
 # Utilizando este repositório
 
-Você pode executar o website localmente utilizando o Hugo (versão Extended), ou você pode executa-ló em um container runtime. É altamente recomendável usar um container runtime, pois garante a consistência na implantação do website real.
+Você pode executar o website localmente utilizando o Hugo (versão Extended), ou você pode executa-ló em um container runtime. É altamente recomendável utilizar um container runtime, pois garante a consistência na implantação do website real.
 
 ## Pré-requisitos
 
@@ -40,7 +40,7 @@ make container-image
 make container-serve
 ```
 
-Abra seu navegador em http://localhost:1313 para visualizar o website. Conforme você faz alterações nos arquivos fontes, Hugo atualiza o website e força a atualização do navegador.
+Abra seu navegador em http://localhost:1313 para visualizar o website. Conforme você faz alterações nos arquivos fontes, o Hugo atualiza o website e força a atualização do navegador.
 
 ## Executando o website localmente utilizando o Hugo
 
@@ -56,10 +56,57 @@ make serve
 
 Isso iniciará localmente o Hugo na porta 1313. Abra o seu navegador em http://localhost:1313 para visualizar o website. Conforme você faz alterações nos arquivos fontes, o Hugo atualiza o website e força uma atualização no navegador.
 
+## Construindo a página de referência da API
+
+A página de referência da API localizada em `content/en/docs/reference/kubernetes-api` é construída a partir da especificação do Swagger utilizando https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs.
+
+Siga os passos abaixo para atualizar a página de referência para uma nova versão do Kubernetes:
+
+OBS: modifique o "v1.20" no exemplo a seguir pela versão a ser atualizada
+
+1. Obter o submódulo `kubernetes-resources-reference`:
+
+```
+git submodule update --init --recursive --depth 1
+```
+
+2. Criar a nova versão da API no submódulo e adicionar à especificação do Swagger:
+
+```
+mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
+curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-generator/gen-resourcesdocs/api/v1.20/swagger.json
+```
+
+3. Copiar o sumário e os campos de configuração para a nova versão a partir da versão anterior:
+
+```
+mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
+cp api-ref-generator/gen-resourcesdocs/api/v1.19/* api-ref-generator/gen-resourcesdocs/api/v1.20/
+```
+
+4. Ajustar os arquivos `toc.yaml` e `fields.yaml` para refletir as mudanças entre as duas versões.
+
+5. Em seguida, gerar as páginas:
+
+```
+make api-reference
+```
+
+Você pode validar o resultado localmente gerando e disponibilizando o site a partir da imagem do container:
+
+```
+make container-image
+make container-serve
+```
+
+Abra o seu navegador em http://localhost:1313/docs/reference/kubernetes-api/ para visualizar a página de referência da API.
+
+6. Quando todas as mudanças forem refletidas nos arquivos de configuração `toc.yaml` e `fields.yaml`, crie um pull request com a nova página de referência de API.
+
 ## Troubleshooting
 ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
 
-Por motivos técnicos, o Hugo é disponibilizado em dois conjuntos de binários. O website atual funciona apenas na versão  **Hugo Extended**. Na [página de releases](https://github.com/gohugoio/hugo/releases) procure por arquivos com `extended` no nome. Para confirmar, execute `hugo version` e procure pela palavra `extended`.
+Por motivos técnicos, o Hugo é disponibilizado em dois conjuntos de binários. O website atual funciona apenas na versão **Hugo Extended**. Na [página de releases](https://github.com/gohugoio/hugo/releases) procure por arquivos com `extended` no nome. Para confirmar, execute `hugo version` e procure pela palavra `extended`.
 
 ### Troubleshooting macOS for too many open files
 
@@ -110,9 +157,9 @@ Você também pode entrar em contato com os mantenedores deste projeto em:
 
 Você pode clicar no botão **Fork** na área superior direita da tela para criar uma cópia desse repositório na sua conta do GitHub. Esta cópia é chamada de *fork*. Faça as alterações desejadas no seu fork e, quando estiver pronto para enviar as alterações para nós, vá até o fork e crie um novo **pull request** para nos informar sobre isso.
 
-Depois que seu **pull request** for criado, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para atender ao feedback que foi fornecido a você pelo revisor do Kubernetes.** 
+Depois que seu **pull request** for criado, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para atender ao feedback que foi fornecido a você pelo revisor do Kubernetes.**
 
-Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um outro revisor do Kubernetes diferente daquele originalmente designado para lhe fornecer o feedback. 
+Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um outro revisor do Kubernetes diferente daquele originalmente designado para lhe fornecer o feedback.
 
 Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor técnico do Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedbacks em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.
 
@@ -134,4 +181,4 @@ A participação na comunidade Kubernetes é regida pelo [Código de Conduta da
 
 # Obrigado!
 
-O Kubernetes conta com a participação da comunidade e nós realmente agradecemos suas contribuições para o nosso website e nossa documentação!
+O Kubernetes prospera com a participação da comunidade e nós realmente agradecemos suas contribuições para o nosso website e nossa documentação!
diff --git a/README.md b/README.md
@@ -100,6 +100,8 @@ make container-image
 make container-serve
 ```
 
+In a web browser, go to http://localhost:1313/docs/reference/kubernetes-api/ to view the API reference.
+
 6. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages.
 
 ## Troubleshooting

diff --git a/content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md b/content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md
@@ -20,21 +20,14 @@ For example, if we want to require scheduling on a node that is in the us-centra
 
 
 ```
-affinity:
-
-  nodeAffinity:
-
-    requiredDuringSchedulingIgnoredDuringExecution:
-
-      nodeSelectorTerms:
-
-        - matchExpressions:
-
-          - key: "failure-domain.beta.kubernetes.io/zone"
-
-            operator: In
-
-            values: ["us-central1-a"]
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+          - matchExpressions:
+            - key: "failure-domain.beta.kubernetes.io/zone"
+              operator: In
+              values: ["us-central1-a"]
  ```
 
 
@@ -44,21 +37,14 @@ Preferred rules mean that if nodes match the rules, they will be chosen first, a
 
 
 ```
-affinity:
-
-  nodeAffinity:
-
-    preferredDuringSchedulingIgnoredDuringExecution:
-
-      nodeSelectorTerms:
-
-        - matchExpressions:
-
-          - key: "failure-domain.beta.kubernetes.io/zone"
-
-            operator: In
-
-            values: ["us-central1-a"]
+  affinity:
+    nodeAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+          - matchExpressions:
+            - key: "failure-domain.beta.kubernetes.io/zone"
+              operator: In
+              values: ["us-central1-a"]
  ```
 
 
@@ -67,21 +53,14 @@ Node anti-affinity can be achieved by using negative operators. So for instance
 
 
 ```
-affinity:
-
-  nodeAffinity:
-
-    requiredDuringSchedulingIgnoredDuringExecution:
-
-      nodeSelectorTerms:
-
-        - matchExpressions:
-
-          - key: "failure-domain.beta.kubernetes.io/zone"
-
-            operator: NotIn
-
-            values: ["us-central1-a"]
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+          - matchExpressions:
+            - key: "failure-domain.beta.kubernetes.io/zone"
+              operator: NotIn
+              values: ["us-central1-a"]
  ```
 
 
@@ -99,23 +78,19 @@ The kubectl command allows you to set taints on nodes, for example:
 
 ```
 kubectl taint nodes node1 key=value:NoSchedule
- ```
+```
 
 
 creates a taint that marks the node as unschedulable by any pods that do not have a toleration for taint with key key, value value, and effect NoSchedule. (The other taint effects are PreferNoSchedule, which is the preferred version of NoSchedule, and NoExecute, which means any pods that are running on the node when the taint is applied will be evicted unless they tolerate the taint.) The toleration you would add to a PodSpec to have the corresponding pod tolerate this taint would look like this  
 
 
 
 ```
-tolerations:
-
-- key: "key"
-
-  operator: "Equal"
-
-  value: "value"
-
-  effect: "NoSchedule"
+  tolerations:
+  - key: "key"
+    operator: "Equal"
+    value: "value"
+    effect: "NoSchedule"
  ```
 
 
@@ -138,21 +113,13 @@ Let’s look at an example. Say you have front-ends in service S1, and they comm
 
 ```
 affinity:
-
     podAffinity:
-
       requiredDuringSchedulingIgnoredDuringExecution:
-
       - labelSelector:
-
           matchExpressions:
-
           - key: service
-
             operator: In
-
             values: [“S1”]
-
         topologyKey: failure-domain.beta.kubernetes.io/zone
  ```
 
@@ -172,25 +139,15 @@ Here we have a Pod where we specify the schedulerName field:
 
 ```
 apiVersion: v1
-
 kind: Pod
-
 metadata:
-
   name: nginx
-
   labels:
-
     app: nginx
-
 spec:
-
   schedulerName: my-scheduler
-
   containers:
-
   - name: nginx
-
     image: nginx:1.10
  ```
 

diff --git a/content/en/blog/_posts/2019-03-15-Kubernetes-setup-using-Ansible-and-Vagrant.md b/content/en/blog/_posts/2019-03-15-Kubernetes-setup-using-Ansible-and-Vagrant.md
@@ -66,6 +66,7 @@ Vagrant.configure("2") do |config|
             end
         end
     end
+end
 ```
 
 ### Step 2: Create an Ansible playbook for Kubernetes master.

diff --git a/content/en/community/_index.html b/content/en/community/_index.html
@@ -19,6 +19,7 @@
 
 <div class="community__navbar">
 
+<a href="#values">Community Values</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#conduct">Code of conduct </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#videos">Videos</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#discuss">Discussions</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
@@ -41,10 +42,28 @@
     <img src="/images/community/kubernetes-community-final-05.jpg" alt="Kubernetes Conference Gallery" style="width:100%;margin-right:0% important" class="desktop">
   </div>
   <img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Kubernetes Conference Gallery" style="width:100%;margin-bottom:3%" class="mobile">
-
-<a name="conduct"></a>
+<a name="values"></a>
 </div>
 
+<div><a name="values"></a></div>
+<div class="conduct">
+<div class="conducttext">
+<br class="mobile"><br class="mobile">
+<br class="tablet"><br class="tablet">
+<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Community Values</h1>
+The Kubernetes Community values are the keystone to the ongoing success of the project.<br>
+These principles guide every aspect of the Kubernetes project.
+<br>
+<a href="/community/values/">
+<br class="mobile"><br class="mobile">
+<span class="fullbutton">
+  READ MORE
+  </span>
+  </a>
+  </div><a name="conduct"></a>
+  </div>
+  </div>
+
 
 
 <div class="conduct">

diff --git a/content/en/community/static/community-values.md b/content/en/community/static/community-values.md
@@ -0,0 +1,28 @@
+<!-- Do not edit this file directly. Get the latest from
+     https://git.k8s.io/community/values.md -->
+
+# Kubernetes Community Values
+
+Kubernetes Community culture is frequently cited as a substantial contributor to the meteoric rise of this Open Source project.  Below are the distilled values which have evolved over the last many years in our community pushing our project and peers toward constant improvement.
+
+## Distribution is better than centralization
+
+The scale of the Kubernetes project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation.  Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstone of our world-wide community.
+
+## Community over product or company
+
+We are here as a community first, our allegiance is to the intentional stewardship of the Kubernetes project for the benefit of all its members and users everywhere.  We support working together publicly for the common goal of a vibrant interoperable ecosystem providing an excellent experience for our users. Individuals gain status through work, companies gain status through their commitments to support this community and fund the resources necessary for the project  to operate.
+
+## Automation over process
+
+Large projects have a lot of less exciting, yet, hard work.  We value time spent automating repetitive work more highly than toil. Where that work cannot be automated, it is our culture to recognize and reward all types of contributions. However, heroism is not sustainable.
+
+## Inclusive is better than exclusive
+
+Broadly successful and useful technology requires different perspectives and skill sets which can only be heard in a welcoming and respectful environment.  Community membership is a privilege, not a right. Community Leadership is earned through effort, scope, quality, quantity, and duration of contributions. Our community shows respect for the time and effort put into a discussion regardless of where a contributor is on their growth path.
+
+## Evolution is better than stagnation
+
+Openness to new ideas and studied technological evolution make Kubernetes a stronger project.  Continual improvement, servant leadership, mentorship and respect are the foundations of the Kubernetes project culture. It is the duty for leaders in the Kubernetes community to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up.
+
+**"Culture eats strategy for breakfast."   --Peter Drucker**
diff --git a/content/en/community/values.md b/content/en/community/values.md
@@ -0,0 +1,13 @@
+---
+title: Community
+layout: basic
+cid: community
+css: /css/community.css
+---
+
+<div class="community_main">
+
+<div class="cncf_coc_container">
+{{< include "/static/community-values.md" >}}
+</div>
+</div>
-Original file line number
+Diff line change
@@ Expand Up / @@ -66,6 +66,7 @@ Vagrant.configure("2") do |config| @@
                 end
             end
         end
+    end
     ```
     ### Step 2: Create an Ansible playbook for Kubernetes master.
@@ Expand Down @@