Update static/_redirects, release-1.14 (#19893 )

* updates 1.14 static _redirects, netlify bug * redirects update, remove zh/_redirects
Updated config.toml as part of release-1.18 (#19843 )
2020-03-27 19:25:53 -07:00 · 2020-03-26 20:32:23 -07:00 · 2020-03-04 16:46:38 -08:00 · 2019-12-09 16:15:30 -08:00 · 2019-10-29 20:06:53 -07:00 · 2019-10-29 19:52:53 -07:00
930 changed files with 110257 additions and 2602 deletions
@@ -1,5 +1,5 @@
 DOCKER       = docker
-HUGO_VERSION = 0.53
+HUGO_VERSION = 0.58.3
 DOCKER_IMAGE = kubernetes-hugo
 DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
 NODE_BIN     = node_modules/.bin
@@ -26,7 +26,7 @@ check-headers-file:

 production-build: check-hugo-versions build check-headers-file ## Build the production site and ensure that noindex headers aren't added

-non-production-build: test-examples check-hugo-versions ## Build the non-production site, which adds noindex headers to prevent indexing
+non-production-build: check-hugo-versions ## Build the non-production site, which adds noindex headers to prevent indexing
 	hugo --enableGitInfo

 serve: ## Boot the development server.
@@ -24,7 +24,9 @@ pygmentsStyle = "emacs"
 enableGitInfo = true

 # Norwegian ("no") is sometimes but not currently used for testing.
-disableLanguages = ["no"]
+# Hindi is disabled because it's currently in development.
+# Italian is disabled until it meets minimum standards for quality.
+disableLanguages = ["hi", "it", "no"]

 [blackfriday]
 hrefTargetBlank = true
@@ -64,25 +66,18 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.14"
+latest = "v1.18"

-fullversion = "v1.14.0"
+fullversion = "v1.14.10"
 version = "v1.14"
-githubbranch = "master"
-docsbranch = "master"
-deprecated = false
+githubbranch = "v1.14.10"
+docsbranch = "release-1.14"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
 githubWebsiteRepo = "github.com/kubernetes/website"
 githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"

-[[params.versions]]
-fullversion = "v1.14.0"
-version = "v1.14"
-githubbranch = "v1.14.0"
-docsbranch = "release-1.14"
-url = "https://kubernetes.io"
-
 [params.pushAssets]
 css = [
  "callouts",
@@ -95,32 +90,39 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.13.4"
-version = "v1.13"
-githubbranch = "v1.13.4"
-docsbranch = "release-1.13"
-url = "https://v1-13.docs.kubernetes.io"
+fullversion = "v1.18.0"
+version = "v1.18"
+githubbranch = "v1.18.0"
+docsbranch = "release-1.18"
+url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.12.6"
-version = "v1.12"
-githubbranch = "v1.12.6"
-docsbranch = "release-1.12"
-url = "https://v1-12.docs.kubernetes.io"
+fullversion = "v1.17.4"
+version = "v1.17"
+githubbranch = "v1.17.4"
+docsbranch = "release-1.17"
+url = "https://v1-17.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.11.8"
-version = "v1.11"
-githubbranch = "v1.11.8"
-docsbranch = "release-1.11"
-url = "https://v1-11.docs.kubernetes.io"
+fullversion = "v1.16.8"
+version = "v1.16"
+githubbranch = "v1.16.8"
+docsbranch = "release-1.16"
+url = "https://v1-16.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.10.13"
-version = "v1.10"
-githubbranch = "v1.10.13"
-docsbranch = "release-1.10"
-url = "https://v1-10.docs.kubernetes.io"
+fullversion = "v1.15.11"
+version = "v1.15"
+githubbranch = "v1.15.11"
+docsbranch = "release-1.15"
+url = "https://v1-15.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.14.10"
+version = "v1.14"
+githubbranch = "v1.14.10"
+docsbranch = "release-1.14"
+url = "https://v1-14.docs.kubernetes.io"

 # Language definitions.

@@ -142,6 +144,7 @@ contentDir = "content/zh"
 [languages.zh.params]
 time_format_blog = "2006.01.02"
 language_alternatives = ["en"]
+deprecated = false

 [languages.ko]
 title = "Kubernetes"
@@ -254,4 +257,4 @@ title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
 languageName ="Hindi"
 weight = 11
-contentDir = "content/hi"
+contentDir = "content/hi"
@@ -12,9 +12,9 @@ With the help of our growing community of 1,400 plus contributors, we issued mor

 While many improvements have been contributed, we highlight key features in this series of in-depth&nbsp;posts listed below. [Follow along](https://twitter.com/kubernetesio) and see what’s new and improved with storage, security and more.  

-**Day 1:** [5 Days of Kubernetes 1.8](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)  
+**Day 1:** [5 Days of Kubernetes v1.8](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)  
 **Day 2:** [kubeadm v1.8 Introduces Easy Upgrades for Kubernetes Clusters](https://kubernetes.io/blog/2017/10/kubeadm-v18-released)  
-**Day 3:** [Kubernetes v.1.8 Retrospective: It Takes a Village to Raise a Kubernetes](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
+**Day 3:** [Kubernetes v1.8 Retrospective: It Takes a Village to Raise a Kubernetes](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
 **Day 4:** [Using RBAC, Generally Available in Kubernetes v1.8](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18)  
 **Day 5:** [Enforcing Network Policies in Kubernetes](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes)  

@@ -19,10 +19,10 @@ For information how to create a cluster with kubeadm once you have performed thi

 * One or more machines running one of:
  - Ubuntu 16.04+
-  - Debian 9
+  - Debian 9+
  - CentOS 7
-  - RHEL 7
-  - Fedora 25/26 (best-effort)
+  - Red Hat Enterprise Linux (RHEL) 7
+  - Fedora 25+
  - HypriotOS v1.0.1+
  - Container Linux (tested with 1800.6.0)
 * 2 GB or more of RAM per machine (any less will leave little room for your apps)
@@ -51,6 +51,34 @@ may [fail](https://github.com/kubernetes/kubeadm/issues/31).
 If you have more than one network adapter, and your Kubernetes components are not reachable on the default
 route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.

+## Ensure iptables tooling does not use the nftables backend
+
+In Linux, nftables is available as a modern replacement for the kernel's iptables subsystem. The
+`iptables` tooling can act as a compatibility layer, behaving like iptables but actually configuring
+nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated
+firewall rules and breaks `kube-proxy`.
+
+If your system's `iptables` tooling uses the nftables backend, you will need to switch the `iptables`
+tooling to 'legacy' mode to avoid these problems. This is the case on at least Debian 10 (Buster),
+Ubuntu 19.04, Fedora 29 and newer releases of these distributions by default. RHEL 8 does not support
+switching to legacy mode, and is therefore incompatible with current kubeadm packages.
+
+{{< tabs name="iptables_legacy" >}}
+{{% tab name="Debian or Ubuntu" %}}
+```bash
+update-alternatives --set iptables /usr/sbin/iptables-legacy
+update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
+update-alternatives --set arptables /usr/sbin/arptables-legacy
+update-alternatives --set ebtables /usr/sbin/ebtables-legacy
+```
+{{% /tab %}}
+{{% tab name="Fedora" %}}
+```bash
+update-alternatives --set iptables /usr/sbin/iptables-legacy
+```
+{{% /tab %}}
+{{< /tabs >}}
+
 ## Check required ports

 ### Master node(s)
@@ -178,7 +178,18 @@ k8s-apparmor-example-deny-write (enforce)
 First, we need to load the profile we want to use onto our nodes. The profile we'll use simply
 denies all file writes:

-{{< code language="text" file="deny-write.profile" >}}
+```shell
+#include <tunables/global>
+
+profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
+  #include <abstractions/base>
+
+  file,
+
+  # Deny all file writes.
+  deny /** w,
+}
+```

 Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our
 nodes. For this example we'll just use SSH to install the profiles, but other approaches are
@@ -1,86 +0,0 @@
---
-reviewers:
- chenopis
-layout: docsportal
-css: /css/style_user_journeys.css
-js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
-title: Advanced Topics
-track: "USERS > CLUSTER OPERATOR > ADVANCED"
-content_template: templates/user-journey-content
-toc_hide: true
---
-
-{{% capture overview %}}
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-{{% /capture %}}
-
-<!--
-Advanced
-Federated clusters
-Multi-cluster access
-Custom controllers, custom resource definitions
-Network-level service management (ISTIO)
-->
-
-{{% capture body %}}
-## Setup federated clusters
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-## Deploy an application with advanced features
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-## Explore advanced topics
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-## Additional resources
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
-
-Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
-
-Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
-
-{{% /capture %}}
-
-
@@ -17,14 +17,14 @@ weight: 10

 노드의 상태는 다음의 정보를 포함한다.

-* [주소](#주소)
-* [컨디션](#컨디션)
-* [용량](#용량)
-* [정보](#정보)
+* [주소](#addresses)
+* [컨디션](#condition)
+* [용량과 할당가능](#capacity)
+* [정보](#info)

 각 섹션은 아래 상세하게 기술되었다.

-### 주소
+### 주소 {#addresses}

 이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다.

@@ -33,9 +33,9 @@ weight: 10
 * InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.


-### 컨디션
+### 컨디션 {#condition}

-`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다.
+`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다.

 | Node Condition | Description |
 |----------------|-------------|
@@ -52,7 +52,11 @@ weight: 10
 "conditions": [
  {
    "type": "Ready",
-    "status": "True"
+    "status": "True",
+    "reason": "KubeletReady",
+    "message": "kubelet is posting ready status",
+    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
+    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
 ]
 ```
@@ -70,11 +74,19 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
 이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
 {{< /caution >}}

-### 용량
+### 용량과 할당가능 {#capacity}

 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.

-### 정보
+용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다.
+할당가능 블록은 일반 파드에서 사용할 수 있는
+노드의 리소스 양을 나타낸다.
+
+노드에서
+[컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을
+배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자.
+
+### 정보 {#info}

 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다.

@@ -170,7 +170,7 @@ zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availabi

 마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면, 
 더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은 
-클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/cluster-large/)에서 확인 가능하다.
+클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/best-practices/cluster-large/)에서 확인 가능하다.

 {{% /capture %}}

@@ -60,6 +60,8 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
  - AWS EC2 컨테이너 레지스트리(ECR) 사용
    - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함
    - ECR 로그인 자격 증명은 자동으로 갱신됨
+  - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용
+    - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함
  - Azure 컨테이너 레지스트리(ACR) 사용
  - IBM 클라우드 컨테이너 레지스트리 사용
  - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
@@ -275,19 +277,7 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.

 ```shell
-cat <<EOF > ./kustomization.yaml
-secretGenerator:
- name: myregistrykey
-  type: docker-registry
-  literals:
-  - docker-server=DOCKER_REGISTRY_SERVER
-  - docker-username=DOCKER_USER
-  - docker-password=DOCKER_PASSWORD
-  - docker-email=DOCKER_EMAIL
-EOF
-
-kubectl apply -k .
-secret/myregistrykey-66h7d4d986 created
+kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
 ```

 만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, 
@@ -8,7 +8,13 @@ weight: 20

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-이 페이지는 런타임 클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
+이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
+
+{{< warning >}}
+런타임클래스는 v1.14 베타 업그레이드에서 *중대한* 변화를 포함한다.
+런타임클래스를 v1.14 이전부터 사용하고 있었다면,
+[런타임 클래스를 알파에서 베타로 업그레이드하기](#upgrading-runtimeclass-from-alpha-to-beta)를 확인한다.
+{{< /warning >}}

 {{% /capture %}}

@@ -17,82 +23,72 @@ weight: 20

 ## 런타임 클래스

-런타임 클래스는 파드의 컨테이너를 실행하는데 사용할 컨테이너 런타임 설정을 선택하기 위한 
-알파 특징이다.
+런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다.
+이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다.
+
+## 동기
+
+서로 다른 파드간에 런타임 클래스를 설정하여
+성능대 보안의 균형을 유지할 수 있다.
+예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
+하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
+그러면 몇가지 추가적인 오버헤드는 있지만
+대체 런타임을 추가 분리하는 유익이 있다.
+
+또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
+여러 파드를 실행할 수 있다.

 ### 셋업

-초기 알파 특징이므로, 런타임 클래스 특징을 사용하기 위해서는 몇 가지 추가 셋업 
-단계가 필요하다.
-
-1. 런타임 클래스 특징 게이트 활성화(apiservers 및 kubelets에 대해서, 버전 1.12+ 필요)
-2. 런타임 클래스 CRD 설치
-3. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
-4. 상응하는 런타임 클래스 리소스 생성
-
-#### 1. 런타임 클래스 특징 게이트 활성화
-
+RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
-참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 
-한다.
+참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.

-#### 2. 런타임 클래스 CRD 설치
+1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
+2. 상응하는 런타임 클래스 리소스 생성

-런타임 클래스 [CustomResourceDefinition][] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수 
-있다. [kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml][runtimeclass_crd]
+#### 1. CRI 구현을 노드에 설정

-`kubectl apply -f runtimeclass_crd.yaml`을 통해서 해당 CRD를 설치한다.
-
-[CustomResourceDefinition]: /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
-[runtimeclass_crd]: https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml
-
-
-#### 3. CRI 구현을 노드에 설정
-
-런타임 클래스와 함께 선택할 설정은 CRI 구현에 의존적이다. 사용자의 CRI 
-구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다. 이것은 알파 
-특징이므로, 아직 모든 CRI가 다중 런타임 클래스를 지원하지는 않는다.
+런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
+사용자의 CRI 구현에 따른 설정 방법은
+연관된 문서를 통해서 확인한다([아래](#cri-configuration)).

 {{< note >}}
 런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
-(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한 
-설정)이라도 
-스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다([파드를 노드에 
-할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
+(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
+설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다
+([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
 {{< /note >}}

-해당 설정은 상응하는 `RuntimeHandler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
+해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다.

-#### 4. 상응하는 런타임 클래스 리소스 생성
+#### 2. 상응하는 런타임 클래스 리소스 생성

-3단계에서 셋업 한 설정은 연관된 `RuntimeHandler` 이름을 가져야 하며, 이를 통해서 
-설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 
-상응하는 런타임 클래스 오브젝트를 생성한다.
+1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
+각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다.

 현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러
-(`spec.runtimeHandler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
+(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.

 ```yaml
-apiVersion: node.k8s.io/v1alpha1  # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
+apiVersion: node.k8s.io/v1beta1  # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
 kind: RuntimeClass
 metadata:
  name: myclass  # 런타임 클래스는 해당 이름을 통해서 참조됨
  # 런타임 클래스는 네임스페이스가 없는 리소스임
-spec:
-  runtimeHandler: myconfiguration  # 상응하는 CRI 설정의 이름임
+handler: myconfiguration  # 상응하는 CRI 설정의 이름임
 ```

-
 {{< note >}}
 런타임 클래스 쓰기 작업(create/update/patch/delete)은
-클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 
-개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
+클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
+더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
 {{< /note >}}

 ### 사용

-클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 
+클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다.

 ```yaml
@@ -105,12 +101,75 @@ spec:
  # ...
 ```

-이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 
-런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 
-`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러 
-메시지를 위해서는 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 
+이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
+만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
+`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다.
+에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
 확인한다.

-만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용될 것이다. 기본 런타임 핸들러는 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
+만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며,
+런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
+
+### CRI 구성 {#cri-configuration}
+
+CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다.
+
+#### dockershim
+
+쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
+
+#### [containerd](https://containerd.io/)
+
+런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다.
+유효한 핸들러는 runtimes 단락 아래에서 설정한다.
+
+```
+[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+```
+
+더 자세한 containerd의 구성 문서를 살펴본다.
+https://github.com/containerd/cri/blob/master/docs/config.md
+
+#### [cri-o](https://cri-o.io/)
+
+런타임 핸들러는 cri-o의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다.
+[crio.runtime 테이블](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에
+유효한 핸들러를 설정한다.
+
+```
+[crio.runtime.runtimes.${HANDLER_NAME}]
+  runtime_path = "${PATH_TO_BINARY}"
+```
+
+더 자세한 cri-o의 구성 문서를 살펴본다.
+https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
+
+
+### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}
+
+런타임 클래스 베타 기능은 다음의 변화를 포함한다.
+
+- `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서
+  내장 API로 이전되었다.
+- 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다.
+  (즉, 더 이상 RuntimeClassSpec는 없다).
+- `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다.
+- `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가
+  필요하다는 의미이다.
+- `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로,
+  이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는
+  다음의 정규 표현식을 따른다. `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`.
+
+**작업 필요** 다음 작업은 알파 버전의 런타임 기능을
+베타 버전으로 업그레이드하기 위해 진행되어야 한다.
+
+- 런타임 클래스 리소스는 v1.14로 업그레이드 *후에* 반드시 재생성되어야 하고,
+  `runtimeclasses.node.k8s.io` CRD는 다음과 같이 수동으로 지워야 한다.
+  ```
+  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
+  ```
+- 지정되지 않았거나 비어 있는 `runtimeHandler` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는
+  더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
+  (위를 참조).

 {{% /capture %}}
@@ -16,7 +16,7 @@ card:
 ## 마스터 컴포넌트

 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
-(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
+(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.

 마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
@@ -72,13 +72,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드

 ### kube-proxy

-[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서
- 쿠버네티스 서비스 추상화가 가능하도록 해준다.
+{{< glossary_definition term_id="kube-proxy" length="all" >}}

 ### 컨테이너 런타임

-컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
-쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 런타임이다.
+{{< glossary_definition term_id="container-runtime" length="all" >}}

 ## 애드온

@@ -15,8 +15,7 @@ API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/referen

 API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다.

-쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. 
-[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
+쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.

 쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다. 

@@ -24,7 +23,6 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -36,9 +34,9 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc

 ## OpenAPI 및 Swagger 정의

-완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. 
+완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.

-쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. 
+쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
 요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다.

 헤더   | 가능한 값
@@ -46,7 +44,8 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
 Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음)
 Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨)

-1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. 이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다.
+1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다.
+이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거됬다.

 **OpenAPI 규격을 조회하는 예제**

@@ -58,21 +57,25 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github

 쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다.

-1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/) 
-쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다. 
+1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
+쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
 이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다.

 ## API 버전 규칙

-필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나 
-`/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다.
+필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
+쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
+각각 다른 API 경로에서 복수의 API 버전을 지원한다.

 리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.

-API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
+API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자.
+[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
+API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.


-API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
+API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다.
+각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.

 - 알파(Alpha) 수준:
  - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
@@ -87,7 +90,8 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르
  - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
    다음 버전으로 이관할 수 있는 가이드를 제공할 것이다. 
    이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
-  - 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
+  - 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
+    복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
  - **베타 기능을 사용하고 피드백을 주기를 바란다! 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.**
 - 안정화(stable) 수준:
  - 버전 이름이 `vX`이고 `X` 는 정수다.
@@ -95,8 +99,7 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르

 ## API 그룹

-쿠버네티스 API를 보다 쉽게 확장하기 위해서, 
-[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
+쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
 API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.

 현재 다양한 API 그룹이 사용되고 있다.
@@ -111,8 +114,9 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명

 1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인
   CRUD 요구를 갖는 사용자에게 적합하다.
-1. 쿠버네티스 API 의미론의 전체 셋을 가지고 사용자만의 apiserver를 만들고자하는 사용자는 [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록
-  만들 수 있다.
+1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는
+   [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록
+   만들 수 있다.


 ## API 그룹 활성화 시키기
@@ -122,7 +126,7 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
 `--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을
 설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.

-중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서 
+중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서
 `--runtime-config` 변경을 반영시켜야 한다.

 ## 그룹 내 리소스 활성화 시키기
@@ -69,8 +69,29 @@ _어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두

 `kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.

+다음은 `imageregistry: https://hub.docker.com/` 어노테이션이 있는 파드의 구성 파일 예시이다.
+
+```yaml
+
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotations-demo
+  annotations:
+    imageregistry: "https://hub.docker.com/"
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.7.9
+    ports:
+    - containerPort: 80
+
+```
+
 {{% /capture %}}

 {{% capture whatsnext %}}
 [레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
 {{% /capture %}}
+
+
@@ -15,10 +15,9 @@ card:
 {{% capture body %}}
 ## 파드에 대해 이해하기

-*파드* 는 쿠버네티스의 기본 구성 요소이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다. 
+*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다.

-파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다.
-파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
+파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.

 [도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.

@@ -27,25 +26,19 @@ card:

 * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
 * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
-
-
 [쿠버네티스 블로그](http://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다.

  * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
  * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)

-
 각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.

-
-
 ## 어떻게 파드가 다중 컨테이너를 관리하는가

 파드는 결합도가 있는 단위의 서비스를 형성하는 다중 협력 프로세스(컨테이너)를 지원하도록 디자인 되었다. 파드 내부의 컨테이너는 자동으로 동일한 물리적 또는 가상의 머신의 클러스터에 함께 배치되고 스케쥴된다. 컨테이너는 리소스와 의존성 공유, 다른 컨테이너와의 통신 그리고 언제,어떻게 조절하는지를 공유할 수 있다.

 단일 파드 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다.

-
 {{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}

 몇몇의 파드는 {{< glossary_tooltip text="init containers" term_id="init-container" >}} 뿐만 아니라 {{< glossary_tooltip text="app containers" term_id="app-container" >}} 도 가진다. 초기 컨테이너는 앱 컨테이너 시작이 완료되기 전에 동작한다.
@@ -62,18 +55,17 @@ card:

 ## 파드 작업

-직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다. 
+직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다.

 {{< note >}}
 파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.
 {{< /note >}}

-파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다.
-쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
+파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.

 ### 파드와 컨트롤러

-컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다.  
+컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다.

 한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시.

@@ -84,7 +76,11 @@ card:
 일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다.

 ## 파드 템플릿
-파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. 컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
+
+파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
+[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/),
+[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
+컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
 아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다.

 ```yaml
@@ -98,7 +94,7 @@ spec:
  containers:
  - name: myapp-container
    image: busybox
-    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
+    command: ['sh', '-c', 'echo 안녕하세요 쿠버네티스! && sleep 3600']
 ```

 모든 레플리카의 현재 원하는 상태를 지정하는 대신, 파드 템플릿은 쿠키 틀과 같다. 쿠키가 한 번 잘리면, 그 쿠키는 쿠키 틀과 더이상 관련이 없다. 양자 얽힘이 없는 것이다. 그 이후 템플릿을 변경하거나 새로운 템플릿으로 바꿔도 이미 만들어진 파드에는 직접적인 영향이 없다. 마찬가지로, 레플리케이션 컨트롤러에 의해 만들어진 파드는 아마 그 이후 직접 업데이트될 수 있다. 이것은 모든 컨테이너가 속해있는 파드에서 현재 원하는 상태를 명시하는 것과 의도적으로 대비가 된다. 이러한 접근은 시스템의 의미를 철저히 단순화하고 유연성을 증가시킨다.
@@ -106,7 +102,8 @@ spec:
 {{% /capture %}}

 {{% capture whatsnext %}}
-* [파드](/docs/concepts/workloads/pods/pod/)의 다른 동작들을 더 배워보자.
+* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
+* 파드의 동작에 대해 더 알아보자.
  * [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
  * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
 {{% /capture %}}
@@ -5,8 +5,8 @@ weight: 50
 ---

 {{% capture overview %}}
-이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에 
-특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는 
+이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에
+특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
 시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
 {{% /capture %}}

@@ -14,12 +14,12 @@ weight: 50
 {{% capture body %}}
 ## 파드 프리셋 이해하기

-`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을 
-주입하기 위한 API 리소스이다. 
-주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는 
+`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
+주입하기 위한 API 리소스이다.
+주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다.

-파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로 
+파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
 템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.

@@ -28,52 +28,54 @@ weight: 50
 ## 어떻게 동작하는가

 쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면,
-파드 프리셋을 파드 생성 요청에 적용한다. 
+파드 프리셋을 파드 생성 요청에 적용한다.
 파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다.

 1. 사용 가능한 모든 `PodPresets`을 검색한다.
-1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는 
-   것이 있는지 확인한다. 
-1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에 
+1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
+   것이 있는지 확인한다.
+1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
   병합되도록 시도한다.
-1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로 
-   부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다. 
-1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서 
+1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
+   부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
+1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
   수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
    `podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.

-각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의 
-파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을 
-때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의 
-변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을 
+각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의
+파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을
+때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의
+변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
 수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.

 {{< note >}}
-파드 프리셋은 적절한 경우 파드 스펙의 `.spec.containers` 필드를 
-수정할 수도 있다. 파드 프리셋으로부터의 리소스 정의 *없음* 은 `initContainers` 
-필드에 적용될 것이다.
+파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다.
+- `.spec.containers` 필드
+- `initContainers` 필드(쿠버네티스 버전 1.14.0 이후에서 필요)
 {{< /note >}}

 ### 특정 파드의 파드 프리셋 비활성화하기

-어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가 
-있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에 
+어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
+있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에
 추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.

 ## 파드 프리셋 활성화하기

 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.

-1.  API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. 
-    예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에  `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
-    minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` 
+1.  API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
+    예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
+    minikube에서는 클러스터가 시작할 때
+    `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
    플래그를 추가한다.
-1.  어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는 
+1.  어드미션 컨트롤러 `PodPreset`을 활성화하였다.
+    이것을 이루는 방법 중 하나는
    API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
-    minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`
+    minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`
    플래그를 추가한다.
-1.  사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여 
-    파드 프리셋을 정의하였다. 
+1.  사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여
+    파드 프리셋을 정의하였다.

 {{% /capture %}}

@@ -2,11 +2,11 @@
 title: 컨테이너 환경 변수(Container Environment Variables)
 id: container-env-variables
 date: 2018-04-12
-full_link: /ko/docs/concepts/containers/container-environment-variables.md
+full_link: /ko/docs/concepts/containers/container-environment-variables/
 short_description: >
  컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다.

-aka: 
+aka:
 tags:
 - fundamental
 ---
@@ -14,4 +14,4 @@ tags:

 <!--more-->

-컨테이너 환경 변수는 중요한 리소스에 대한 정보와 함께 실행 중인 컨테이너화 된 애플리케이션이 요구하는 정보를 해당 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에 제공한다. 예를 들면, 파일 시스템 상세 정보, 컨테이너 스스로에 대한 정보, 서비스 엔드포인트와 같은 다른 클러스터 리소스에 대한 정보 등이 있다.
+컨테이너 환경 변수는 중요한 리소스에 대한 정보와 함께 실행 중인 컨테이너화 된 애플리케이션이 요구하는 정보를 해당 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에 제공한다. 예를 들면, 파일 시스템 상세 정보, 컨테이너 스스로에 대한 정보, 서비스 엔드포인트와 같은 다른 클러스터 리소스에 대한 정보 등이 있다.
@@ -0,0 +1,21 @@
+---
+title: 컨테이너 런타임
+id: container-runtime
+date: 2019-06-05
+full_link: /docs/reference/generated/container-runtime
+short_description: >
+ 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
+
+aka:
+tags:
+- fundamental
+- workload
+---
+ 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
+
+<!--more-->
+
+쿠버네티스느 여러 컨테이너 런타임을 지원한다. [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)를 구현한 모든 소프트웨어.
@@ -13,7 +13,10 @@ tags:
 ---
 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.

-<!--more--> 
+<!--more-->

-쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다.
+쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면,
+이 데이터를 [백업](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)하는 계획은
+필수이다.

+etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다.
@@ -6,14 +6,17 @@ full_link: /docs/reference/generated/kube-proxy
 short_description: >
  `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.

-aka: 
+aka:
 tags:
 - fundamental
 - core-object
 ---
 `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.

-<!--more--> 
+이는 호스트의 네트워크 규칙을 관리하고 접속 포워딩을 수행하여
+쿠버네티스 서비스 추상화를 가능케 한다.
+
+<!--more-->

 `kube-proxy`는 요청에 대한 포워딩을 책임진다. `kube-proxy`는 TCP 및 UDP 스트림 포워딩을 허용하거나 TCP 및 UDP 포워딩을 백 엔드 기능 집합에 걸쳐 라운드 로빈을 제공한다.

@@ -4,15 +4,14 @@ id: node
 date: 2018-04-12
 full_link: /docs/concepts/architecture/nodes/
 short_description: >
-  노드는 쿠버네티스의 워커 머신이다.
+  노드는 쿠버네티스의 작업 장비(worker machine)이다.

-aka: 
+aka:
 tags:
 - fundamental
 ---
- 노드는 쿠버네티스의 워커 머신이다.
+ 노드는 쿠버네티스의 작업 장비(worker machine)이다.

-<!--more--> 
-
-워커 머신은 클러스터에 따라 VM이거나 물리 머신일 것이다. 그것은 실행해야 하는 {{< glossary_tooltip text="서비스" term_id="service" >}}와 {{< glossary_tooltip text="파드" term_id="pod" >}}를 가지고 있으며, 마스터 컴포넌트에 의해서 관리된다. 노드에 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}는 Docker, kubelet, kube-proxy를 포함한다.
+<!--more-->

+작업 노드는 클러스터에 따라 VM이거나 물리 머신일 것이다. {{< glossary_tooltip text="파드" term_id="pod" >}} 실행에 필요한 로컬 데몬과 서비스를 가지고 있으며, 콘트롤 플레인에 의해서 관리된다. 노드에 있는 데몬은 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}와 {{< glossary_tooltip term_id="docker" >}} 같이 컨테이너 런타임을 구현한 {{< glossary_tooltip text="CRI" term_id="cri" >}}를 포함한다.
@@ -4,16 +4,15 @@ id: service
 date: 2018-04-12
 full_link: /docs/concepts/services-networking/service/
 short_description: >
-  파드의 집합과 같은 애플리케이션에 엑세스하는 방법을 기술하는 API 오브젝트이며, 포트와 로드밸런서를 기술할 수 있다.
+  네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법

 aka: 
 tags:
 - fundamental
 - core-object
 ---
- {{< glossary_tooltip text="파드" term_id="pod" >}}의 집합과 같은 애플리케이션에 엑세스하는 방법을 기술하는 API 오브젝트이며, 포트와 로드밸런서를 기술할 수 있다.
+{{< glossary_tooltip text="파드" term_id="pod" >}} 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법

-<!--more--> 
-
-엑세스 포인트는 클러스터의 내부이거나 외부일 수 있다.
+<!--more-->

+서비스의 대상이 되는 파드 집합은 (보통) {{< glossary_tooltip text="셀렉터" term_id="selector" >}}로 결정된다. 많은 파드가 추가되거나 제거되면, 셀렉터와 일치하는 파드의 집합도 변경된다. 서비스는 네트워크 트래픽을 현재 워크로드를 위한 파드 집합으로 보낼 수 있는지 확인한다.
@@ -1,76 +1,106 @@
 ---
 no_issue: true
-title: 설치
+title: 시작하기
 main_menu: true
-weight: 30
+weight: 20
 content_template: templates/concept
+card:
+  name: setup
+  weight: 20
+  anchors:
+  - anchor: "#학습-환경"
+    title: 학습 환경
+  - anchor: "#운영-환경"
+    title: 운영 환경
 ---

 {{% capture overview %}}

-니즈에 가장 적합한 솔루션 유형을 찾기 위해서는 이 페이지를 사용하길 바란다.
+본 섹션에서는 쿠버네티스를 구축하고 실행하는 여러가지 옵션을 다룬다.

-쿠버네티스를 어디에서 동작시킬지 결정하는 것은 가용한 자원과 요구되는 유연성의 정도에 의존적이다. 쿠버네티스는 랩톱부터, 클라우드 프로바이더의 VM, 베어메탈(bare metal) 서버로 이루어진 랙까지 거의 모든 곳에서 동작시킬 수 있다. 또한 단 하나의 명령어 실행으로 완전-관리되는(fully-managed) 클러스터를 설치할 수도 있고, 베어메탈 서버에 자신만의 맞춤형 클러스터를 만들 수도 있다.
+각각의 쿠버네티스 솔루션은 유지보수의 용이성, 보안, 제어, 가용 자원, 클러스터를 운영하고 관리하기 위해 필요한 전문성과 같은 제각각의 요구사항을 충족한다.
+
+쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 넓은 범위의 클라우드 프로바이더에 걸치거나 베어 메탈 환경을 사용하는 커스텀 솔루션을 만들 수도 있다.
+
+더 간단하게 정리하면, 쿠버네티스 클러스터를 학습 환경과 운영 환경에 만들 수 있다.

 {{% /capture %}}

 {{% capture body %}}

-## 로컬 머신(Local-machine) 솔루션
+## 학습 환경

-로컬 머신 솔루션은 쿠버네티스를 시작하기에 쉬운 방법이다. 클라우드 자원(resource)과 한도(quota)에 대한 걱정 없이 쿠버네티스 클러스터를 생성하고 테스트할 수 있다.
+쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구와 같은 도커 기반의 솔루션을 사용하자.

-다음과 같은 사항을 원한다면 로컬 솔루션을 선택해야 한다. 
+{{< table caption="쿠버네티스를 배포하기 위해 커뮤니티와 생태계에서 지원하는 도구를 나열한 로컬 머신 솔루션 표." >}}

-* 쿠버네티스를 써 보거나 배우기 시작하려고 함
-* 내부적으로 클러스터를 개발하거나 테스트하려고 함
+|커뮤니티              |생태계     |
+| ------------       | --------     |
+| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
+| [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
+| [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) | [Minishift](https://docs.okd.io/latest/minishift/)|
+|                     | [MicroK8s](https://microk8s.io/)|
+|                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
+|                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
+|                     | [k3s](https://k3s.io)|
+|                     | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)|

-[로컬 머신 솔루션](/docs/setup/pick-right-solution/#local-machine-solutions) 중 하나를 선택하길 바란다.

-## 호스트 된(Hosted) 솔루션
+## 운영 환경

-호스트 된 솔루션은 쿠버네티스 클러스터를 생성하고 유지 관리하는데 편리한 방법이다. 호스트가 사용자의 클러스터를 관리하고 운영하기 때문에 사용자는 관리와 운영에서 자유롭다.
+운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자.

-다음의 경우 호스트 된 솔루션이 필요하다.
+몇 가지 가능한 쿠버네티스 클러스터의 추상적인 개념은 {{< glossary_tooltip text="애플리케이션" term_id="applications" >}}, {{< glossary_tooltip text="데이터 플레인" term_id="data-plane" >}}, {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}, {{< glossary_tooltip text="클러스터 인프라스트럭처" term_id="cluster-infrastructure" >}}, 및 {{< glossary_tooltip text="클러스터 운영" term_id="cluster-operations" >}}이다.

-* 완전히 관리된 솔루션을 원함
-* 사용자의 앱 또는 서비스를 개발에만 집중하고 싶음 
-* 지정된 사이트 신뢰성 엔지니어링(SRE) 팀은 없지만 고가용성을 원함
-* 클러스터를 호스팅하고 모니터할 자원이 없음 
+다음의 다이어그램은 쿠버네티스 클러스터에 대해 가능한 추상적인 개념을 나열하고, 각 추상적인 개념을 사용자 스스로 관리하는지 제공자에 의해 관리되는지를 보여준다.

-[호스트 된 솔루션](/docs/setup/pick-right-solution/#hosted-solutions) 중 하나를 선택하길 바란다.
+운영 환경 솔루션![운영 환경 솔루션](/images/docs/KubernetesSolutions.svg)

-## 턴키(Turnkey) – 클라우드 솔루션
+{{< table caption="제공자와 솔루션을 나열한 운영 환경 솔루션 표." >}}
+다음 운영 환경 솔루션 표는 제공자와 솔루션을 나열한다.

-이와 같은 솔루션들은 쿠버네티스 클러스터를 단지 몇 가지 명령어로 생성하게 해준다. 솔루션들은 활발히 개발되며 활동적인 커뮤니티의 지원을 받는다. 또한 넓은 범위의 IaaS 클라우드 프로바이더들에 호스트 될 수 있음에도, 노력의 대가로 솔루션들은 더욱 더 큰 자유와 유연성을 제공한다.
-
-다음의 경우 턴키 클라우드 솔루션을 선택해야 한다.
-
-* 호스트 된 솔루션이 허용하는 것보다는 클러스터에 대한 더 높은 제어권을 원함
-* 운영에 대한 더 큰 소유권을 가지고 싶음 
-
-[턴키 클라우드 솔루션](/docs/setup/pick-right-solution/#turnkey-cloud-solutions) 중 하나를 선택하길 바란다.
-
-## 턴키(Turnkey) – 온-프레미스(On-Premise) 솔루션
-
-이와 같은 솔루션들은 내부의, 안전한, 클라우드 네트워크에 쿠버네티스 클러스터를 단 몇 가지 명령어로 생성하게 해준다.
-
-다음의 경우 온-프레미스 턴키 솔루션을 선택해야 한다.
-
-* 프라이빗 클라우드 네트워크에 클러스터를 디플로이하길 원함 
-* 지정된 사이트 신뢰성 엔지니어링(SRE) 팀을 보유함
-* 클러스터를 호스팅하고 모니터할 수 있는 자원을 보유함
-
-[온-프레미스 턴키 클라우드 솔루션](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions) 중 하나를 선택하길 바란다.
-
-## 사용자 지정(Custom) 솔루션
-
-사용자 지정 솔루션들은 클러스터에 대해서 가장 큰 자유를 제공하지만, 그 대신 높은 전문성을 필요로 한다. 이 솔루션들은 서로 다른 운영체제들에 대해서 베어메탈부터 클라우드 프로바이더들까지의 지원을 포함한다. 
-
-[사용자 지정 솔루션](/docs/setup/pick-right-solution/#custom-solutions) 중 하나를 선택하길 바란다.
+|제공자  | 매니지드 | 턴키 클라우드  | 온-프렘(on-prem) 데이터센터  | 커스텀 (클라우드) | 커스텀 (온-프레미스 VMs)| 커스텀 (베어 메탈) |
+| ---------  | ------  | ------         | ------         | ------         | ------                  | -----               |
+| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)|                | &#x2714;       | &#x2714;         |       |                    |
+| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)|     | &#x2714; |          |    |                      |
+| [Amazon](https://aws.amazon.com)   | [Amazon EKS](https://aws.amazon.com/eks/)   |[Amazon EC2](https://aws.amazon.com/ec2/)  |          |        |                       |
+| [AppsCode](https://appscode.com/products/pharmer/)          | &#x2714;      |  |       |         |  |
+| [APPUiO](https://appuio.ch/)  | &#x2714;     | &#x2714;  |   &#x2714; | |  | |
+| [CenturyLink Cloud](https://www.ctl.io/)     |       | &#x2714; |   |  | |
+| [Cisco Container Platform](https://cisco.com/go/containers)     |       |  | &#x2714;  |  | |
+| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)       |     |  |   | &#x2714; |&#x2714; |
+| [CloudStack](https://cloudstack.apache.org/)           |      |  |   | | &#x2714;|
+| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart)      |              | &#x2714;       |             | &#x2714;     |&#x2714;  | &#x2714;
+| [Containership](https://containership.io/containership-platform)            | &#x2714;       |&#x2714;  |     |     |                   |
+| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html)            |        |  |      |     |  | &#x2714;
+| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/)        | &#x2714;      |  |      |     |            |
+| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) |       |&#x2714;  | &#x2714;     |  |     | &#x2714;
+| [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)     |      |  |      | |    &#x2714;       | &#x2714;
+| [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)     |      |  |      | |           | &#x2714;
+| [Gardner](https://gardener.cloud/)       |              |&#x2714;  |         | &#x2714;   |          |
+| [Giant Swarm](https://giantswarm.io/)     | &#x2714;       | &#x2714; |   &#x2714;    |     |
+| [Google](https://cloud.google.com/)           |  [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/)       | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/)       |  |  |     |  |      |       |  |
+| [IBM](https://www.ibm.com/in-en/cloud)        | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
+| [Kontena Pharos](https://www.kontena.io/pharos/)          |    |&#x2714;|    &#x2714;    |        |         |
+| [Kubermatic](https://www.loodse.com/)         |     &#x2714;  | &#x2714; | &#x2714;     |     |  |
+| [KubeSail](https://kubesail.com/)    | &#x2714;       |  |      |     |        |
+| [Kubespray](https://kubespray.io/#/)       |       |    |       |&#x2714;  | &#x2714; | &#x2714; |
+| [Kublr](https://kublr.com/)        |&#x2714; | &#x2714;  |&#x2714;       |&#x2714;  |&#x2714; |&#x2714; |
+| [Microsoft Azure](https://azure.microsoft.com)    |  [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/)     |  |     |        |    |
+| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)    |       |  | &#x2714; |  |    |
+| [Nirmata](https://www.nirmata.com/)          |              |   &#x2714;     | &#x2714;            |      |          |
+| [Nutanix](https://www.nutanix.com/en)         | [Nutanix Karbon](https://www.nutanix.com/products/karbon)             | [Nutanix Karbon](https://www.nutanix.com/products/karbon)       |             |      | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization)         |
+| [OpenShift](https://www.openshift.com)          |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/)              |        | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/)            |      |  [OpenShift Container Platform](https://www.openshift.com/products/container-platform/)        |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
+| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm)          | &#x2714;             |   &#x2714;     |             |      |          |
+| [oVirt](https://www.ovirt.org/)         |              |        |             |     | &#x2714;          |
+| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service)           |      |          |
+| [Platform9](https://platform9.com/)         | &#x2714;             | &#x2714;      | &#x2714;            |      |   &#x2714;       |&#x2714;
+| [Rancher](https://rancher.com/)         |              |   [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/)     |             |  [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/)    |          | [k3s](https://k3s.io/)
+| [StackPoint](https://stackpoint.io/)          | &#x2714;            |  &#x2714;      |             |      |          |
+| [Supergiant](https://supergiant.io/)         |              |&#x2714;        |             |      |          |
+| [SUSE](https://www.suse.com/)        |              | &#x2714;       |             |      |          |
+| [SysEleven](https://www.syseleven.io/)         | &#x2714;             |        |             |      |          |
+| [VEXXHOST](https://vexxhost.com/)         | &#x2714;             | &#x2714;      |             |      |          |
+| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)              |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)        |   [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)          | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)      |          |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)

 {{% /capture %}}
-
-{{% capture whatsnext %}}
-완전한 솔루션 리스트를 확인하기 위해서는 [올바른 솔루션 선택하기](/docs/setup/pick-right-solution/)로 가길 바란다.
-{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: 모범 사례
+weight: 40
+---
@@ -1,6 +1,7 @@
 ---
 title: PKI 인증서 및 요구 조건
 content_template: templates/concept
+weight: 40
 ---

 {{% capture overview %}}
@@ -84,15 +85,15 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.

 | 기본 CN                      | 권고되는 키 파일 경로         | 권고하는 인증서 파일 경로   | 명령어         | 키 파라미터                  | 인증서 파라미터                           |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
-| etcd-ca                      |                              | etcd/ca.crt                 | kube-apiserver |                              | --etcd-cafile                             |
+| etcd-ca                      |     etcd/ca.key                         | etcd/ca.crt                 | kube-apiserver |                              | --etcd-cafile                             |
 | etcd-client                  | apiserver-etcd-client.key    | apiserver-etcd-client.crt   | kube-apiserver | --etcd-keyfile               | --etcd-certfile                           |
-| kubernetes-ca                |                              | ca.crt                      | kube-apiserver |                              | --client-ca-file                          |
+| kubernetes-ca                |    ca.key                          | ca.crt                      | kube-apiserver |                              | --client-ca-file                          |
 | kube-apiserver               | apiserver.key                | apiserver.crt               | kube-apiserver | --tls-private-key-file       | --tls-cert-file                           |
-| apiserver-kubelet-client     |                              | apiserver-kubelet-client.crt| kube-apiserver |                              | --kubelet-client-certificate              |
-| front-proxy-ca               |                              | front-proxy-ca.crt          | kube-apiserver |                              | --requestheader-client-ca-file            |
+| apiserver-kubelet-client     |     apiserver-kubelet-client.key                         | apiserver-kubelet-client.crt| kube-apiserver |                              | --kubelet-client-certificate              |
+| front-proxy-ca               |     front-proxy-ca.key                         | front-proxy-ca.crt          | kube-apiserver |                              | --requestheader-client-ca-file            |
 | front-proxy-client           | front-proxy-client.key       | front-proxy-client.crt      | kube-apiserver | --proxy-client-key-file      | --proxy-client-cert-file                  |
 |                              |                              |                             |                |                              |                                           |
-| etcd-ca                      |                              | etcd/ca.crt                 | etcd           |                              | --trusted-ca-file, --peer-trusted-ca-file |
+| etcd-ca                      |         etcd/ca.key                     | etcd/ca.crt                 | etcd           |                              | --trusted-ca-file, --peer-trusted-ca-file |
 | kube-etcd                    | etcd/server.key              | etcd/server.crt             | etcd           | --key-file                   | --cert-file                               |
 | kube-etcd-peer               | etcd/peer.key                | etcd/peer.crt               | etcd           | --peer-key-file              | --peer-cert-file                          |
 | etcd-ca                      |                              | etcd/ca.crt                 | etcdctl[2]     |                              | --cacert                                  |
@@ -128,12 +129,12 @@ KUBECONFIG=<filename> kubectl config use-context default-system

 이 파일들은 다음과 같이 사용된다.

-| 파일명                | 명령어                  | 설명                                                                  | 
+| 파일명                   | 명령어                  | 설명                                                                   |
 |-------------------------|-------------------------|-----------------------------------------------------------------------|
-| admin.conf              | kubectl                 | 클러스터 관리자를 설정한다.                                           |
-| kubelet.conf            | kubelet                 | 클러스터 각 노드를 위해 필요하다.                                     |
+| admin.conf              | kubectl                 | 클러스터 관리자를 설정한다.                                              |
+| kubelet.conf            | kubelet                 | 클러스터 각 노드를 위해 필요하다.                            |
 | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. |
-| scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다. |
+| scheduler.conf          | kube-scheduler          | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다.          |

 [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
 [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
@@ -1,6 +1,6 @@
 ---
 title: 대형 클러스터 구축
-weight: 80
+weight: 20
 ---

 ## 지원
@@ -1,6 +1,6 @@
 ---
 title: 여러 영역에서 구동
-weight: 90
+weight: 10
 content_template: templates/concept
 ---

@@ -1,5 +1,6 @@
 ---
 title: 노드 구성 검증하기
+weight: 30
 ---

 {{< toc >}}
@@ -1,4 +0,0 @@
---
-title: 사용자 지정 클라우드 솔루션
-weight: 50
---
@@ -1,5 +0,0 @@
---
-title: "kubeadm으로 클러스터 부트스트래핑 하기"
-weight: 30
---
-
@@ -0,0 +1,4 @@
+---
+title: 학습 환경
+weight: 20
+---
@@ -1,11 +1,11 @@
 ---
-title: Minikube로 로컬 상에서 쿠버네티스 구동
-content_template: templates/concept	
+title: Minikube로 쿠버네티스 설치
+content_template: templates/concept
 ---

 {{% capture overview %}}

-Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 VM 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다.
+Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 가상 머신(VM) 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다.

 {{% /capture %}}

@@ -13,14 +13,15 @@ Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Mi

 ## Minikube 특징

-* Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다.
-  * DNS
-  * 노드 포트
-  * 컨피그 맵과 시크릿
-  * 대시보드
-  * 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd)
-  * CNI(Container Network Interface) 사용
-  * 인그레스
+Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다.
+
+* DNS
+* 노드 포트
+* 컨피그 맵과 시크릿
+* 대시보드
+* 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd)
+* CNI(Container Network Interface) 사용
+* 인그레스

 ## 설치

@@ -28,123 +29,183 @@ Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Mi

 ## 빠른 시작

-여기부터는 Minikube 사용에 대한 간단한 데모이다.
-VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를 `minikube start`에 추가한다.
-Minikube는 다음의 드라이버를 지원한다.
+여기서 기술하는 간단한 데모는 어떻게 로컬에서 Minikube를 시작하고, 사용하고 삭제하는지를 안내한다. 다음의 주어진 단계를 따라서 Minikube를 시작하고 탐구한다.
+
+1. Minikube를 시작하고 클러스터를 생성
+    ```shell
+    minikube start
+    ```
+    결과는 다음과 비슷하다.
+
+    ```
+    Starting local Kubernetes cluster...
+    Running pre-create checks...
+    Creating machine...
+    Starting local Kubernetes cluster...
+    ```
+    특정 쿠버네티스 버전, VM, 컨테이너 런타임 상에서 클러스터를 시작하기 위한 보다 상세한 정보는 [클러스터 시작하기](#클러스터-시작하기)를 참조한다.
+
+2. 이제, kubectl을 통해서 클러스터와 상호작용할 수 있다. 보다 상세한 정보는 [클러스터와 상호 작용하기](#클러스터와-상호-작용하기)를 참조한다.
+
+    단순한 HTTP 서버인 `echoserver` 이미지를 사용해서 쿠버네티스 디플로이먼트를 만들고 `--port`를 이용해서 8080 포트로 노출해보자.
+    ```shell
+    kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
+    ```
+    결과는 다음과 비슷하다.
+    ```
+    deployment.apps/hello-minikube created
+    ```
+3. `hello-minikube` 디플로이먼트에 액세스하기 위해, 서비스로 노출시킨다.
+    ```shell
+    kubectl expose deployment hello-minikube --type=NodePort
+    ```
+    `--type=NodePort` 옵션은 서비스 타입을 지정한다.
+
+    결과는 다음과 비슷하다.
+    ```
+    service/hello-minikube exposed
+    ```
+4. `hello-minikube` 파드가 이제 시작되었지만 노출된 서비스를 통해서 접근하기 전에 파드가 뜨기를 기다려야한다.
+
+	파드가 떠서 구동되고 있는지 확인한다.
+	```shell
+	kubectl get pod
+	```
+	출력에서 `STATUS`가 `ContainerCreating`으로 나타나는 경우, 파드는 아직 생성 중이다.
+	```
+	NAME                              READY     STATUS              RESTARTS   AGE
+	hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
+	```
+	출력에서 `STATUS`가 `Running`으로 나타나는 경우, 파드는 이제 떠서 기동 중이다.
+	```
+	NAME                              READY     STATUS    RESTARTS   AGE
+	hello-minikube-3383150820-vctvh   1/1       Running   0          13s
+	```
+5. 서비스 상세를 보기 위해서 노출된 서비스의 URL을 얻는다.
+	```shell
+	minikube service hello-minikube --url
+	```
+6. 로컬 클러스터의 상세를 보기위해서, 출력에서 얻은 URL을 브라우저에 복사해서 붙여 넣는다.
+
+    출력은 다음과 비슷하다.
+    ```
+    Hostname: hello-minikube-7c77b68cff-8wdzq
+
+    Pod Information:
+        -no pod information available-
+
+    Server values:
+        server_version=nginx: 1.13.3 - lua: 10008
+
+    Request Information:
+        client_address=172.17.0.1
+        method=GET
+        real path=/
+        query=
+        request_version=1.1
+        request_scheme=http
+        request_uri=http://192.168.99.100:8080/
+
+    Request Headers:
+        accept=*/*
+        host=192.168.99.100:30674
+        user-agent=curl/7.47.0
+
+    Request Body:
+        -no body in request-
+    ```
+  서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다.  
+7. `hello-minikube` 서비스 삭제
+    ```shell
+    kubectl delete services hello-minikube
+    ```
+    출력은 다음과 비슷하다.
+    ```
+    service "hello-minikube" deleted
+    ```
+8. `hello-minikube` 디플로이먼트 삭제
+    ```shell
+    kubectl delete deployment hello-minikube
+    ```
+    출력은 다음과 비슷하다.
+    ```
+    deployment.extensions "hello-minikube" deleted
+    ```
+9. 로컬 Minikube 클러스터 중지
+    ```shell
+    minikube stop
+    ```
+    출력은 다음과 비슷하다.
+    ```
+    Stopping "minikube"...
+    "minikube" stopped.
+    ```
+	보다 상세한 정보는 [클러스터 중지하기](#클러스터-중지하기)를 참조한다.
+10. 로컬 Minikube 클러스터 삭제
+    ```shell
+    minikube delete
+    ```
+    출력은 다음과 비슷하다.
+    ```
+    Deleting "minikube" ...
+    The "minikube" cluster has been deleted.
+    ```
+	보다 상세한 정보는 [Deleting a cluster](#클러스터-삭제하기)를 참조한다.
+
+## 클러스터 관리하기
+
+### 클러스터 시작하기
+
+클러스터를 시작하기 위해서 `minikube start` 커멘드를 사용할 수 있다.
+이 커멘드는 단일 노드 쿠버네티스 클러스터를 구동하는 가상 머신을 생성하고 구성한다.
+이 커멘드는 또한 [kubectl](/docs/user-guide/kubectl-overview/)도 설정해서 클러스터와 통신할 수 있도록 한다.
+
+{{< note >}}
+웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. 
+
+```shell
+https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
+```
+불행하게도, 환경 변수 설정만으로는 되지 않는다.
+
+Minikube는 또한 "minikube" 컨텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다.
+이 컨텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`.
+{{< /note >}}
+
+#### 쿠버네티스 버전 지정하기
+
+`minikube start` 코멘드에 `--kubernetes-version` 문자열을 
+추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. 
+예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다.
+
+```
+minikube start --kubernetes-version {{< param "fullversion" >}}
+```
+#### VM 드라이버 지정하기
+`minikube start` 코멘드에 `--vm-driver=<enter_driver_name>` 플래그를 추가해서 VM 드라이버를 변경할 수 있다.
+코멘드를 예를 들면 다음과 같다.
+```shell
+minikube start --vm-driver=<driver_name>
+```
+ Minikube는 다음의 드라이버를 지원한다.
+ {{< note >}}
+ 지원되는 드라이버와 플러그인 설치 방법에 대한 보다 상세한 정보는 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 참조한다.
+{{< /note >}}

 * virtualbox
 * vmwarefusion
-* kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
-* hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
-아래 나오는 IP주소는 동적이고 변할 수 있음을 알린다. 이는 `minikube ip` 명령으로 확인할 수 있다.
-* vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
-* none (쿠버네티스 구성요소는 VM이 아닌 호스트상에서 동작한다. 이 드라이버를 사용하기 위해서는 Docker ([docker 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))와 리눅스 환경)이 필요하다.
-
-```shell
-minikube start
-```
-```
-Starting local Kubernetes cluster...
-Running pre-create checks...
-Creating machine...
-Starting local Kubernetes cluster...
-```
-```shell
-kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
-```
-```
-deployment.apps/hello-minikube created
-```
-
-```shell
-kubectl expose deployment hello-minikube --type=NodePort
-```
-```
-service/hello-minikube exposed
-```
-
-에코 서버 파드를 실행했지만 노출된 서비스를 통해 curl 등의 접근하기 전에
-파드가 올라갈 때까지 기다려야 한다.
-파드가 실행 중인지 확인하기 위해 다음을 이용할 수 있다.
-
-```
-kubectl get pod
-```
-```
-NAME                              READY     STATUS              RESTARTS   AGE
-hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
-```
-
-이 파드는 ContainerCreating 상태임을 알 수 있다.
-kubectl get pod
-
-```
-NAME                              READY     STATUS    RESTARTS   AGE
-hello-minikube-3383150820-vctvh   1/1       Running   0          13s
-```
-
-이제 파드가 Running 상태이므로 curl를 실행해 볼 수 있다.
-
-```
-curl $(minikube service hello-minikube --url)
-```
-```
-
-Hostname: hello-minikube-7c77b68cff-8wdzq
-
-Pod Information:
-	-no pod information available-
-
-Server values:
-	server_version=nginx: 1.13.3 - lua: 10008
-
-Request Information:
-	client_address=172.17.0.1
-	method=GET
-	real path=/
-	query=
-	request_version=1.1
-	request_scheme=http
-	request_uri=http://192.168.99.100:8080/
-
-Request Headers:
-	accept=*/*
-	host=192.168.99.100:30674
-	user-agent=curl/7.47.0
-
-Request Body:
-	-no body in request-
-```
-
-```shell
-kubectl delete services hello-minikube
-```
-```
-service "hello-minikube" deleted
-```
-
-```shell
-kubectl delete deployment hello-minikube
-```
-```
-deployment.extensions "hello-minikube" deleted
-```
-
-```shell
-minikube stop
-```
-```
-Stopping local Kubernetes cluster...
-Stopping "minikube"...
-```
-
-### 다른 컨테이너 런타임
-
-#### containerd
+* kvm2 ([드라이버 설치](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
+* hyperkit ([드라이버 설치](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
+* hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다.
+* vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
+* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/)))

+#### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기
+Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다.
+{{< tabs name="container_runtimes" >}}
+{{% tab name="containerd" %}}
 [containerd](https://github.com/containerd/containerd)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.
-
 ```bash
 minikube start \
    --network-plugin=cni \
@@ -164,9 +225,8 @@ minikube start \
    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
    --bootstrapper=kubeadm
 ```
-
-#### CRI-O
-
+{{% /tab %}}
+{{% tab name="CRI-O" %}}
 [CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.

 ```bash
@@ -176,7 +236,6 @@ minikube start \
    --container-runtime=cri-o \
    --bootstrapper=kubeadm
 ```
-
 혹은 확장 버전을 사용할 수 있다.

 ```bash
@@ -188,9 +247,8 @@ minikube start \
    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
    --bootstrapper=kubeadm
 ```
-
-#### rkt 컨테이너 엔진
-
+{{% /tab %}}
+{{% tab name="rkt container engine" %}}
 [rkt](https://github.com/rkt/rkt)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.

 ```shell
@@ -199,37 +257,38 @@ minikube start \
    --enable-default-cni \
    --container-runtime=rkt
 ```
-
 이것은 rkt와 Docker와 CNI 네트워킹을 포함하는 대안적인 Minikube ISO 이미지를 이용한다.
+{{% /tab %}}
+{{< /tabs >}}

-### 드라이버 플러그인
+#### Docker 데몬 재사용을 통한 로컬 이미지 사용하기

-지원하는 드라이버 상세 정보와 설치방법은 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 살펴보자
-꼭 필요하다면 말이다.
+쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 도커 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 도커 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 도커 데몬 안에서 이미지를 빌드하기 때문이다.

-### Docker 데몬 재사용
+{{< note >}}
+Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다.
+{{< /note >}}

-쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 Docker 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 Docker 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 Docker 데몬 안에서 이미지를 빌드하기 때문이다. Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다.
-
-맥이나 리눅스 호스트의 Docker 데몬에서 이 작업이 가능하게 하려면 `docker-env command`를 쉘에서 사용해야 한다.
+맥이나 리눅스 호스트에서 해당 Docker 데몬을 사용하려면 `docker-env command`를 쉘에서 사용해야 한다.

 ```shell
 eval $(minikube docker-env)
 ```

-맥이나 리눅스 호스트에서 Minikube VM안에 Docker 데몬과 통신하도록 Docker를 명령행에서 사용할 수 있어야 한다.
+이제 개인의 맥/리눅스 머신 내 커멘드 라인에서 도커를 사용해서 Minikube VM 안의 도커 데몬과 통신할 수 있다.

 ```shell
 docker ps
 ```

+{{< note >}}
 Centos 7 에서 Docker는 아래와 같은 오류를 발생한다.

-```shell
+```
 Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
 ```

-해결 방법은 /etc/sysconfig/docker를 Minikube의 환경 변화를 기대한 것대로 바꾸도록 업데이트하는 것이다.
+/etc/sysconfig/docker를 업데이트하고 Minikube의 환경에 변경이 반영되었는지 확인해서 고칠 수 있다.

 ```shell
 < DOCKER_CERT_PATH=/etc/docker
@@ -238,39 +297,9 @@ Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no
 >   DOCKER_CERT_PATH=/etc/docker
 > fi
 ```
+{{< /note >}}

-imagePullPolicy:Always를 꺼야하는 것은 명심하자. 그렇지 않으면 쿠버네티스가 로컬에서 빌드한 이미지를 사용하지 않는다.
-
-## 클러스터 관리
-
-### 클러스터 시작
-
-`minikube start` 명령은 클러스터를 시작하는데 사용할 수 있다.
-이 명령은 단일 노드 쿠버네티스 클러스터를 실행하는 가상머신을 생성하고 구성한다.
-또한 클러스터와 통신하기 위해 [kubectl](/docs/user-guide/kubectl-overview/)를 구성한다.
-
-만약 웹 프록시를 사용 중이라면 `minikube start` 명령에서 이 정보를 포함해야 한다.
-
-```shell
-https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
-```
-
-불행히 환경 설정 변수만으로는 동작하지 않는다.
-
-Minikube는 또한 "minikube" 컨텍스트를 생성하고, kubectl의 기본값으로 설정한다.
-나중에 이 컨택스트를 변경하려면, `kubectl config use-context minikube` 명령을 실행하자.
-
-#### 쿠버네티스 버전 지정
-
-Minikube에서 사용할 쿠버네티스 버전은 `--kubernetes-version` 문자열을
-`minikube start` 명령에 추가하여 지정할 수 있다.
-예를 들어, `v1.7.3`을 이용한다면 아래처럼 할 수 있다.
-
-```
-minikube start --kubernetes-version v1.7.3
-```
-
-### 쿠버네티스 구성
+### 쿠버네티스 구성하기

 Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설정할 수 있도록 하는 '설정기' 기능이 있다.
 이 기능을 사용하려면, `--extra-config` 플래그를 `minikube start` 명령어에 추가하여야 한다.
@@ -307,18 +336,18 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설
 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다.
 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다.

-## 클러스터와 상호 작용
+## 클러스터와 상호 작용하기

 ### Kubectl

-`minikube start` 명령어는 Minikube로 부르는 "[kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)" 를 생성한다. 
+`minikube start` 명령어는 Minikube로 부르는 [kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다.
 이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다.

 Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 

 `kubectl config use-context minikube`을 실행하자.

-혹은 각 명령어를 `kubectl get pods --context=minikube`처럼 컨텍스트를 전달하십시오.
+혹은 `kubectl get pods --context=minikube`처럼 코멘드를 실행할때마다 매번 컨텍스트를 전달한다.

 ### 대시보드

@@ -400,7 +429,7 @@ Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터
 폴더 내부의 애드온은 Minikube VM으로 이동되어
 Minikube가 시작하거나 재시작될 때에 함께 실행된다.

-## HTTP 프록시 환경에서 Minikube 사용
+## HTTP 프록시 환경에서 Minikube 사용하기

 Minikube는 쿠버네티스와 Docker 데몬을 포함한 가상 머신을 생성한다.
 쿠버네티스가 Docker를 이용하여 컨테이너를 스케쥴링 시도할 때에, Docker 데몬은 컨테이너 이미지를 풀링하기 위해 외부 네트워크를 이용해야 한다.
@@ -0,0 +1,4 @@
+---
+title: 운영 환경
+weight: 30
+---
@@ -1,7 +1,7 @@
 ---
-title: CRI 설치
+title: 컨테이너 런타임
 content_template: templates/concept
-weight: 100
+weight: 10
 ---
 {{% capture overview %}}
 {{< feature-state for_k8s_version="v1.6" state="stable" >}}
@@ -281,7 +281,7 @@ systemctl restart containerd

 `systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`의 `plugins.cri.systemd_cgroup = true`을 설정한다.
 kubeadm을 사용하는 경우에도 마찬가지로, 수동으로
-[cgroup driver for kubelet](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을 
+[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을 
 설정해준다.

 ## 다른 CRI 런타임: frakti
@@ -1,4 +1,4 @@
 ---
 title: 온-프레미스 VM
-weight: 60
+weight: 40
 ---
@@ -1,6 +1,7 @@
 ---
-title: Kops로 AWS에 쿠버네티스 설치하기
+title: Kops로 쿠버네티스 설치하기
 content_template: templates/concept
+weight: 20
 ---

 {{% capture overview %}}
@@ -1,4 +1,4 @@
 ---
 title: 턴키 클라우드 솔루션
-weight: 40
+weight: 30
 ---
@@ -1,5 +1,5 @@
 ---
-title: "쿠버네티스 다운로드"
-weight: 20
+title: "릴리스 노트와 버전 차이 지원(skew)"
+weight: 10
 ---

@@ -1,30 +0,0 @@
---
-title: 릴리스 빌드
-content_template: templates/concept
-card:
-  name: download
-  weight: 20
-  title: 릴리스 빌드하기
---
-
-{{% capture overview %}}
-소스로부터 빌드하거나 이미 빌드된 릴리스를 다운받을 수 있다. 쿠버네티스를 자체를 개발할 계획이 없다면, [릴리스 노트](/docs/setup/release/notes/)에 있는 현재 릴리스 빌드 버전을 사용하는 것을 추천한다.
-
-쿠버네티스 소스 코드는 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 리포지토리에서 다운받을 수 있다.
-{{% /capture %}}
-
-{{% capture body %}}
-## 소스로부터 빌드
-
-소스 코드를 빌드만 하려면, 모든 빌드 과정이 Docker 컨테이너 안에서 실행되기 때문에 golang 환경을 구축할 필요가 없다.
-
-릴리스를 빌드하는 것은 간단하다.
-
-```shell
-git clone https://github.com/kubernetes/kubernetes.git
-cd kubernetes
-make release
-```
-
-릴리스 절차에 대한 더 자세한 설명은 kubernetes/kubernetes [`빌드`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) 디렉토리를 참조한다.
-{{% /capture %}}
@@ -6,8 +6,8 @@ weight: 110

 {{% capture overview %}}

-이 페이지는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지
-살펴본다.
+이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지
+살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.

 {{% /capture %}}

@@ -135,11 +135,13 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트
 * [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여
 더 공부한다.

-* [모듈 구조를 위한 컴포지트 컨테이너](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
-공부한다.
+* [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
+더 공부한다.

-* [저장소로 볼륨을 사용하는 파드 구성 방법](/docs/tasks/configure-pod-container/configure-volume-storage/)을
-참고한다.
+* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여
+확인한다.
+
+* [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다.

 * [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 확인한다.

@@ -6,7 +6,9 @@ weight: 100

 {{% capture overview %}}

-Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다.
+Horizontal Pod Autoscaler는
+CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
+레플리케이션 컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다.

 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.

@@ -17,9 +19,16 @@ Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플
 {{% capture prerequisites %}}

 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다.
-[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다.
+[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다.
+Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다.
+메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다.

-Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, 버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. 마지막으로, 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우 버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다. 자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다.
+Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우,
+버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다.
+또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
+마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우,
+버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다.
+자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다.

 {{% /capture %}}

@@ -30,7 +39,6 @@ Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하
 Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다.
 Dockerfile은 다음과 같다.

-
 ```
 FROM php:5-apache
 ADD index.php /var/www/html/index.php
@@ -61,9 +69,14 @@ deployment.apps/php-apache created

 ## Horizontal Pod Autoscaler 생성

-이제 서비스가 동작중이므로, [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 
-사용하여 오토스케일러를 생성한다. 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
-간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. ([kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고, 따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.) 이에 대한 자세한 알고리즘은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)를 참고하기 바란다.
+이제 서비스가 동작중이므로,
+[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 사용하여 오토스케일러를 생성한다.
+다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를
+1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
+간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
+[kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고,
+따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
+이에 대한 자세한 알고리즘은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)를 참고하기 바란다.

 ```shell
 kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
@@ -109,7 +122,8 @@ php-apache   Deployment/php-apache/scale   305% / 50%  305%      1         10

 ```

-CPU 소비가 305%까지 증가하였다. 결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다.
+CPU 소비가 305%까지 증가하였다.
+결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다.

 ```shell
 kubectl get deployment php-apache
@@ -120,13 +134,19 @@ php-apache   7         7         7            7           19m
 ```

 {{< note >}}
-레플리카의 개수를 안정화시키는데 몇 분이 걸릴 수 있다. 부하의 양은 환경에 따라 다르기 때문에, 최종 레플리카의 개수는 본 예제와 다를 수 있다.
+레플리카의 개수를 안정화시키는데 몇 분이 걸릴 수 있다.
+부하의 양은 환경에 따라 다르기 때문에,
+최종 레플리카의 개수는 본 예제와 다를 수 있다.
 {{< /note >}}

 ## 부하 중지

 본 예제를 마무리하기 위해 부하를 중단시킨다.
-`busybox` 컨테이너를 띄운 터미널에서, `<Ctrl> + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다.
+
+`busybox` 컨테이너를 띄운 터미널에서,
+`<Ctrl> + C`로 부하 발생을 중단시킨다.
+
+그런 다음 (몇 분 후에) 결과를 확인한다.

 ```shell
 kubectl get hpa
@@ -156,7 +176,8 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮

 ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링

-`php-apache` 디플로이먼트를 오토스케일링할 때 `autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다.
+`php-apache` 디플로이먼트를 오토스케일링할 때,
+`autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다.

 첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.

@@ -200,15 +221,26 @@ status:
        averageValue: 0
 ```

-`targetCPUUtilizationPercentage` 필드가 `metrics` 배열로 대체되었다. CPU 사용량 메트릭은 *resource metric* 으로 파드 컨테이너 자원의 백분율로 표현된다. CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원되는 다른 메트릭은 메모리뿐이다. 이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며, `metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다.
+`targetCPUUtilizationPercentage` 필드가 `metrics` 배열로 대체되었다.
+CPU 사용량 메트릭은 *resource metric* 으로 파드 컨테이너 자원의 백분율로 표현된다.
+CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원되는 다른 메트릭은 메모리뿐이다.
+이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며,
+`metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다.

-또한, `AverageUtilization` 대신 `AverageValue`의 `target` 타입을, 그리고 `target.averageUtilization` 대신 `target.averageValue`로 설정하여 자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다.
+또한, `AverageUtilization` 대신 `AverageValue`의 `target` 타입을,
+그리고 `target.averageUtilization` 대신 `target.averageValue`로 설정하여
+자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다.

-파드 메트릭과 오브젝트 메트릭 두 가지의 *사용자 정의 메트릭* 이 있다. 파드 메트릭과 오브젝트 메트릭. 이 메트릭은 클러스터에 특화된 이름을 가지고 있으며, 더 고급화된 클러스터 모니터링 설정이 필요하다.
+파드 메트릭과 오브젝트 메트릭 두 가지의 *사용자 정의 메트릭* 이 있다.
+파드 메트릭과 오브젝트 메트릭. 이 메트릭은 클러스터에 특화된 이름을 가지고 있으며,
+더 고급화된 클러스터 모니터링 설정이 필요하다.

-이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다. 이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며, 대상 값과 비교하여 레플리카 개수를 결정한다.
+이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다.
+이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며,
+대상 값과 비교하여 레플리카 개수를 결정한다.

-이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, 자원 메트릭과 매우 유사하게 동작한다.
+이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면,
+자원 메트릭과 매우 유사하게 동작한다.

 파드 메트릭은 이처럼 메트릭 블록을 사용하여 정의된다.

@@ -223,7 +255,13 @@ pods:
    averageValue: 1k
 ```

-두 번째 대체 메트릭 타입은 *오브젝트 메트릭* 이다. 이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다. 이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다. 오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다. `Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다. `AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다. 다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다.
+두 번째 대체 메트릭 타입은 *오브젝트 메트릭* 이다.
+이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다.
+이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다.
+오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다.
+`Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다.
+`AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다.
+다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다.

 ```yaml
 type: Object
@@ -239,9 +277,12 @@ object:
    value: 2k
 ```

-이러한 메트릭 블록을 여러 개 제공하면, HorizontalPodAutoscaler는 각 메트릭을 차례로 고려한다. HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수를 계산하고, 그중 가장 높은 레플리카 개수를 선정한다.
+이러한 메트릭 블록을 여러 개 제공하면, HorizontalPodAutoscaler는 각 메트릭을 차례로 고려한다.
+HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수를 계산하고,
+그중 가장 높은 레플리카 개수를 선정한다.

-예를 들어, 네트워크 트래픽 메트릭을 수집하는 모니터링 시스템이 있는 경우, `kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다.
+예를 들어, 네트워크 트래픽 메트릭을 수집하는 모니터링 시스템이 있는 경우,
+`kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다.

 ```yaml
 apiVersion: autoscaling/v2beta1
@@ -303,11 +344,17 @@ status:
        value: 10k
 ```

-이후, HorizontalPodAutoscaler는 각 파드가 요청 된 약 50%의 CPU 사용률을 소모하는지, 초당 1000 패킷을 처리하는지, 메인-루트 인그레스 뒤의 모든 파드들이 초당 10000 요청을 처리하는지 확인한다.
+이후, HorizontalPodAutoscaler는 각 파드가 요청 된 약 50%의 CPU 사용률을 소모하는지,
+초당 1000 패킷을 처리하는지,
+메인-루트 인그레스 뒤의 모든 파드들이 초당 10000 요청을 처리하는지 확인한다.

 ### 보다 구체적인 메트릭을 기초로한 오토스케일링

-많은 메트릭 파이프라인들을 사용하면 이름 또는 _labels_ 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다. 그리고, 모든 비 자원 메트릭 타입(파드, 오브젝트 그리고 아래 기술된 외부 타입)에 대해, 메트릭 파이프라인으로 전달되는 추가 레이블 셀렉터를 지정할 수 있다. 예를 들면, `verb` 레이블로 `http_requests` 메트릭을 수집하는 경우, 다음과 같이 메트릭 블록을 지정하여 GET 요청에 대해 크기를 조정할 수 있다.
+많은 메트릭 파이프라인들을 사용하면 이름 또는 _labels_ 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다.
+그리고, 모든 비 자원 메트릭 타입(파드, 오브젝트 그리고 아래 기술된 외부 타입)에 대해,
+메트릭 파이프라인으로 전달되는 추가 레이블 셀렉터를 지정할 수 있다.
+예를 들면, `verb` 레이블로 `http_requests` 메트릭을 수집하는 경우,
+다음과 같이 메트릭 블록을 지정하여 GET 요청에 대해 크기를 조정할 수 있다.

 ```yaml
 type: Object
@@ -317,18 +364,30 @@ object:
    selector: `verb=GET`
 ```

-이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다. 모니터링 파이프라인은 네임과 셀렉터가 여러 시리즈와 일치하는 경우, 해당 여러 시리즈를 단일 값으로 축소하는 방법을 결정한다. 셀렉터는 부가적인 속성이며, 대상 오브젝트(`Pods` 타입의 대상 파드, `Object` 타입으로 기술된 오브젝트)가 아닌 메트릭을 선택할 수 없다.
+이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다.
+모니터링 파이프라인은 네임과 셀렉터가 여러 시리즈와 일치하는 경우,
+해당 여러 시리즈를 단일 값으로 축소하는 방법을 결정한다.
+셀렉터는 부가적인 속성이며,
+대상 오브젝트(`Pods` 타입의 대상 파드, `Object` 타입으로 기술된 오브젝트)가 아닌 메트릭을 선택할 수 없다.

 ### 쿠버네티스 오브젝트와 관련이 없는 메트릭을 기초로한 오토스케일링

-쿠버네티스 위에서 동작하는 애플리케이션은 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여 오토스케일링을 할 수도 있다. 예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다. 쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭* 을 사용하여 이러한 유스케이스를 해결할 수 있다.
+쿠버네티스 위에서 동작하는 애플리케이션은, 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여
+오토스케일링을 할 수도 있다.
+예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다.
+쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭* 을 사용하여 이러한 유스케이스를 해결할 수 있다.

-외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다. 이 설치는 사용자 정의 메트릭과 유사하다.
+외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다.
+이 설치는 사용자 정의 메트릭과 유사하다.
 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
-위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고, `Object` 대신에 `External` 메트릭 타입을 사용한다.
+위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고,
+`Object` 대신에 `External` 메트릭 타입을 사용한다.
 만일 여러개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
-외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고, `Object` 타입을 사용할 때와 똑같이 동작한다.
-예를 들면 애플리케이션이 호스팅 된 대기열 서비스에서 작업을 처리하는 경우, 다음과 같이 HorizontalPodAutoscaler 매니퍼스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다.
+외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고,
+`Object` 타입을 사용할 때와 똑같이 동작한다.
+
+예를 들면 애플리케이션이 호스팅 된 대기열 서비스에서 작업을 처리하는 경우,
+다음과 같이 HorizontalPodAutoscaler 매니퍼스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다.

 ```yaml
 - type: External
@@ -341,13 +400,19 @@ object:
      averageValue: 30
 ```

-가능하다면, 외부 메트릭 대신 사용자 정의 메트릭 대상 타입을 사용하길 권장한다. 왜냐하면, 클러스터 관리자가 사용자 정의 메트릭 API를 보안관점에서 더 쉽게 보호할 수 있기 때문이다. 외부 메트릭 API는 잠재적으로 어떠한 메트릭에도 접근할 수 있기에, 클러스터 관리자는 API를 노출시킬때 신중해야 한다.
+가능하다면, 외부 메트릭 대신 사용자 정의 메트릭 대상 타입을 사용하길 권장한다.
+왜냐하면, 클러스터 관리자가 사용자 정의 메트릭 API를 보안관점에서 더 쉽게 보호할 수 있기 때문이다.
+외부 메트릭 API는 잠재적으로 어떠한 메트릭에도 접근할 수 있기에, 클러스터 관리자는 API를 노출시킬때 신중해야 한다.

 ## 부록: Horizontal Pod Autoscaler 상태 조건

-HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다. 이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지, 어떤 방식으로든 제한되어 있는지 여부를 나타낸다.
+HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면,
+HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다.
+이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지,
+어떤 방식으로든 제한되어 있는지 여부를 나타낸다.

-이 조건은 `status.conditions`에 나타난다. HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl describe hpa`를 사용할 수 있다.
+이 조건은 `status.conditions`에 나타난다.
+HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl describe hpa`를 사용할 수 있다.

 ```shell
 kubectl describe hpa cm-test
@@ -373,17 +438,32 @@ Conditions:
 Events:
 ```

-이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다. 첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지, 백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. 두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지), 원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, 일반적으로 메트릭을 가져오는데 문제가 있다. 마지막으로, 마지막 조건인 `ScalingLimited`는 원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다. 이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다.
+이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다.
+첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지,
+백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
+두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지),
+원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우,
+일반적으로 메트릭을 가져오는데 문제가 있다.
+마지막으로, 마지막 조건인 `ScalingLimited`는
+원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다.
+이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다.

 ## 부록: 수량

-HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다. 예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다. 메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며, 일반적으로 수량을 밀리단위로 반환한다. 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. 더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다.
+HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
+쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다.
+예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다.
+메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며,
+일반적으로 수량을 밀리단위로 반환한다.
+10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다.
+더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다.

 ## 부록: 다른 가능한 시나리오

 ### 명시적으로 오토스케일러 만들기

-HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고 명시적으로 다음 파일을 사용하여 만들 수 있다.
+HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고,
+명시적으로 다음 파일을 사용하여 만들 수 있다.

 {{< codenew file="application/hpa/php-apache.yaml" >}}

@@ -15,12 +15,10 @@ card:

 {{% capture prerequisites %}}

-컴퓨터의 바이오스(BIOS)에서 VT-x 또는 AMD-v 가상화는 필수적으로 활성화되어 있어야 한다.
-
 {{< tabs name="minikube_before_you_begin" >}}
 {{% tab name="리눅스" %}}
 리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다.
-```
+```shell
 egrep --color 'vmx|svm' /proc/cpuinfo
 ```
 {{% /tab %}}
@@ -44,6 +42,12 @@ Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
                          Data Execution Prevention Available: Yes
 ```

+다음의 출력을 확인할 수 있다면, 이미 하이퍼바이저가 설치되어 있는 것으로 다음 단계를 건너 뛸 수 있다.
+```
+Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.
+```
+
+
 {{% /tab %}}
 {{< /tabs >}}

@@ -51,87 +55,125 @@ Hyper-V Requirements:     VM Monitor Mode Extensions: Yes

 {{% capture steps %}}

-## 하이퍼바이저(hypervisor) 설치 {#install-a-hypervisor}
+# minikube 설치하기
+
+{{< tabs name="tab_with_md" >}}
+{{% tab name="리눅스" %}}
+
+### kubectl 설치
+
+kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)의 요령을 따라서 설치할 수 있다.
+
+## 하이퍼바이저(hypervisor) 설치

 하이퍼바이저를 설치하지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다.

-운영체제 | 지원하는 하이퍼바이저
-:----------------|:---------------------
-맥OS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit)
-리눅스 | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/)
-윈도우 | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
+• [KVM](https://www.linux-kvm.org/), 또한 QEMU를 사용한다
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)

 {{< note >}}
-Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 Docker와 리눅스 환경을 필요로 한다.
+Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경을 필요로 한다.
 {{< /note >}}

-## kubectl 설치
+### 패키지를 이용하여 Minikube 설치

-* [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/) 지침에 따라 kubectl을 설치한다.
+Minikube를 위한 *실험적인* 패키지가 있다.
+리눅스 (AMD64) 패키지는 GitHub의 Minikube의 [릴리스](https://github.com/kubernetes/minikube/releases)에서 찾을 수 있다.

-## Minikube 설치 {#install-minikube}
+적절한 패키지를 설치하기 위해 리눅스 배포판의 패키지 도구를 사용한다.

-### 맥OS {#macos}
+### Minikube를 직접 다운로드하여 설치

-맥OS에 Minikube를 설치하는 가장 쉬운 방법은 [Homebrew](https://brew.sh)을 사용하는 것이다.
-
-```shell
-brew cask install minikube
-```
-
-정적 바이너리를 내려받아서 맥OS에 설치할 수도 있다.
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
-  && chmod +x minikube
-```
-
-Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다.
-
-```shell
-sudo mv minikube /usr/local/bin
-```
-
-### 리눅스 {#linux}
-
-{{< note >}}
-이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다.
-{{< /note >}}
-
-정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있다.
+패키지를 통해 설치하지 못하였다면,
+바이너리 자체를 다운로드 받고 사용할 수 있다.

 ```shell
 curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
  && chmod +x minikube
 ```

-Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다.
+Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.

 ```shell
-sudo cp minikube /usr/local/bin && rm minikube
+sudo install minikube /usr/local/bin
 ```

-### 윈도우 {#windows}
+{{% /tab %}}
+{{% tab name="맥OS" %}}
+### kubectl 설치
+
+kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)의 요령을 따라서 설치할 수 있다.
+
+### 하이퍼바이저(hypervisor) 설치
+
+하이퍼바이저를 설치하지 않았다면, 다음 중 하나를 지금 설치한다.
+
+• [HyperKit](https://github.com/moby/hyperkit)
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+• [VMware Fusion](https://www.vmware.com/products/fusion)
+
+### Minikube 설치
+가장 쉽게 맥OS에 Minikube를 설치하는 방법은 [Homebrew](https://brew.sh)를 이용하는 것이다.
+
+```shell
+brew cask install minikube
+```
+
+실행 바이너리를 다운로드 받아서 맥OS에 설치할 수도 있다.
+
+```shell
+curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
+  && chmod +x minikube
+```
+
+Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.
+
+```shell
+sudo mv minikube /usr/local/bin
+```
+
+{{% /tab %}}
+{{% tab name="Windows" %}}
+### kubectl 설치하기
+
+kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)의 요령을 따라서 설치할 수 있다.
+
+### 하이퍼바이저(hypervisor) 설치하기
+
+하이퍼바이저가 설치 안 되어 있다면 아래중 하나를 지금 설치한다.
+
+• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)

 {{< note >}}
-Minikube를 윈도우에서 실행하려면, 먼저 [VirtualBox](https://www.virtualbox.org/) 또는 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치해야 한다. Hyper-V는 Windows 10 엔터프라이즈, Windows 10 프로페셔널, Windows 10 에듀케이션 세 버전의 Windows 10에서 동작한다. Minikube 공식 GitHub 레포지토리에 추가적인 [설치 방법](https://github.com/kubernetes/minikube/#installation)을 확인한다.
+Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows 10 Enterprise, Windows 10 Professional, Windows 10 Education.
 {{< /note >}}

-윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다. (관리자 권한으로 실행)
+### Chocolatey를 이용한 Minikube 설치
+
+윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행).

 ```shell
 choco install minikube kubernetes-cli
 ```

-Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube가 실행 경로에 자동으로 추가되어 있어야 한다.
+Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다.

-#### 윈도우 수동 설치 {#windows-manual-installation}
+### 인스톨러 실행파일을 통한 Minikube 설치

-윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다.
+윈도우에서 수동으로 [Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다.

-#### 윈도우 인스톨러 {#windows-installer}
+### 직접 다운로드하여 Minikube 설치
+
+윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 다운로드 받아서, 파일 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다.
+
+{{% /tab %}}
+{{< /tabs >}}

-[Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)으로 윈도우에서 Minikube를 수동으로 설치하려면 [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 인스톨러를 실행한다.

 {{% /capture %}}

@@ -155,5 +197,5 @@ machine does not exist

 구성 파일을 삭제해야 한다.
 ```shell
-rm -rf ~/.minikube
+minikube delete
 ```
@@ -177,7 +177,18 @@ k8s-apparmor-example-deny-write (enforce)
 먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 단순히
 파일 쓰기를 거부할 것이다.

-{{< code language="text" file="deny-write.profile" >}}
+```shell
+#include <tunables/global>
+
+profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
+  #include <abstractions/base>
+
+  file,
+
+  # Deny all file writes.
+  deny /** w,
+}
+```

 파드를 언제 스케줄할지 알지 못하므로 모든 노드에 프로파일을 적재해야 한다.
 이 예시에서는 SSH를 이용하여 프로파일을 설치할 것이나 다른 방법은
@@ -24,10 +24,10 @@ card:
        <p>이 튜토리얼에서는 쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 익힐 수 있는 가이드를 제공한다. 각각의 모듈에는 쿠버네티스의 주요 기능과 개념에 대한 배경 지식이 담겨 있으며 대화형 온라인 튜토리얼도 포함되어 있다. 대화형 튜토리얼에서 간단한 클러스터와 그 클러스터 상의 컨테이너화 된 애플리케이션을 직접 관리해볼 수 있다.</p>
        <p>대화형 튜토리얼을 사용해서 다음의 내용을 배울 수 있다.</p>
        <ul>
-        <li>컨테이너화된 애플리케이션을 클러스터에 배포하기</li>
-        <li>디플로이먼트를 스케일링하기</li>
-        <li>컨테이너화된 애플리케이션을 새로운 소프트웨어 버전으로 업데이트하기</li>
-        <li>컨테이너화된 애플리케이션을 디버그하기</li>
+        <li>컨테이너화된 애플리케이션을 클러스터에 배포하기.</li>
+        <li>디플로이먼트를 스케일링하기.</li>
+        <li>컨테이너화된 애플리케이션을 새로운 소프트웨어 버전으로 업데이트하기.</li>
+        <li>컨테이너화된 애플리케이션을 디버그하기.</li>
        </ul>
        <p>이 튜토리얼에서는 Katacoda를 사용해서 독자의 웹브라우저에서 Minikube가 동작하는 가상 터미널을 구동시킨다. Minikube는 로컬에 설치할 수 있는 작은 규모의 쿠버네티스로써 어디에서든 작동된다. 어떤 소프트웨어도 설치할 필요가 없고, 아무 것도 설정할 필요가 없다. 왜냐하면 대화형 튜토리얼이 웹브라우저 자체에서 바로 동작하기 때문이다.</p>
      </div>
@@ -104,12 +104,6 @@ card:
      </div>
    </div>

-    <div class="row">
-      <div class="col-md-12">
-        <a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button">튜토리얼 시작하기<span class="btn__next">›</span></a>
-      </div>
-    </div>
-
  </main>

 </div>
@@ -17,33 +17,31 @@ content_template: templates/concept

 * [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)

-* [Certified Kubernetes Administrator Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
+* [Certified Kubernetes Administrator Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)

 * [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)

-* [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
+* [Certified Kubernetes Application Developer Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)

-* [Google Kubernetes Engine 시작하기 (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
+* [Getting Started with Google Kubernetes Engine (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)

-* [Google Kubernetes Engine Deep Dive (Linux Academy)](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
+* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)

-* [쿠버네티스 시작하기 (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
+* [Getting Started with Kubernetes Clusters on OCI Oracle Kubernetes Engine (OKE) (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)

-* [OCI Oracle Kubernetes Engine (OKE)에서 쿠버네티스 클러스터 시작하기 (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
-
-* [쿠버네티스 소개 및 실습 (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
-
-* [IBM 클라우드: 쿠버네티스로 마이크로서비스(Microservices) 배포 (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
-
-* [쿠버네티스 소개 (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
-
-* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
+* [Google Kubernetes Engine Deep Dive (Linux Academy)] (https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)

 * [Helm Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)

-* [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
+* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)

-* [Kubernetes Quick Start (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
+* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
+
+* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
+
+* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
+
+* [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)

 * [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)

@@ -55,7 +53,7 @@ content_template: templates/concept

 * [Learn Kubernetes by Doing - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)

-* [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
+* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/)

 * [Microservice Applications in Kubernetes - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)

@@ -63,9 +61,7 @@ content_template: templates/concept

 * [Service Mesh with Istio with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)

-* [Prometheus로 쿠버네티스 모니터링 (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
-
-* [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
+* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)

 * [Self-paced Kubernetes online course (Learnk8s Academy)](https://learnk8s.io/academy)
 {{% /capture %}}
@@ -34,7 +34,10 @@ content_template: templates/tutorial
 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.

 ```console
-$ kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
+kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
+```
+출력은 다음과 같다.
+```
 deployment.apps/source-ip-app created
 ```

@@ -59,23 +62,38 @@ deployment.apps/source-ip-app created
 Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다.

 ```console
-$ kubectl get nodes
+kubectl get nodes
+```
+출력은 다음과 유사하다
+```
 NAME                           STATUS     ROLES    AGE     VERSION
 kubernetes-minion-group-6jst   Ready      <none>   2h      v1.13.0
 kubernetes-minion-group-cx31   Ready      <none>   2h      v1.13.0
 kubernetes-minion-group-jj1t   Ready      <none>   2h      v1.13.0
-
+```
+한 노드의 프록시 모드를 확인한다.
+```console
 kubernetes-minion-group-6jst $ curl localhost:10249/proxyMode
+```
+출력은 다음과 같다.
+```
 iptables
 ```

 소스 IP 애플리케이션을 통해 서비스를 생성하여 소스 IP 주소 보존 여부를 테스트할 수 있다.

 ```console
-$ kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
+kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
+```
+출력은 다음과 같다.
+```
 service/clusterip exposed
-
-$ kubectl get svc clusterip
+```
+```console
+kubectl get svc clusterip
+```
+출력은 다음과 같다.
+```
 NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
 clusterip    ClusterIP   10.0.170.92   <none>        80/TCP    51s
 ```
@@ -83,7 +101,10 @@ clusterip    ClusterIP   10.0.170.92   <none>        80/TCP    51s
 그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면:

 ```console
-$ kubectl run busybox -it --image=busybox --restart=Never --rm
+kubectl run busybox -it --image=busybox --restart=Never --rm
+```
+The output is similar to this:
+```
 Waiting for pod default/busybox to be running, status is Pending, pod ready: false
 If you don't see a command prompt, try pressing enter.

@@ -115,11 +136,16 @@ client_address는 클라이언트 파드와 서버 파드가 같은 노드 또
 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.

 ```console
-$ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
+kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
+```
+출력은 다음과 같다.
+```
 service/nodeport exposed
+```

-$ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
-$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }')
+```console
+NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
+NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
 ```

 클라우드 공급자 상에서 실행한다면,
@@ -128,7 +154,10 @@ $ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=
 서비스에 도달할 수 있다.

 ```console
-$ for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
+for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
+```
+출력은 다음과 같다.
+```
 client_address=10.180.1.1
 client_address=10.240.0.5
 client_address=10.240.0.3
@@ -170,14 +199,20 @@ client_address=10.240.0.3
 다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자.

 ```console
-$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
+kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
+```
+출력은 다음과 같다.
+```
 service/nodeport patched
 ```

 이제 다시 테스트를 실행해보자.

 ```console
-$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
+for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
+```
+출력은 다음과 같다.
+```
 client_address=104.132.1.79
 ```

@@ -191,7 +226,6 @@ client_address=104.132.1.79
 * 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다.
 * node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다.

-
 시각적으로

 ```
@@ -220,14 +254,28 @@ client_address=104.132.1.79
 로드밸런서를 통해 source-ip-app을 노출하여 테스트할 수 있다.

 ```console
-$ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
+kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
+```
+다음과 같이 출력된다.
+```
 service/loadbalancer exposed
+```

-$ kubectl get svc loadbalancer
+서비스의 IP를 출력한다.
+```console
+kubectl get svc loadbalancer
+```
+다음과 같이 출력된다.
+```
 NAME           TYPE           CLUSTER-IP    EXTERNAL-IP       PORT(S)   AGE
 loadbalancer   LoadBalancer   10.0.65.118   104.198.149.140   80/TCP    5m
+```

-$ curl 104.198.149.140
+```console
+curl 104.198.149.140
+```
+다음과 같이 출력된다.
+```
 CLIENT VALUES:
 client_address=10.240.0.5
 ...
@@ -255,29 +303,44 @@ health check --->   node 1   node 2 <--- health check
 이것은 어노테이션을 설정하여 테스트할 수 있다.

 ```console
-$ kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
+kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
 ```

 쿠버네티스에 의해 `service.spec.healthCheckNodePort` 필드가
 즉각적으로 할당되는 것을 봐야 한다.

 ```console
-$ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
+kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
+```
+다음과 같이 출력된다.
+```
  healthCheckNodePort: 32122
 ```

 `service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는
 모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.

+```console
+kubectl get pod -o wide -l run=source-ip-app
+```
+다음과 같이 출력된다.
 ```
-$ kubectl get pod -o wide -l run=source-ip-app
 NAME                            READY     STATUS    RESTARTS   AGE       IP             NODE
 source-ip-app-826191075-qehz4   1/1       Running   0          20h       10.180.1.136   kubernetes-minion-group-6jst
-
+```
+다른 노드에서`/healthz` 엔드포인트로 curl 명령을 수행한다.
+```console
 kubernetes-minion-group-6jst $ curl localhost:32122/healthz
+```
+다음과 같이 출력된다.
+```
 1 Service Endpoints found
-
+```
+```console
 kubernetes-minion-group-jj1t $ curl localhost:32122/healthz
+```
+다음과 같이 출력된다.
+```
 No Service Endpoints Found
 ```

@@ -287,7 +350,10 @@ No Service Endpoints Found
 로드밸런서 IP 주소로 curl 하자.

 ```console
-$ curl 104.198.149.140
+curl 104.198.149.140
+```
+다음과 같이 출력된다.
+```
 CLIENT VALUES:
 client_address=104.132.1.79
 ...
@@ -323,13 +389,13 @@ HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 헤더나
 서비스를 삭제하자.

 ```console
-$ kubectl delete svc -l run=source-ip-app
+kubectl delete svc -l run=source-ip-app
 ```

 디플로이먼트와 리플리카 셋과 파드를 삭제하자.

 ```console
-$ kubectl delete deployment source-ip-app
+kubectl delete deployment source-ip-app
 ```

 {{% /capture %}}
@@ -0,0 +1,3 @@
+---
+headless: true
+---
@@ -1,153 +1,89 @@
 ---
 title: "生产级别的容器编排系统"
 abstract: "自动化的容器部署、扩展和管理"
-cid: "home"
+cid: home
 ---

-<section id="oceanNodes">
-    <main>
-        <div class="image-wrapper"><img src="https://d33wubrfki0l68.cloudfront.net/1567471e7c58dc9b7d9c65dcd54e60cbf5870daa/da576/_common-resources/images/flower.png" alt="images/flower.png"></div>
-        <div class="content">
-            
-            <h3><a href="/docs/concepts/overview/what-is-kubernetes/">Kubernetes</a> 是用于自动部署，扩展和管理容器化应用程序的开源系统。</h3>
-            <p>它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现，Kubernetes 构建在 <a href="http://queue.acm.org/detail.cfm?id=2898444"> Google 15 年生产环境经验</a>基础之上,并结合来自社区的最佳创意和实践。</p>
-        </div>
-    </main>
-    <main>
-        <div class="image-wrapper"><img src="https://d33wubrfki0l68.cloudfront.net/33a12d8be0bc50be4738443101616e968c7afb8f/2c641/_common-resources/images/scalable.png" alt="images/scalable.png"></div>
-        <div class="content">
-            
-            <h4>全球规模</h4>
-            <p>基于允许 Google 每周运行数十亿个容器的原则进行设计，Kubernetes 可以在不增加您的运维团队的情况下进行弹性扩展。</p>
-        </div>
-    </main>
-    <main>
-        <div class="image-wrapper"><img src="https://d33wubrfki0l68.cloudfront.net/dbc75a944a909b2d52bf24ad06d485eca12af892/4fb42/_common-resources/images/blocks.png" alt="images/blocks.png"></div>
-        <div class="content">
-            
-            <h4>永不过时</h4>
-            <p>无论您应用运行在本地还是运行于全球任何地域，Kubernetes 的灵活性都可以随着您的需求复杂度不断增加，还可以持续、轻松地对外提供服务。</p>
-        </div>
-    </main>
-    <main>
-        <div class="image-wrapper"><img src="https://d33wubrfki0l68.cloudfront.net/bc2e475ac5fee0199eb3f4a0879cd559e8929f3a/4a628/_common-resources/images/suitcase.png" alt="images/suitcase.png"></div>
-        <div class="content">
-            
-            <h4>随处运行</h4>
-            <p>Kubernetes 是开源的，可以让您自由地部署在企业内部，私有云、混合云或公有云基础架构，使您轻松将应用迁移至任何位置。</p>
-        </div>
-    </main>
-</section>
-<section id="video">
-    <div class="light-text">
-        
-        <h2>Kubernetes: 最后&hellip; 它是真正的云平台</h2>
-        <p>Box 的联合创始人和服务架构师 Sam Ghods 发表了热情洋溢的演讲，随着使用 Kubernetes，我们首次有一个通用接口，可以建立真正的部署工具。</p>
-        <button id="desktopShowVideoButton" onclick="kub.showVideo()">观看视频</button>
-    </div>
-    <button id="mobileShowVideoButton" onclick="kub.showVideo()"></button>
-</section>
-<section id="features">
-    <main>
-        
-        <h3 class="center">Kubernetes 特性</h3>
-        <div class="feature-box">
-            <div>
-                
-                <h4><a href="/docs/concepts/configuration/manage-compute-resources-container/">自动包装</a></h4>
-                <p>根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，混合关键和最大努力的工作负载，以提高资源利用率并节省更多资源。</p>
-            </div>
-            <div>
-                
-                <h4><a href="/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller">自我修复</a></h4>
-                <p>重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。</p>
-            </div>
-        </div>
-        <div class="feature-box">
-            <div>
-                
-                <h4><a href="/docs/tasks/run-application/horizontal-pod-autoscale/">横向缩放</a></h4>
-                <p>使用简单的命令或 UI，或者根据 CPU 的使用情况自动调整应用程序副本数。</p>
-            </div>
-            <div>
-                
-                <h4><a href="/docs/concepts/services-networking/service/">服务发现和负载均衡</a></h4>
-                <p>不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。</p>
-            </div>
-        </div>
-        <div class="feature-box">
-            <div>
-                
-                <h4><a href="/docs/concepts/workloads/controllers/deployment/#what-is-a-deployment">自动部署和回滚</a></h4>
-                <p>Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。 如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。</p>
-            </div>
-            <div>
-                <h4><a href="/docs/concepts/configuration/secret/">密钥</a> 和 <a href="/docs/tasks/configure-pod-container/configure-pod-configmap/">配置</a> 管理</h4>
-                <p>部署和更新密钥和应用程序配置，不会重新编译您的镜像，不会在堆栈配置中暴露密钥(secrets)。</p>
-            </div>
-        </div>
-        <div class="feature-box">
-            <div>
-                <h4><a href="/docs/concepts/storage/persistent-volumes/">存储编排</a></h4>
-                <p>自动安装您所选择的存储系统，无论是本地存储，如公有云提供商 <a href="https://cloud.google.com/storage/">GCP</a> 或 <a href="https://aws.amazon.com/products/storage/">AWS</a>, 还是网络存储系统 NFS, iSCSI,
-            Gluster, Ceph, Cinder, 或 Flocker。</p>
-        </div>
-        <div>
-            <h4><a href="/docs/concepts/workloads/controllers/jobs-run-to-completion/">批处理</a></h4>
-            <p>除了服务之外，Kubernetes还可以管理您的批处理和 CI 工作负载，如果需要，替换出现故障的容器。</p>
-        </div>
-    </div>
-</main>
-</section>
-<section id="talkToUs">
-<main>
-    
-    <h3>实例探究</h3>
-    <div id="caseStudiesWrapper">
-        <div>
-            <p>使用Kubernetes来重塑世界上最大的教育公司</p>
-            <a href="/case-studies/pearson/">阅读更多</a>
-        </div>
-        <div>
-            <p>Kubernetes at Box: 微服务的最大优势</p>
-            <a href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/">阅读更多</a>
-        </div>
-        <div>
-            <p>在 eBay 内部转移到 OpenStack 上的 Kubernetes 和容器</p>
-            <a href="https://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">阅读更多</a>
-        </div>
-        <div>
-            <p>将本地的集群迁移至 Kubernetes</p>
-            <a href="https://www.youtube.com/watch?v=6XGUTu3WhBw">观看视频</a>
-        </div>
-    </div>
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    <h5 style="text-align: center"><a href="/case-studies/" style="color: #3371E3; font-weight: 400">探究所有的案例</a></h5>
-</main>
-</section>
-<div id="videoPlayer">
-<iframe data-url="https://www.youtube.com/embed/of45hYbkIZs?autoplay=1" frameborder="0" allowfullscreen></iframe>
-<button id="closeButton"></button>
+{{< deprecationwarning >}}
+
+{{< blocks/section id="oceanNodes" >}}
+{{% blocks/feature image="flower" %}}
+
+<!-- ### [Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications. -->
+### [Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) 是用于自动部署，扩展和管理容器化应用程序的开源系统。
+
+<!-- It groups containers that make up an application into logical units for easy management and discovery.
+Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444),
+combined with best-of-breed ideas and practices from the community. -->
+
+它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 源自[Google 15 年生产环境的运维经验](http://queue.acm.org/detail.cfm?id=2898444)，同时凝聚了社区的最佳创意和实践。
+
+{{% /blocks/feature %}}
+
+{{% blocks/feature image="scalable" %}}
+
+<!-- #### Planet Scale -->
+#### 星际尺度
+
+<!-- Designed on the same principles that allows Google to run billions of containers a week,
+Kubernetes can scale without increasing your ops team. -->
+
+Google 每周运行数十亿个容器，Kubernetes 基于与之相同的原则来设计，能够在不扩张运维团队的情况下进行规模扩展。
+
+{{% /blocks/feature %}}
+
+{{% blocks/feature image="blocks" %}}
+
+<!-- #### Never Outgrow -->
+#### 处处适用
+
+<!-- Whether testing locally or running a global enterprise, Kubernetes flexibility grows with you to deliver your applications
+consistently and easily no matter how complex your need is. -->
+
+无论是本地测试，还是跨国公司，Kubernetes 的灵活性都能让你在应对复杂系统时得心应手。
+
+{{% /blocks/feature %}}
+
+{{% blocks/feature image="suitcase" %}}
+
+<!-- #### Run Anywhere -->
+#### 永不过时
+
+<!-- Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid,
+or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you. -->
+
+Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、混合云或公有云，让您轻松地做出合适的选择。
+
+{{% /blocks/feature %}}
+
+{{< /blocks/section >}}
+
+{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}
+
+<div class="light-text">
+    <!-- <h2>The Challenges of Migrating 150+ Microservices to Kubernetes</h2> -->
+    <h2>将 150+ 微服务迁移到 Kubernetes 上的挑战</h2>
+    <!-- <p>By Sarah Wells, Technical Director for Operations and Reliability, Financial Times</p> -->
+    <p>Sarah Wells, 运营和可靠性技术总监, 金融时报</p>
+    <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
+    <br>
+    <br>
+    <br>
+    <!-- <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id="desktopKCButton">Attend KubeCon in Shanghai on Nov. 13-15, 2018</a> -->
+    <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id="desktopKCButton">参加11月13日到15日的上海 KubeCon</a>
+    <br>
+    <br>
+    <br>
+    <br>
+    <!-- <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/" button id="desktopKCButton">Attend KubeCon in Seattle on Dec. 11-13, 2018</a> -->
+    <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/" button id="desktopKCButton">参加12月11日到13日的西雅图 KubeCon</a>
 </div>
+<div id="videoPlayer">
+    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
+    <button id="closeButton"></button>
+</div>
+{{< /blocks/section >}}
+
+{{< blocks/kubernetes-features >}}
+
+{{< blocks/case-studies >}}
@@ -0,0 +1,27 @@
+---
+
+title: " Kubernetes 采集视频 "
+date: 2015-03-23
+slug: kubernetes-gathering-videos
+url: /blog/2015/03/Kubernetes-Gathering-Videos
+---
+
+<!--
+---
+
+title: " Kubernetes Gathering Videos "
+date: 2015-03-23
+slug: kubernetes-gathering-videos
+url: /blog/2015/03/Kubernetes-Gathering-Videos
+---
+-->
+
+<!--
+If you missed the Kubernetes Gathering in SF last month, fear not! Here are the videos from the evening presentations organized into a playlist on YouTube
+
+[![Kubernetes Gathering](https://img.youtube.com/vi/q8lGZCKktYo/0.jpg)](https://www.youtube.com/playlist?list=PL69nYSiGNLP2FBVvSLHpJE8_6hRHW8Kxe)
+-->
+
+如果你错过了上个月在旧金山举行的 Kubernetes 大会，不要害怕!以下是在 YouTube 上组织成播放列表的晚间演示文稿中的视频。
+
+[![Kubernetes Gathering](https://img.youtube.com/vi/q8lGZCKktYo/0.jpg)](https://www.youtube.com/playlist?list=PL69nYSiGNLP2FBVvSLHpJE8_6hRHW8Kxe)
@@ -0,0 +1,186 @@
+---
+title: " Kubernetes 社区每周聚会笔记 - 2015年3月27日 "
+date: 2015-03-28
+slug: weekly-kubernetes-community-hangout
+url: /blog/2015/03/Weekly-Kubernetes-Community-Hangout
+---
+
+<!--
+---
+title: " Weekly Kubernetes Community Hangout Notes - March 27 2015 "
+date: 2015-03-28
+slug: weekly-kubernetes-community-hangout
+url: /blog/2015/03/Weekly-Kubernetes-Community-Hangout
+---
+-->
+
+<!--
+Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
+-->
+每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
+
+<!--
+Agenda:
+-->
+日程安排：
+
+<!--
+
+\- Andy - demo remote execution and port forwarding
+
+\- Quinton - Cluster federation - Postponed
+
+\- Clayton - UI code sharing and collaboration around Kubernetes
+
+-->
+
+\- Andy - 演示远程执行和端口转发
+
+\- Quinton - 联邦集群 - 延迟
+
+\- Clayton - 围绕 Kubernetes 的 UI 代码共享和协作
+
+<!--
+Notes from meeting:
+-->
+从会议指出：
+
+<!--
+
+1\. Andy from RedHat:
+
+-->
+
+1\. Andy 从 RedHat：
+
+<!--
+
+* Demo remote execution
+
+-->
+
+* 演示远程执行
+
+<!--
+
+    * kubectl exec -p $POD -- $CMD
+
+    * Makes a connection to the master as proxy, figures out which node the pod is on, proxies connection to kubelet, which does the interesting bit.  via nsenter.
+
+    * Multiplexed streaming over HTTP using SPDY
+
+    * Also interactive mode:
+
+    * Assumes first container.  Can use -c $CONTAINER to pick a particular one.
+
+    * If have gdb pre-installed in container, then can interactively attach it to running process
+
+        * backtrace, symbol tbles, print, etc.  Most things you can do with gdb.
+
+    * Can also with careful flag crafting run rsync over this or set up sshd inside container.
+
+    * Some feedback via chat:
+    
+-->
+
+    * kubectl exec -p $POD -- $CMD
+
+    * 作为代理与主机建立连接，找出 pod 所在的节点，代理与 kubelet 的连接，这一点很有趣。通过 nsenter。
+
+    * 使用 SPDY 通过 HTTP 进行多路复用流式传输
+
+    * 还有互动模式：
+
+    * 假设第一个容器，可以使用 -c $CONTAINER 一个特定的。
+
+    * 如果在容器中预先安装了 gdb，则可以交互地将其附加到正在运行的进程中
+
+        * backtrace、symbol tbles、print 等。  使用gdb可以做的大多数事情。
+
+    * 也可以用精心制作的参数在上面运行 rsync 或者在容器内设置 sshd。
+
+    * 一些聊天反馈：
+
+<!--
+
+* Andy also demoed port forwarding
+* nsenter vs. docker exec
+
+-->
+
+* Andy 还演示了端口转发
+* nnsenter 与 docker exec
+
+<!--
+
+    * want to inject a binary under control of the host, similar to pre-start hooks
+
+    * socat, nsenter, whatever the pre-start hook needs
+    
+-->
+
+    * 想要在主机的控制下注入二进制文件，类似于预启动钩子
+
+    * socat、nsenter，任何预启动钩子需要的
+
+<!--
+
+* would be nice to blog post on this
+* version of nginx in wheezy is too old to support needed master-proxy functionality
+
+-->
+
+* 如果能在博客上发表这方面的文章就太好了
+* wheezy 中的 nginx 版本太旧，无法支持所需的主代理功能
+
+<!--
+
+2\. Clayton: where are we wrt a community organization for e.g. kubernetes UI components?
+
+* google-containers-ui IRC channel, mailing list.
+* Tim: google-containers prefix is historical, should just do "kubernetes-ui"
+* also want to put design resources in, and bower expects its own repo.
+* General agreement
+
+-->
+
+2\. Clayton: 我们的社区组织在哪里，例如 kubernetes UI 组件？
+
+* google-containers-ui IRC 频道，邮件列表。
+* Tim: google-containers 前缀是历史的，应该只做 "kubernetes-ui"
+* 也希望将设计资源投入使用，并且 bower 期望自己的仓库。
+* 通用协议
+
+<!--
+
+3\. Brian Grant:
+
+* Testing v1beta3, getting that ready to go in.
+* Paul working on changes to commandline stuff.
+* Early to mid next week, try to enable v1beta3 by default?
+* For any other changes, file issue and CC thockin.
+
+-->
+
+3\. Brian Grant:
+
+* 测试 v1beta3，准备进入。
+* Paul 力于改变命令行的内容。
+* 下周初至中旬，尝试默认启用v1beta3 ?
+* 对于任何其他更改，请发出文件并抄送 thockin。
+
+<!--
+
+4\. General consensus that 30 minutes is better than 60
+
+-->
+
+4\. 一般认为30分钟比60分钟好
+
+<!--
+
+* Shouldn't artificially try to extend just to fill time.
+
+-->
+
+* 不应该为了填满时间而人为地延长。
@@ -0,0 +1,62 @@
+---
+title: 欢迎来到 Kubernetes 博客!
+date: 2015-03-20
+slug: welcome-to-kubernetes-blog
+url: /blog/2015/03/Welcome-To-Kubernetes-Blog
+---
+
+<!--
+---
+title: Welcome to the Kubernetes Blog! 
+date: 2015-03-20
+slug: welcome-to-kubernetes-blog
+url: /blog/2015/03/Welcome-To-Kubernetes-Blog
+---
+-->
+
+<!--
+Welcome to the new Kubernetes Blog. Follow this blog to learn about the Kubernetes Open Source project. We plan to post release notes, how-to articles, events, and maybe even some off topic fun here from time to time.
+-->
+欢迎来到新的 Kubernetes 博客。关注此博客，了解 Kubernetes 开源项目。我们计划不时发布发布说明，操作方法文章，活动，甚至一些非常有趣的话题。
+
+<!--
+If you are using Kubernetes or contributing to the project and would like to do a guest post, [please let me know](mailto:kitm@google.com).
+-->
+如果您正在使用 Kubernetes 或为该项目做出贡献并想要发帖子，[请告诉我](mailto:kitm@google.com)。
+
+<!--
+To start things off, here's a roundup of recent Kubernetes posts from other sites:
+-->
+首先，以下是 Kubernetes 最近在其他网站上发布的文章摘要：
+
+<!--
+- [Scaling MySQL in the cloud with Vitess and Kubernetes](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html)
+- [Container Clusters on VMs](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html)
+- [Everything you wanted to know about Kubernetes but were afraid to ask](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html)
+- [What makes a container cluster?](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html)
+- [Integrating OpenStack and Kubernetes with Murano](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/)
+- [An introduction to containers, Kubernetes, and the trajectory of modern cloud computing](http://googlecloudplatform.blogspot.com/2015/01/in-coming-weeks-we-will-be-publishing.html)
+- [What is Kubernetes and how to use it?](http://www.centurylinklabs.com/what-is-kubernetes-and-how-to-use-it/)
+- [OpenShift V3, Docker and Kubernetes Strategy](https://blog.openshift.com/v3-docker-kubernetes-interview/)
+- [An Introduction to Kubernetes](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes)
+-->
+
+- [使用 Vitess 和 Kubernetes 在云中扩展 MySQL](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html)
+- [虚拟机上的容器群集](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html)
+- [想知道的关于 kubernetes 的一切，却又不敢问](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html)
+- [什么构成容器集群？](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html)
+- [将 OpenStack 和 Kubernetes 与 Murano 集成](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/)
+- [容器介绍，Kubernetes 以及现代云计算的发展轨迹](http://googlecloudplatform.blogspot.com/2015/01/in-coming-weeks-we-will-be-publishing.html)
+- [什么是 Kubernetes 以及如何使用它？](http://www.centurylinklabs.com/what-is-kubernetes-and-how-to-use-it/)
+- [OpenShift V3，Docker 和 Kubernetes 策略](https://blog.openshift.com/v3-docker-kubernetes-interview/)
+- [Kubernetes 简介](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes)
+
+<!--
+Happy cloud computing!
+-->
+快乐的云计算！
+
+<!--
+ - Kit Merker - Product Manager, Google Cloud Platform
+-->
+ - Kit Merker - Google 云平台产品经理
@@ -0,0 +1,176 @@
+---
+title: " Kubernetes Release: 0.15.0 "
+date: 2015-04-16
+slug: kubernetes-release-0150
+url: /blog/2015/04/Kubernetes-Release-0150
+---
+
+<!--
+Release Notes:
+-->
+
+Release 说明：
+
+<!--
+
+* Enables v1beta3 API and sets it to the default API version ([#6098][1])
+* Added multi-port Services ([#6182][2])
+    * New Getting Started Guides
+    * Multi-node local startup guide ([#6505][3])
+    * Mesos on Google Cloud Platform ([#5442][4])
+    * Ansible Setup instructions ([#6237][5])
+* Added a controller framework ([#5270][6], [#5473][7])
+* The Kubelet now listens on a secure HTTPS port ([#6380][8])
+* Made kubectl errors more user-friendly ([#6338][9])
+* The apiserver now supports client cert authentication ([#6190][10])
+* The apiserver now limits the number of concurrent requests it processes ([#6207][11])
+* Added rate limiting to pod deleting ([#6355][12])
+* Implement Balanced Resource Allocation algorithm as a PriorityFunction in scheduler package ([#6150][13])
+* Enabled log collection from master ([#6396][14])
+* Added an api endpoint to pull logs from Pods ([#6497][15])
+* Added latency metrics to scheduler ([#6368][16])
+* Added latency metrics to REST client ([#6409][17])
+
+-->
+
+* 启用 1beta3 API 并将其设置为默认 API 版本 ([#6098][1])
+* 增加了多端口服务([#6182][2])
+    * 新入门指南
+    * 多节点本地启动指南 ([#6505][3])
+    * Google 云平台上的 Mesos ([#5442][4])
+    * Ansible 安装说明 ([#6237][5])
+* 添加了一个控制器框架 ([#5270][6], [#5473][7])
+* Kubelet 现在监听一个安全的 HTTPS 端口 ([#6380][8])
+* 使 kubectl 错误更加友好 ([#6338][9])
+* apiserver 现在支持客户端 cert 身份验证 ([#6190][10])
+* apiserver 现在限制了它处理的并发请求的数量 ([#6207][11])
+* 添加速度限制删除 pod ([#6355][12])
+* 将平衡资源分配算法作为优先级函数实现在调度程序包中 ([#6150][13])
+* 从主服务器启用日志收集功能 ([#6396][14])
+* 添加了一个 api 端口来从 Pod 中提取日志 ([#6497][15])
+* 为调度程序添加了延迟指标 ([#6368][16])
+* 为 REST 客户端添加了延迟指标 ([#6409][17])
+
+<!--
+
+* etcd now runs in a pod on the master ([#6221][18])
+* nginx now runs in a container on the master ([#6334][19])
+* Began creating Docker images for master components ([#6326][20])
+* Updated GCE provider to work with gcloud 0.9.54 ([#6270][21])
+* Updated AWS provider to fix Region vs Zone semantics ([#6011][22])
+* Record event when image GC fails ([#6091][23])
+* Add a QPS limiter to the kubernetes client ([#6203][24])
+* Decrease the time it takes to run make release ([#6196][25])
+* New volume support
+    * Added iscsi volume plugin ([#5506][26])
+    * Added glusterfs volume plugin ([#6174][27])
+    * AWS EBS volume support ([#5138][28])
+* Updated to heapster version to v0.10.0 ([#6331][29])
+* Updated to etcd 2.0.9 ([#6544][30])
+* Updated to Kibana to v1.2 ([#6426][31])
+* Bug Fixes
+    * Kube-proxy now updates iptables rules if a service's public IPs change ([#6123][32])
+    * Retry kube-addons creation if the initial creation fails ([#6200][33])
+    * Make kube-proxy more resiliant to running out of file descriptors ([#6727][34])
+
+-->
+
+* etcd 现在在 master 上的一个 pod 中运行 ([#6221][18])
+* nginx 现在在 master上的容器中运行 ([#6334][19])
+* 开始为主组件构建 Docker 镜像 ([#6326][20])
+* 更新了 GCE 程序以使用 gcloud 0.9.54 ([#6270][21])
+* 更新了 AWS 程序来修复区域与区域语义 ([#6011][22])
+* 记录镜像 GC 失败时的事件 ([#6091][23])
+* 为 kubernetes 客户端添加 QPS 限制器 ([#6203][24])
+* 减少运行 make release 所需的时间 ([#6196][25])
+* 新卷的支持
+    * 添加 iscsi 卷插件 ([#5506][26])
+    * 添加 glusterfs 卷插件 ([#6174][27])
+    * AWS EBS 卷支持 ([#5138][28])
+* 更新到 heapster 版本到 v0.10.0 ([#6331][29])
+* 更新到 etcd 2.0.9 ([#6544][30])
+* 更新到 Kibana 到 v1.2 ([#6426][31])
+* 漏洞修复
+    * 如果服务的公共 IP 发生变化，Kube-proxy现在会更新iptables规则 ([#6123][32])
+    * 如果初始创建失败，则重试 kube-addons 创建 ([#6200][33])
+    * 使 kube-proxy 对耗尽文件描述符更具弹性 ([#6727][34])
+
+<!--
+To download, please visit https://github.com/GoogleCloudPlatform/kubernetes/releases/tag/v0.15.0
+-->
+要下载，请访问 https://github.com/GoogleCloudPlatform/kubernetes/releases/tag/v0.15.0
+
+<!--
+[1]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6098 "Enabling v1beta3 api version by default in master"
+[2]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6182 "Implement multi-port Services"
+[3]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6505 "Docker multi-node"
+[4]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5442 "Getting started guide for Mesos on Google Cloud Platform"
+[5]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6237 "example ansible setup repo"
+[6]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5270 "Controller framework"
+[7]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5473 "Add DeltaFIFO (a controller framework piece)"
+[8]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6380 "Configure the kubelet to use HTTPS (take 2)"
+[9]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6338 "Return a typed error for config validation, and make errors simple"
+[10]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6190 "Add client cert authentication"
+[11]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6207 "Add a limit to the number of in-flight requests that a server processes."
+[12]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6355 "Added rate limiting to pod deleting"
+[13]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6150 "Implement Balanced Resource Allocation (BRA) algorithm as a PriorityFunction in scheduler package."
+[14]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6396 "Enable log collection from master."
+[15]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6497 "Pod log subresource"
+[16]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6368 "Add basic latency metrics to scheduler."
+[17]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6409 "Add latency metrics to REST client"
+[18]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6221 "Run etcd 2.0.5 in a pod"
+[19]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6334 "Add an nginx docker image for use on the master."
+[20]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6326 "Create Docker images for master components "
+[21]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6270 "Updates for gcloud 0.9.54"
+-->
+[1]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6098 "在 master 中默认启用 v1beta3 api 版本"
+[2]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6182 "实现多端口服务"
+[3]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6505 "Docker 多节点"
+[4]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5442 "谷歌云平台上 Mesos 入门指南"
+[5]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6237 "示例 ansible 设置仓库"
+[6]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5270 "控制器框架"
+[7]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5473 "添加 DeltaFIFO（控制器框架块）"
+[8]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6380 "将 kubelet 配置为使用 HTTPS (获得 2)"
+[9]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6338 "返回用于配置验证的类型化错误，并简化错误"
+[10]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6190 "添加客户端证书认证"
+[11]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6207 "为服务器处理的正在运行的请求数量添加一个限制。"
+[12]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6355 "添加速度限制删除 pod"
+[13]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6150 "将均衡资源分配算法作为优先级函数实现在调度程序包中。"
+[14]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6396 "启用主服务器收集日志。"
+[15]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6497 "pod 子日志资源"
+[16]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6368 "将基本延迟指标添加到调度程序。"
+[17]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6409 "向 REST 客户端添加延迟指标"
+[18]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6221 "在 pod 中运行 etcd 2.0.5"
+[19]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6334 "添加一个 nginx docker 镜像用于主程序。"
+[20]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6326 "为主组件创建 Docker 镜像"
+[21]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6270 "gcloud 0.9.54 的更新"
+
+<!--
+[22]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6011 "Fix AWS region vs zone"
+[23]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6091 "Record event when image GC fails."
+[24]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6203 "Add a QPS limiter to the kubernetes client."
+[25]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6196 "Parallelize architectures in both the building and packaging phases of `make release`"
+[26]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5506 "add iscsi volume plugin"
+[27]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6174 "implement glusterfs volume plugin"
+[28]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5138 "AWS EBS volume support"
+[29]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6331 "Update heapster version to v0.10.0"
+[30]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6544 "Build etcd image (version 2.0.9), and upgrade kubernetes cluster to the new version"
+[31]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6426 "Update Kibana to v1.2 which paramaterizes location of Elasticsearch"
+[32]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6123 "Fix bug in kube-proxy of not updating iptables rules if a service's public IPs change"
+[33]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6200 "Retry kube-addons creation if kube-addons creation fails."
+[34]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6727 "pkg/proxy: panic if run out of fd"
+-->
+[22]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6011 "修复 AWS 区域 与 zone"
+[23]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6091 "记录镜像 GC 失败时的事件。"
+[24]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6203 "向 kubernetes 客户端添加 QPS 限制器。"
+[25]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6196 "在 `make release` 的构建和打包阶段并行化架构"
+[26]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5506 "添加 iscsi 卷插件"
+[27]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6174 "实现 glusterfs 卷插件"
+[28]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5138 "AWS EBS 卷支持"
+[29]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6331 "将 heapster 版本更新到 v0.10.0"
+[30]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6544 "构建 etcd 镜像(版本 2.0.9)，并将 kubernetes 集群升级到新版本"
+[31]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6426 "更新 Kibana 到 v1.2，它对 Elasticsearch 的位置进行了参数化"
+[32]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6123 "修复了 kube-proxy 中的一个错误，如果一个服务的公共 ip 发生变化，它不会更新 iptables 规则"
+[33]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6200 "如果 kube-addons 创建失败，请重试 kube-addons 创建。"
+[34]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6727 "pkg/proxy: fd 用完后引起恐慌"
+
@@ -0,0 +1,287 @@
+---
+title: " Kubernetes 社区每周聚会笔记- 2015年4月17日 "
+date: 2015-04-17
+slug: weekly-kubernetes-community-hangout_17
+url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_17
+---
+
+<!--
+---
+title: " Weekly Kubernetes Community Hangout Notes - April 17 2015 "
+date: 2015-04-17
+slug: weekly-kubernetes-community-hangout_17
+url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_17
+---
+-->
+
+<!--
+Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.  
+-->
+每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
+
+<!--
+Agenda  
+
+* Mesos Integration
+* High Availability (HA)
+* Adding performance and profiling details to e2e to track regressions
+* Versioned clients
+
+-->
+议程  
+
+* Mesos 集成
+* 高可用性（HA）
+* 向 e2e 添加性能和分析详细信息以跟踪回归
+* 客户端版本化
+
+<!--
+Notes  
+-->
+笔记
+
+<!--
+
+* Mesos integration
+
+    * Mesos integration proposal:
+
+    * No blockers to integration.
+
+    * Documentation needs to be updated.
+
+-->
+
+* Mesos 集成
+
+    * Mesos 集成提案：
+
+    * 没有阻塞集成的因素。
+
+    * 文档需要更新。
+
+<!--
+
+* HA
+
+    * Proposal should land today.
+
+    * Etcd cluster.
+
+    * Load-balance apiserver.
+
+    * Cold standby for controller manager and other master components.
+    
+-->
+
+* HA
+
+    * 提案今天应该会提交。
+
+    * Etcd 集群。
+
+    * apiserver 负载均衡。
+
+    * 控制器管理器和其他主组件的冷备用。
+
+<!--
+
+* Adding performance and profiling details to e2e to track regression
+
+    * Want red light for performance regression
+
+    * Need a public DB to post the data
+
+        * See
+
+    * Justin working on multi-platform e2e dashboard
+    
+-->
+
+* 向 e2e 添加性能和分析详细信息以跟踪回归
+
+    * 希望红色为性能回归
+
+    * 需要公共数据库才能发布数据
+
+        * 查看
+
+    * Justin 致力于多平台 e2e 仪表盘
+
+<!--
+
+* Versioned clients
+
+    *
+
+    *
+
+    * Client library currently uses internal API objects.
+
+    * Nobody reported that frequent changes to types.go have been painful, but we are worried about it.
+
+    * Structured types are useful in the client. Versioned structs would be ok.
+
+    * If start with json/yaml (kubectl), shouldn’t convert to structured types. Use swagger.
+    
+-->
+
+* 客户端版本化
+
+    *
+
+    *
+
+    * 客户端库当前使用内部 API 对象。
+
+    * 尽管没有人反映频繁修改 `types.go` 有多痛苦，但我们很为此担心。
+
+    * 结构化类型在客户端中很有用。版本化的结构就可以了。
+
+    * 如果从 json/yaml (kubectl) 开始，则不应转换为结构化类型。使用 swagger。
+
+<!--
+
+* Security context
+
+    *
+
+    * Administrators can restrict who can run privileged containers or require specific unix uids
+
+    * Kubelet will be able to get pull credentials from apiserver
+
+    * Policy proposal coming in the next week or so
+-->
+
+* Security context
+
+    *
+
+    * 管理员可以限制谁可以运行特权容器或需要特定的 unix uid
+
+    * kubelet 将能够从 apiserver 获取证书
+
+    * 政策提案将于下周左右出台
+
+<!--
+
+* Discussing upstreaming of users, etc. into Kubernetes, at least as optional
+* 1.0 Roadmap
+
+    * Focus is performance, stability, cluster upgrades
+
+    * TJ has been making some edits to [roadmap.md][4] but hasn’t sent out a PR yet
+* Kubernetes UI
+
+    * Dependencies broken out into third-party
+
+    * @lavalamp is reviewer
+
+-->
+
+* 讨论用户的上游，等等进入Kubernetes，至少是可选的
+* 1.0 路线图
+
+    * 重点是性能，稳定性，集群升级
+
+    * TJ 一直在对[roadmap.md][4]进行一些编辑，但尚未发布PR
+* Kubernetes UI
+
+    * 依赖关系分解为第三方
+
+    * @lavalamp 是评论家
+
+
+[1]: http://kubernetes.io/images/nav_logo.svg
+[2]: http://kubernetes.io/docs/
+[3]: https://kubernetes.io/blog/
+[4]: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/roadmap.md
+[5]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_17 "permanent link"
+[6]: https://resources.blogblog.com/img/icon18_edit_allbkg.gif
+[7]: https://www.blogger.com/post-edit.g?blogID=112706738355446097&postID=630924463010638300&from=pencil "Edit Post"
+[8]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=email "Email This"
+[9]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=blog "BlogThis!"
+[10]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=twitter "Share to Twitter"
+[11]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=facebook "Share to Facebook"
+[12]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=pinterest "Share to Pinterest"
+[13]: https://kubernetes.io/blog/search/label/community%20meetings
+[14]: https://kubernetes.io/blog/search/label/containers
+[15]: https://kubernetes.io/blog/search/label/docker
+[16]: https://kubernetes.io/blog/search/label/k8s
+[17]: https://kubernetes.io/blog/search/label/kubernetes
+[18]: https://kubernetes.io/blog/search/label/open%20source
+[19]: https://kubernetes.io/blog/2015/04/kubernetes-and-mesosphere-dcos "Newer Post"
+[20]: https://kubernetes.io/blog/2015/04/introducing-kubernetes-v1beta3 "Older Post"
+[21]: https://kubernetes.io/blog/feeds/630924463010638300/comments/default
+[22]: https://img2.blogblog.com/img/widgets/arrow_dropdown.gif
+[23]: https://img1.blogblog.com/img/icon_feed12.png
+[24]: https://img1.blogblog.com/img/widgets/subscribe-netvibes.png
+[25]: https://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2Fposts%2Fdefault
+[26]: https://img1.blogblog.com/img/widgets/subscribe-yahoo.png
+[27]: https://add.my.yahoo.com/content?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2Fposts%2Fdefault
+[28]: https://kubernetes.io/blog/feeds/posts/default
+[29]: https://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2F630924463010638300%2Fcomments%2Fdefault
+[30]: https://add.my.yahoo.com/content?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2F630924463010638300%2Fcomments%2Fdefault
+[31]: https://resources.blogblog.com/img/icon18_wrench_allbkg.png
+[32]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=Subscribe&widgetId=Subscribe1&action=editWidget§ionId=sidebar-right-1 "Edit"
+[33]: https://twitter.com/kubernetesio
+[34]: https://github.com/kubernetes/kubernetes
+[35]: http://slack.k8s.io/
+[36]: http://stackoverflow.com/questions/tagged/kubernetes
+[37]: http://get.k8s.io/
+[38]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=HTML&widgetId=HTML2&action=editWidget§ionId=sidebar-right-1 "Edit"
+[39]: javascript:void(0)
+[40]: https://kubernetes.io/blog/2018/
+[41]: https://kubernetes.io/blog/2018/01/
+[42]: https://kubernetes.io/blog/2017/
+[43]: https://kubernetes.io/blog/2017/12/
+[44]: https://kubernetes.io/blog/2017/11/
+[45]: https://kubernetes.io/blog/2017/10/
+[46]: https://kubernetes.io/blog/2017/09/
+[47]: https://kubernetes.io/blog/2017/08/
+[48]: https://kubernetes.io/blog/2017/07/
+[49]: https://kubernetes.io/blog/2017/06/
+[50]: https://kubernetes.io/blog/2017/05/
+[51]: https://kubernetes.io/blog/2017/04/
+[52]: https://kubernetes.io/blog/2017/03/
+[53]: https://kubernetes.io/blog/2017/02/
+[54]: https://kubernetes.io/blog/2017/01/
+[55]: https://kubernetes.io/blog/2016/
+[56]: https://kubernetes.io/blog/2016/12/
+[57]: https://kubernetes.io/blog/2016/11/
+[58]: https://kubernetes.io/blog/2016/10/
+[59]: https://kubernetes.io/blog/2016/09/
+[60]: https://kubernetes.io/blog/2016/08/
+[61]: https://kubernetes.io/blog/2016/07/
+[62]: https://kubernetes.io/blog/2016/06/
+[63]: https://kubernetes.io/blog/2016/05/
+[64]: https://kubernetes.io/blog/2016/04/
+[65]: https://kubernetes.io/blog/2016/03/
+[66]: https://kubernetes.io/blog/2016/02/
+[67]: https://kubernetes.io/blog/2016/01/
+[68]: https://kubernetes.io/blog/2015/
+[69]: https://kubernetes.io/blog/2015/12/
+[70]: https://kubernetes.io/blog/2015/11/
+[71]: https://kubernetes.io/blog/2015/10/
+[72]: https://kubernetes.io/blog/2015/09/
+[73]: https://kubernetes.io/blog/2015/08/
+[74]: https://kubernetes.io/blog/2015/07/
+[75]: https://kubernetes.io/blog/2015/06/
+[76]: https://kubernetes.io/blog/2015/05/
+[77]: https://kubernetes.io/blog/2015/04/
+[78]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_29
+[79]: https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes
+[80]: https://kubernetes.io/blog/2015/04/kubernetes-and-mesosphere-dcos
+[81]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_17
+[82]: https://kubernetes.io/blog/2015/04/introducing-kubernetes-v1beta3
+[83]: https://kubernetes.io/blog/2015/04/kubernetes-release-0150
+[84]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_11
+[85]: https://kubernetes.io/blog/2015/04/faster-than-speeding-latte
+[86]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout
+[87]: https://kubernetes.io/blog/2015/03/
+[88]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=BlogArchive&widgetId=BlogArchive1&action=editWidget§ionId=sidebar-right-1 "Edit"
+[89]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=HTML&widgetId=HTML1&action=editWidget§ionId=sidebar-right-1 "Edit"
+[90]: https://www.blogger.com
+[91]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=Attribution&widgetId=Attribution1&action=editWidget§ionId=footer-3 "Edit"
+
+  [*[3:27 PM]: 2015-04-17T15:27:00-07:00
@@ -0,0 +1,143 @@
+---
+title: " Kubernetes 社区每周聚会笔记- 2015年4月24日 "
+date: 2015-04-30
+slug: weekly-kubernetes-community-hangout_29
+url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_29
+---
+
+<!--
+---
+title: " Weekly Kubernetes Community Hangout Notes - April 24 2015 "
+date: 2015-04-30
+slug: weekly-kubernetes-community-hangout_29
+url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_29
+---
+
+-->
+
+<!--
+Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.  
+-->
+每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
+
+<!--
+Agenda:
+
+* Flocker and Kubernetes integration demo
+
+-->
+日程安排：
+
+* Flocker 和 Kubernetes 集成演示
+
+<!--
+Notes:
+
+* flocker and kubernetes integration demo
+* * Flocker Q/A
+
+    * Does the file still exists on node1 after migration?
+
+    * Brendan: Any plan this to make it a volume? So we don't need powerstrip?
+
+        * Luke:  Need to figure out interest to decide if we want to make it a first-class persistent disk provider in kube.
+
+        * Brendan: Removing need for powerstrip would make it simple to use. Totally go for it.
+
+        * Tim: Should take no more than 45 minutes to add it to kubernetes:)
+
+-->
+笔记：
+
+* flocker 和 kubernetes 集成演示
+* * Flocker Q/A
+
+    * 迁移后文件是否仍存在于node1上？
+
+    * Brendan: 有没有计划把它做成一本书？我们不需要 powerstrip？
+
+        * Luke:  需要找出感兴趣的来决定我们是否想让它成为 kube 中的一个一流的持久性磁盘提供商。
+
+        * Brendan: 删除对 powerstrip 的需求会使其易于使用。完全去做。
+
+        * Tim: 将它添加到 kubernetes 应该不超过45分钟:)
+
+<!--
+
+    * Derek: Contrast this with persistent volumes and claims?
+
+        * Luke: Not much difference, except for the novel ZFS based backend. Makes workloads really portable.
+
+        * Tim: very different than network-based volumes. Its interesting that it is the only offering that allows upgrading media.
+
+        * Brendan: claims, how does it look for replicated claims? eg Cassandra wants to have replicated data underneath. It would be efficient to scale up and down. Create storage on the fly based on load dynamically. Its step beyond taking snapshots - programmatically creating replicas with preallocation.
+
+        * Tim: helps with auto-provisioning.
+
+-->
+
+    * Derek: 持久卷和请求相比呢?
+
+        * Luke: 除了基于 ZFS 的新后端之外，差别不大。使工作负载真正可移植。
+
+        * Tim: 与基于网络的卷非常不同。有趣的是，它是唯一允许升级媒体的产品。
+
+        * Brendan: 请求，它如何查找重复请求？Cassandra 希望在底层复制数据。向上和向下扩缩是有效的。根据负载动态地创建存储。它的步骤不仅仅是快照——通过编程使用预分配创建副本。
+
+        * Tim: 帮助自动配置。
+        
+<!--
+
+    * Brian: Does flocker requires any other component?
+
+        * Kai: Flocker control service co-located with the master.  (dia on blog post). Powerstrip + Powerstrip Flocker. Very interested in mpersisting state in etcd. It keeps metadata about each volume.
+
+        * Brendan: In future, flocker can be a plugin and we'll take care of persistence. Post v1.0.
+
+        * Brian: Interested in adding generic plugin for services like flocker.
+
+        * Luke: Zfs can become really valuable when scaling to lot of containers on a single node.
+
+-->
+
+    * Brian: flocker 是否需要其他组件？
+
+        * Kai: Flocker 控制服务与主服务器位于同一位置。(dia 在博客上)。Powerstrip + Powerstrip Flocker。对在 etcd 中持久化状态非常有趣。它保存关于每个卷的元数据。
+
+        * Brendan: 在未来，flocker 可以是一个插件，我们将负责持久性。发布 v1.0。
+
+        * Brian: 有兴趣为 flocker 等服务添加通用插件。
+
+        * Luke: 当扩展到单个节点上的许多容器时，Zfs 会变得非常有价值。
+
+<!--
+
+    * Alex: Can flocker service can be run as a pod?
+
+        * Kai: Yes, only requirement is the flocker control service should be able to talk to zfs agent. zfs agent needs to be installed on the host and zfs binaries need to be accessible.
+
+        * Brendan: In theory, all zfs bits can be put it into a container with devices.
+
+        * Luke: Yes, still working through cross-container mounting issue.
+
+        * Tim: pmorie is working through it to make kubelet work in a container. Possible re-use.
+
+    * Kai: Cinder support is coming. Few days away.
+* Bob: What's the process of pushing kube to GKE? Need more visibility for confidence.
+
+-->
+
+    * Alex: flocker 服务可以作为 pod 运行吗？
+
+        * Kai: 是的，唯一的要求是 flocker 控制服务应该能够与 zfs 代理对话。需要在主机上安装 zfs 代理，并且需要访问 zfs 二进制文件。
+
+        * Brendan: 从理论上讲，所有 zfs 位都可以与设备一起放入容器中。
+
+        * Luke: 是的，仍然在处理跨容器安装问题。
+
+        * Tim: pmorie 正在通过它使 kubelet 在容器中工作。可能重复使用。
+
+    * Kai: Cinder 支持即将到来。几天之后。
+* Bob: 向 GKE 推送 kube 的过程是怎样的？需要更多的可见度。
+
+
@@ -0,0 +1,112 @@
+---
+title: " OpenStack 上的 Kubernetes "
+date: 2015-05-19
+slug: kubernetes-on-openstack
+url: /blog/2015/05/Kubernetes-On-Openstack
+---
+
+<!--
+---
+title: " Kubernetes on OpenStack "
+date: 2015-05-19
+slug: kubernetes-on-openstack
+url: /blog/2015/05/Kubernetes-On-Openstack
+---
+-->
+
+[![](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s400/Untitled%2Bdrawing.jpg)](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s1600/Untitled%2Bdrawing.jpg)
+
+
+<!--
+Today, the [OpenStack foundation](https://www.openstack.org/foundation/) made it even easier for you deploy and manage clusters of Docker containers on OpenStack clouds by including Kubernetes in its [Community App Catalog](http://apps.openstack.org/). &nbsp;At a keynote today at the OpenStack Summit in Vancouver, Mark Collier, COO of the OpenStack Foundation, and Craig Peters, &nbsp;[Mirantis](https://www.mirantis.com/) product line manager, demonstrated the Community App Catalog workflow by launching a Kubernetes cluster in a matter of seconds by leveraging the compute, storage, networking and identity systems already present in an OpenStack cloud.
+-->
+今天，[OpenStack 基金会](https://www.openstack.org/foundation/)通过在其[社区应用程序目录](http://apps.openstack.org/)中包含 Kubernetes，使您更容易在 OpenStack 云上部署和管理 Docker 容器集群。
+今天在温哥华 OpenStack 峰会上的主题演讲中，OpenStack 基金会的首席运营官：Mark Collier 和 [Mirantis](https://www.mirantis.com/) 产品线经理 Craig Peters 通过利用 OpenStack 云中已经存在的计算、存储、网络和标识系统，在几秒钟内启动了 Kubernetes 集群，展示了社区应用程序目录的工作流。
+
+<!--
+The entries in the catalog include not just the ability to [start a Kubernetes cluster](http://apps.openstack.org/#tab=murano-apps&asset=Kubernetes%20Cluster), but also a range of applications deployed in Docker containers managed by Kubernetes. These applications include:
+-->
+目录中的条目不仅包括[启动 Kubernetes 集群](http://apps.openstack.org/#tab=murano-apps&asset=Kubernetes%20Cluster)的功能，还包括部署在 Kubernetes 管理的 Docker 容器中的一系列应用程序。这些应用包括：
+
+<!--
+
+-
+Apache web server
+-
+Nginx web server
+-
+Crate - The Distributed Database for Docker
+-
+GlassFish - Java EE 7 Application Server
+-
+Tomcat - An open-source web server and servlet container
+-
+InfluxDB - An open-source, distributed, time series database
+-
+Grafana - Metrics dashboard for InfluxDB
+-
+Jenkins - An extensible open source continuous integration server
+-
+MariaDB database
+-
+MySql database
+-
+Redis - Key-value cache and store
+-
+PostgreSQL database
+-
+MongoDB NoSQL database
+-
+Zend Server - The Complete PHP Application Platform
+
+-->
+
+
+-
+Apache web 服务器
+-
+Nginx web 服务器
+-
+Crate - Docker的分布式数据库
+-
+GlassFish - Java EE 7 应用服务器
+-
+Tomcat - 一个开源的 web 服务器和 servlet 容器
+-
+InfluxDB - 一个开源的、分布式的、时间序列数据库
+-
+Grafana -   InfluxDB 的度量仪表板
+-
+Jenkins - 一个可扩展的开放源码持续集成服务器
+-
+MariaDB 数据库
+-
+MySql 数据库
+-
+Redis - 键-值缓存和存储
+-
+PostgreSQL 数据库
+-
+MongoDB NoSQL 数据库
+-
+Zend 服务器 - 完整的 PHP 应用程序平台
+
+<!--
+This list will grow, and is curated [here](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
+-->
+此列表将会增长，并在[此处](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes)进行策划。您可以检查（并参与）YAML 文件，该文件告诉 Murano 如何根据[此处](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml)定义来安装和启动 ...apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml)安装和启动 Kubernetes 集群。
+
+<!--
+[The Kubernetes open source project](https://github.com/GoogleCloudPlatform/kubernetes) has continued to see fantastic community adoption and increasing momentum, with over 11,000 commits and 7,648 stars on GitHub. With supporters ranging from Red Hat and Intel to CoreOS and Box.net, it has come to represent a range of customer interests ranging from enterprise IT to cutting edge startups. We encourage you to give it a try, give us your feedback, and get involved in our growing community.
+-->
+[Kubernetes 开源项目](https://github.com/GoogleCloudPlatform/kubernetes)继续受到社区的欢迎，并且势头越来越好，GitHub 上有超过 11000 个提交和 7648 颗星。从 Red Hat 和 Intel 到 CoreOS 和 Box.net，它已经代表了从企业 IT 到前沿创业企业的一系列客户。我们鼓励您尝试一下，给我们您的反馈，并参与到我们不断增长的社区中来。
+
+
+<!--
+
+- Martin Buhr, Product Manager, Kubernetes Open Source Project
+
+-->
+
+- Martin Buhr, Kubernetes 开源项目产品经理
+
@@ -0,0 +1,121 @@
+---
+title: " Kubernetes 社区每周聚会笔记- 2015年5月1日 "
+date: 2015-05-11
+slug: weekly-kubernetes-community-hangout
+url: /blog/2015/05/Weekly-Kubernetes-Community-Hangout
+---
+
+<!--
+---
+title: " Weekly Kubernetes Community Hangout Notes - May 1 2015 "
+date: 2015-05-11
+slug: weekly-kubernetes-community-hangout
+url: /blog/2015/05/Weekly-Kubernetes-Community-Hangout
+---
+-->
+
+<!--
+Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
+-->
+每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
+
+<!--
+
+* Simple rolling update - Brendan
+
+    * Rolling update = nice example of why RCs and Pods are good.
+
+    * ...pause… (Brendan needs demo recovery tips from Kelsey)
+
+    * Rolling update has recovery: Cancel update and restart, update continues from where it stopped.
+
+    * New controller  gets name of old controller, so appearance is pure update.
+
+    * Can also name versions in update (won't do rename at the end).
+
+-->  
+
+* 简单的滚动更新 - Brendan
+
+    * 滚动更新 = RCs和Pods很好的例子。
+
+    * ...pause… (Brendan 需要 Kelsey 的演示恢复技巧)
+
+    * 滚动更新具有恢复功能:取消更新并重新启动，更新从停止的地方继续。
+
+    * 新控制器获取旧控制器的名称，因此外观是纯粹的更新。
+
+    * 还可以在 update 中命名版本(最后不会重命名)。
+
+<!--
+
+* Rocket demo - CoreOS folks
+
+    * 2 major differences between rocket & docker: Rocket is daemonless & pod-centric.
+
+    * Rocket has AppContainer format as native, but also supports docker image format.
+
+    * Can run AppContainer and docker containers in same pod.
+
+    * Changes are close to merged.
+    
+-->
+
+* Rocket 演示 - CoreOS 的伙计们
+
+    * Rocket 和 docker 之间的主要区别: Rocket 是无守护进程和以 pod 为中心。。
+
+    * Rocket 具有原生的 AppContainer 格式，但也支持 docker 镜像格式。
+
+    * 可以在同一个 pod 中运行 AppContainer 和 docker 容器。
+
+    * 变更接近于合并。
+
+<!--
+
+* demo service accounts and secrets being added to pods - Jordan
+
+    * Problem: It's hard to get a token to talk to the API.
+
+    * New API object: "ServiceAccount"
+
+    * ServiceAccount is namespaced, controller makes sure that at least 1 default service account exists in a namespace.
+
+    * Typed secret "ServiceAccountToken", controller makes sure there is at least 1 default token.
+
+    * DEMO
+
+    *     * Can create new service account with ServiceAccountToken. Controller will create token for it.
+
+    * Can create a pod with service account, pods will have service account secret mounted at /var/run/secrets/kubernetes.io/…
+    
+-->
+
+* 演示 service accounts 和 secrets 被添加到 pod - Jordan
+
+    * 问题：很难获得与API通信的令牌。
+
+    * 新的API对象："ServiceAccount"
+
+    * ServiceAccount 是命名空间，控制器确保命名空间中至少存在一个个默认 service account。
+
+    * 键入 "ServiceAccountToken"，控制器确保至少有一个默认令牌。
+
+    * 演示
+
+    *     * 可以使用 ServiceAccountToken 创建新的 service account。控制器将为它创建令牌。
+
+    * 可以创建一个带有 service account 的 pod, pod 将在 /var/run/secrets/kubernets.io/…
+    
+<!--    
+    
+* Kubelet running in a container - Paul
+
+    * Kubelet successfully ran pod w/ mounted secret.
+
+-->
+    
+* Kubelet 在容器中运行 - Paul
+
+    * Kubelet 成功地运行了带有 secret 的 pod。
+    
@@ -0,0 +1,25 @@
+---
+title: "幻灯片：Kubernetes 集群管理，爱丁堡大学演讲"
+date: 2015-06-26
+slug: slides-cluster-management-with
+url: /blog/2015/06/Slides-Cluster-Management-With
+---
+
+<!--
+---
+title: " Slides: Cluster Management with Kubernetes, talk given at the University of Edinburgh "
+date: 2015-06-26
+slug: slides-cluster-management-with
+url: /blog/2015/06/Slides-Cluster-Management-With
+---
+-->
+
+<!--
+On Friday 5 June 2015 I gave a talk called [Cluster Management with Kubernetes](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000) to a general audience at the University of Edinburgh. The talk includes an example of a music store system with a Kibana front end UI and an Elasticsearch based back end which helps to make concrete concepts like pods, replication controllers and services.
+
+[Cluster Management with Kubernetes](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000).
+-->
+
+2015年6月5日星期五，我在爱丁堡大学给普通听众做了一个演讲，题目是[使用 Kubernetes 进行集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。这次演讲包括一个带有 Kibana 前端 UI 的音乐存储系统的例子，以及一个基于 Elasticsearch 的后端，该后端有助于生成具体的概念，如 pods、复制控制器和服务。
+
+[Kubernetes 集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。
@@ -0,0 +1,24 @@
+---
+title: "宣布首个Kubernetes企业培训课程 "
+date: 2015-07-08
+slug: announcing-first-kubernetes-enterprise
+url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise
+---
+<!-- ---
+title: " Announcing the First Kubernetes Enterprise Training Course "
+date: 2015-07-08
+slug: announcing-first-kubernetes-enterprise
+url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise
+--- -->
+
+<!-- At Google we rely on Linux application containers to run our core infrastructure. Everything from Search to Gmail runs in containers. &nbsp;In fact, we like containers so much that even our Google Compute Engine VMs run in containers! &nbsp;Because containers are critical to our business, we have been working with the community on many of the basic container technologies (from cgroups to Docker’s LibContainer) and even decided to build the next generation of Google’s container scheduling technology, Kubernetes, in the open. -->
+在谷歌，我们依赖 Linux 容器应用程序去运行我们的核心基础架构。所有服务，从搜索引擎到Gmail服务，都运行在容器中。事实上，我们非常喜欢容器，甚至我们的谷歌云计算引擎虚拟机也运行在容器上！由于容器对于我们的业务至关重要，我们已经与社区合作开发许多基本的容器技术（从 cgroups 到 Docker 的 LibContainer）,甚至决定去构建谷歌的下一代开源容器调度技术，Kubernetes。
+
+<!-- One year into the Kubernetes project, and on the eve of our planned V1 release at OSCON, we are pleased to announce the first-ever formal Kubernetes enterprise-focused training session organized by a key Kubernetes contributor, Mesosphere. The inaugural session will be taught by Zed Shaw and Michael Hausenblas from Mesosphere, and will take place on July 20 at OSCON in Portland. [Pre-registration](https://mesosphere.com/training/kubernetes/) is free for early registrants, but space is limited so act soon! -->
+在 Kubernetes 项目进行一年后，在 OSCON 上发布 V1 版本的前夕，我们很高兴的宣布Kubernetes 的主要贡献者 Mesosphere 组织了有史以来第一次正规的以企业为中心的 Kubernetes 培训会议。首届会议将于 6 月 20 日在波特兰的 OSCON 举办，由来自 Mesosphere 的 Zed Shaw 和 Michael Hausenblas 演讲。[Pre-registration](https://mesosphere.com/training/kubernetes/) 对于优先注册者是免费的，但名额有限，立刻行动吧！
+
+<!-- This one-day course will cover the basics of building and deploying containerized applications using Kubernetes. It will walk attendees through the end-to-end process of creating a Kubernetes application architecture, building and configuring Docker images, and deploying them on a Kubernetes cluster. Users will also learn the fundamentals of deploying Kubernetes applications and services on our Google Container Engine and Mesosphere’s Datacenter Operating System. -->
+这个为期一天的课程将包涵使用 Kubernetes 构建和部署容器化应用程序的基础知识。它将通过完整的流程引导与参会者创建一个 Kubernetes 的应用程序体系结构，创建和配置 Docker 镜像，并把它们部署到 Kubernetes 集群上。用户还将了解在我们的谷歌容器引擎和 Mesosphere 的数据中心操作系统上部署 Kubernetes 应用程序和服务的基础知识。
+
+<!-- The upcoming Kubernetes bootcamp will be a great way to learn how to apply Kubernetes to solve long-standing deployment and application management problems. &nbsp;This is just the first of what we hope are many, and from a broad set of contributors. -->
+即将推出的 Kubernetes bootcamp 将是学习如何应用 Kubernetes 解决长期部署和应用程序管理问题的一个好途径。相对于我们所预期的，来自于广泛社区的众多培训项目而言，这只是其中一个。
@@ -0,0 +1,164 @@
+---
+title: " 使用 Puppet 管理 Kubernetes Pods，Services 和 Replication Controllers "
+date: 2015-12-17
+slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet
+url: /blog/2015/12/Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet
+---
+
+<!--
+---
+title: " Managing Kubernetes Pods, Services and Replication Controllers with Puppet "
+date: 2015-12-17
+slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet
+url: /blog/2015/12/Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet
+---
+-->
+
+<!--
+_Today’s guest post is written by Gareth Rushgrove, Senior Software Engineer at Puppet Labs, a leader in IT automation. Gareth tells us about a new Puppet module that helps manage resources in Kubernetes.&nbsp;_  
+
+People familiar with [Puppet](https://github.com/puppetlabs/puppet)&nbsp;might have used it for managing files, packages and users on host computers. But Puppet is first and foremost a configuration management tool, and config management is a much broader discipline than just managing host-level resources. A good definition of configuration management is that it aims to solve four related problems: identification, control, status accounting and verification and audit. These problems exist in the operation of any complex system, and with the new [Puppet Kubernetes module](https://forge.puppetlabs.com/garethr/kubernetes)&nbsp;we’re starting to look at how we can solve those problems for Kubernetes.  
+-->
+
+_今天的嘉宾帖子是由 IT 自动化领域的领导者 Puppet Labs 的高级软件工程师 Gareth Rushgrove 撰写的。Gareth告诉我们一个新的 Puppet 模块，它帮助管理 Kubernetes 中的资源。_
+
+熟悉[Puppet]的人(https://github.com/puppetlabs/puppet)可能使用它来管理主机上的文件、包和用户。但是Puppet首先是一个配置管理工具，配置管理是一个比管理主机级资源更广泛的规程。配置管理的一个很好的定义是它旨在解决四个相关的问题：标识、控制、状态核算和验证审计。这些问题存在于任何复杂系统的操作中，并且有了新的[Puppet Kubernetes module](https://forge.puppetlabs.com/garethr/kubernetes)，我们开始研究如何为 Kubernetes 解决这些问题。
+
+<!--
+### The Puppet Kubernetes Module
+
+The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](http://kubernetes.io/gettingstarted/).&nbsp;Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.  
+-->
+
+### Puppet Kubernetes 模块
+
+Puppet kubernetes 模块目前假设您已经有一个 kubernetes 集群 [启动并运行]](http://kubernetes.io/gettingstarted/)。它的重点是管理 Kubernetes中的资源，如 Pods、Replication Controllers 和 Services，而不是（现在）管理底层的 kubelet 或 etcd services。下面是描述 Puppet’s DSL 中一个 Pod 的简短代码片段。
+
+<!--
+```
+kubernetes_pod { 'sample-pod':
+  ensure => present,
+  metadata => {
+    namespace => 'default',
+  },
+  spec => {
+    containers => [{
+      name => 'container-name',
+      image => 'nginx',
+    }]
+  },
+```
+}  
+-->
+
+```
+kubernetes_pod { 'sample-pod':
+  ensure => present,
+  metadata => {
+    namespace => 'default',
+  },
+  spec => {
+    containers => [{
+      name => 'container-name',
+      image => 'nginx',
+    }]
+  },
+}  
+```
+<!--
+If you’re familiar with the YAML file format, you’ll probably recognise the structure immediately. The interface is intentionally identical to aid conversion between different formats — in fact, the code powering this is autogenerated from the Kubernetes API Swagger definitions. Running the above code, assuming we save it as pod.pp, is as simple as:  
+
+
+```
+puppet apply pod.pp
+```
+-->
+
+如果您熟悉 YAML 文件格式，您可能会立即识别该结构。 该接口故意采取相同的格式以帮助在不同格式之间进行转换 — 事实上，为此提供支持的代码是从Kubernetes API Swagger自动生成的。 运行上面的代码，假设我们将其保存为 pod.pp，就像下面这样简单：
+
+
+```
+puppet apply pod.pp
+```
+
+<!--
+Authentication uses the standard kubectl configuration file. You can find complete [installation instructions in the module's README](https://github.com/garethr/garethr-kubernetes/blob/master/README.md).  
+
+Kubernetes has several resources, from Pods and Services to Replication Controllers and Service Accounts. You can see an example of the module managing these resources in the [Kubernetes guestbook sample in Puppet](https://puppetlabs.com/blog/kubernetes-guestbook-example-puppet)&nbsp;post. This demonstrates converting the canonical hello-world example to use Puppet code.  -->
+
+身份验证使用标准的 kubectl 配置文件。您可以在模块的自述文件中找到完整的[README](https://github.com/garethr/garethr-kubernetes/blob/master/README.md)。
+
+Kubernetes 有很多资源，来自 Pods、 Services、 Replication Controllers 和 Service Accounts。您可以在[Puppet 中的 kubernetes 留言簿示例](https://puppetlabs.com/blog/kubernetes-guestbook-example-puppet)文章中看到管理这些资源的模块示例。这演示了如何将规范的 hello-world 示例转换为使用 Puppet代码。
+
+<!--
+One of the main advantages of using Puppet for this, however, is that you can create your own higher-level and more business-specific interfaces to Kubernetes-managed applications. For instance, for the guestbook, you could create something like the following:  
+
+
+```
+guestbook { 'myguestbook':
+  redis_slave_replicas => 2,
+  frontend_replicas => 3,
+  redis_master_image => 'redis',
+  redis_slave_image => 'gcr.io/google_samples/gb-redisslave:v1',
+  frontend_image => 'gcr.io/google_samples/gb-frontend:v3',     
+}
+```
+-->
+
+然而，使用 Puppet 的一个主要优点是，您可以创建自己的更高级别和更特定于业务的接口，以连接 kubernetes 管理的应用程序。例如，对于留言簿，可以创建如下内容：
+
+```
+guestbook { 'myguestbook':
+  redis_slave_replicas => 2,
+  frontend_replicas => 3,
+  redis_master_image => 'redis',
+  redis_slave_image => 'gcr.io/google_samples/gb-redisslave:v1',
+  frontend_image => 'gcr.io/google_samples/gb-frontend:v3',     
+}
+```
+
+<!--
+You can read more about using Puppet’s defined types, and see lots more code examples, in the Puppet blog post, [Building Your Own Abstractions for Kubernetes in Puppet](https://puppetlabs.com/blog/building-your-own-abstractions-kubernetes-puppet).  
+
+
+### Conclusions
+
+The advantages of using Puppet rather than just the standard YAML files and kubectl are:  
+-->
+
+您可以在Puppet博客文章[在 Puppet 中为 Kubernetes 构建自己的抽象](https://puppetlabs.com/blog/building-your-own-abstractions-kubernetes-puppet)中阅读更多关于使用 Puppet 定义的类型的信息，并看到更多的代码示例。
+
+
+### 结论
+
+使用 Puppet 而不仅仅是使用标准的 YAML 文件和 kubectl 的优点是：
+
+<!--
+- The ability to create your own abstractions to cut down on repetition and craft higher-level user interfaces, like the guestbook example above.&nbsp;
+- Use of Puppet’s development tools for validating code and for writing unit tests.&nbsp;
+- Integration with other tools such as Puppet Server, for ensuring that your model in code matches the state of your cluster, and with PuppetDB for storing reports and tracking changes.
+- The ability to run the same code repeatedly against the Kubernetes API, to detect any changes or remediate configuration drift.&nbsp;
+-->
+
+- 能够创建自己的抽象，以减少重复和设计更高级别的用户界面，如上面的留言簿示例。
+- 使用 Puppet 的开发工具验证代码和编写单元测试。
+- 与 Puppet Server 等其他工具配合，以确保代码中的模型与集群的状态匹配，并与 PuppetDB 配合工作，以存储报告和跟踪更改。
+- 能够针对 Kubernetes API 重复运行相同的代码，以检测任何更改或修正配置。
+
+<!--
+It’s also worth noting that most large organisations will have very heterogenous environments, running a wide range of software and operating systems. Having a single toolchain that unifies those discrete systems can make adopting new technology like Kubernetes much easier.  
+-->
+
+值得注意的是，大多数大型组织都将拥有非常异构的环境，运行各种各样的软件和操作系统。拥有统一这些离散系统的单一工具链可以使采用 Kubernetes 等新技术变得更加容易。
+
+<!--
+It’s safe to say that Kubernetes provides an excellent set of primitives on which to build cloud-native systems. And with Puppet, you can address some of the operational and configuration management issues that come with running any complex system in production. [Let us know](mailto:gareth@puppetlabs.com)&nbsp;what you think if you try the module out, and what else you’d like to see supported in the future.  
+
+&nbsp;-&nbsp;Gareth Rushgrove, Senior Software Engineer, Puppet Labs
+-->
+
+可以肯定地说，Kubernetes提供了一组优秀的组件来构建云原生系统。使用 Puppet，您可以解决在生产中运行任何复杂系统所带来的一些操作和配置管理问题。[告诉我们](mailto:gareth@puppetlabs.com)如果您试用了该模块，您会有什么想法，以及您希望在将来看到哪些支持。
+
+
+Gareth Rushgrove，Puppet Labs 高级软件工程师
+
@@ -0,0 +1,303 @@
+<!--
+---
+title: " Simple leader election with Kubernetes and Docker "
+date: 2016-01-11
+slug: simple-leader-election-with-kubernetes
+url: /blog/2016/01/Simple-Leader-Election-With-Kubernetes
+---
+
+####  Overview
+-->
+
+title: "Kubernetes 和 Docker 简单的 leader election"
+date: 2016-01-11
+slug: simple-leader-election-with-kubernetes
+url: /blog/2016/01/Simple-Leader-Election-With-Kubernetes
+
+<!--
+Kubernetes simplifies the deployment and operational management of services running on clusters. However, it also simplifies the development of these services. In this post we'll see how you can use Kubernetes to easily perform leader election in your distributed application. Distributed applications usually replicate the tasks of a service for reliability and scalability, but often it is necessary to designate one of the replicas as the leader who is responsible for coordination among all of the replicas.
+-->
+
+Kubernetes 简化了集群上运行的服务的部署和操作管理。但是，它也简化了这些服务的发展。在本文中，我们将看到如何使用 Kubernetes 在分布式应用程序中轻松地执行 leader election。分布式应用程序通常为了可靠性和可伸缩性而复制服务的任务，但通常需要指定其中一个副本作为负责所有副本之间协调的负责人。
+
+<!--
+Typically in leader election, a set of candidates for becoming leader is identified. These candidates all race to declare themselves the leader. One of the candidates wins and becomes the leader. Once the election is won, the leader continually "heartbeats" to renew their position as the leader, and the other candidates periodically make new attempts to become the leader. This ensures that a new leader is identified quickly, if the current leader fails for some reason.
+-->
+
+通常在 leader election 中，会确定一组成为领导者的候选人。这些候选人都竞相宣布自己为领袖。其中一位候选人获胜并成为领袖。一旦选举获胜，领导者就会不断地“信号”以表示他们作为领导者的地位，其他候选人也会定期地做出新的尝试来成为领导者。这样可以确保在当前领导因某种原因失败时，快速确定新领导。
+
+<!--
+Implementing leader election usually requires either deploying software such as ZooKeeper, etcd or Consul and using it for consensus, or alternately, implementing a consensus algorithm on your own. We will see below that Kubernetes makes the process of using leader election in your application significantly easier.
+
+####  Implementing leader election in Kubernetes
+-->
+
+实现 leader election 通常需要部署 ZooKeeper、etcd 或 Consul 等软件并将其用于协商一致，或者也可以自己实现协商一致算法。我们将在下面看到，Kubernetes 使在应用程序中使用 leader election 的过程大大简化。
+
+####在 Kubernetes 实施领导人选举
+
+<!--
+The first requirement in leader election is the specification of the set of candidates for becoming the leader. Kubernetes already uses _Endpoints_ to represent a replicated set of pods that comprise a service, so we will re-use this same object. (aside: You might have thought that we would use _ReplicationControllers_, but they are tied to a specific binary, and generally you want to have a single leader even if you are in the process of performing a rolling update)
+
+To perform leader election, we use two properties of all Kubernetes API objects:
+-->
+
+Leader election 的首要条件是确定候选人的人选。Kubernetes 已经使用 _Endpoints_ 来表示组成服务的一组复制 pod，因此我们将重用这个相同的对象。（旁白：您可能认为我们会使用 _ReplicationControllers_，但它们是绑定到特定的二进制文件，而且通常您希望只有一个领导者，即使您正在执行滚动更新）
+
+要执行 leader election，我们使用所有 Kubernetes api 对象的两个属性：
+
+<!--
+* ResourceVersions - Every API object has a unique ResourceVersion, and you can use these versions to perform compare-and-swap on Kubernetes objects
+* Annotations - Every API object can be annotated with arbitrary key/value pairs to be used by clients.
+
+Given these primitives, the code to use master election is relatively straightforward, and you can find it [here][1]. Let's run it ourselves.
+-->
+
+* ResourceVersions - 每个 API 对象都有一个惟一的 ResourceVersion，您可以使用这些版本对 Kubernetes 对象执行比较和交换
+* Annotations - 每个 API 对象都可以用客户端使用的任意键/值对进行注释。
+
+给定这些原语，使用 master election 的代码相对简单，您可以在这里找到[here][1]。我们自己来做吧。
+
+<!--
+```    
+$ kubectl run leader-elector --image=gcr.io/google_containers/leader-elector:0.4 --replicas=3 -- --election=example
+```
+
+This creates a leader election set with 3 replicas:
+
+```    
+$ kubectl get pods
+NAME                   READY     STATUS    RESTARTS   AGE
+leader-elector-inmr1   1/1       Running   0          13s
+leader-elector-qkq00   1/1       Running   0          13s
+leader-elector-sgwcq   1/1       Running   0          13s
+```
+-->
+
+```    
+$ kubectl run leader-elector --image=gcr.io/google_containers/leader-elector:0.4 --replicas=3 -- --election=example
+```
+
+这将创建一个包含3个副本的 leader election 集合：
+
+```    
+$ kubectl get pods
+NAME                   READY     STATUS    RESTARTS   AGE
+leader-elector-inmr1   1/1       Running   0          13s
+leader-elector-qkq00   1/1       Running   0          13s
+leader-elector-sgwcq   1/1       Running   0          13s
+```
+
+<!--
+To see which pod was chosen as the leader, you can access the logs of one of the pods, substituting one of your own pod's names in place of
+
+```  
+${pod_name}, (e.g. leader-elector-inmr1 from the above)
+
+$ kubectl logs -f ${name}
+leader is (leader-pod-name)
+```
+… Alternately, you can inspect the endpoints object directly:
+-->
+
+要查看哪个pod被选为领导，您可以访问其中一个 pod 的日志，用您自己的一个 pod 的名称替换
+
+```  
+${pod_name}, (e.g. leader-elector-inmr1 from the above)
+
+$ kubectl logs -f ${name}
+leader is (leader-pod-name)
+```
+…或者，可以直接检查 endpoints 对象：
+
+<!--
+_'example' is the name of the candidate set from the above kubectl run … command_
+```
+$ kubectl get endpoints example -o yaml
+```
+Now to validate that leader election actually works, in a different terminal, run:
+
+```  
+$ kubectl delete pods (leader-pod-name)
+```
+-->
+
+_'example' 是上面 kubectl run … 命令_中候选集的名称
+```
+$ kubectl get endpoints example -o yaml
+```
+现在，要验证 leader election 是否实际有效，请在另一个终端运行：
+```  
+$ kubectl delete pods (leader-pod-name)
+```
+
+<!--
+This will delete the existing leader. Because the set of pods is being managed by a replication controller, a new pod replaces the one that was deleted, ensuring that the size of the replicated set is still three. Via leader election one of these three pods is selected as the new leader, and you should see the leader failover to a different pod. Because pods in Kubernetes have a _grace period_ before termination, this may take 30-40 seconds.
+
+The leader-election container provides a simple webserver that can serve on any address (e.g. http://localhost:4040). You can test this out by deleting the existing leader election group and creating a new one where you additionally pass in a --http=(host):(port) specification to the leader-elector image. This causes each member of the set to serve information about the leader via a webhook.
+-->
+
+这将删除现有领导。由于 pod 集由 replication controller 管理，因此新的 pod 将替换已删除的pod，确保复制集的大小仍为3。通过 leader election，这三个pod中的一个被选为新的领导者，您应该会看到领导者故障转移到另一个pod。因为 Kubernetes 的吊舱在终止前有一个 _grace period_，这可能需要30-40秒。
+
+Leader-election container 提供了一个简单的 web 服务器，可以服务于任何地址(e.g. http://localhost:4040)。您可以通过删除现有的 leader election 组并创建一个新的 leader elector 组来测试这一点，在该组中，您还可以向 leader elector 映像传递--http=(host):(port) 规范。这将导致集合中的每个成员通过 webhook 提供有关领导者的信息。
+
+<!--
+```    
+# delete the old leader elector group
+$ kubectl delete rc leader-elector
+
+# create the new group, note the --http=localhost:4040 flag
+$ kubectl run leader-elector --image=gcr.io/google_containers/leader-elector:0.4 --replicas=3 -- --election=example --http=0.0.0.0:4040
+
+# create a proxy to your Kubernetes api server
+$ kubectl proxy
+```
+-->
+
+```    
+# delete the old leader elector group
+$ kubectl delete rc leader-elector
+
+# create the new group, note the --http=localhost:4040 flag
+$ kubectl run leader-elector --image=gcr.io/google_containers/leader-elector:0.4 --replicas=3 -- --election=example --http=0.0.0.0:4040
+
+# create a proxy to your Kubernetes api server
+$ kubectl proxy
+```
+
+<!--
+You can then access:
+
+
+http://localhost:8001/api/v1/proxy/namespaces/default/pods/(leader-pod-name):4040/
+
+
+And you will see:
+
+```  
+{"name":"(name-of-leader-here)"}
+```
+####  Leader election with sidecars
+-->
+
+然后您可以访问：
+
+
+
+
+http://localhost:8001/api/v1/proxy/namespaces/default/pods/(leader-pod-name):4040/
+
+
+
+
+你会看到：
+
+```  
+{"name":"(name-of-leader-here)"}
+```
+####  有副手的 leader election
+
+<!--
+Ok, that's great, you can do leader election and find out the leader over HTTP, but how can you use it from your own application? This is where the notion of sidecars come in. In Kubernetes, Pods are made up of one or more containers. Often times, this means that you add sidecar containers to your main application to make up a Pod. (for a much more detailed treatment of this subject see my earlier blog post).
+
+The leader-election container can serve as a sidecar that you can use from your own application. Any container in the Pod that's interested in who the current master is can simply access http://localhost:4040 and they'll get back a simple JSON object that contains the name of the current master. Since all containers in a Pod share the same network namespace, there's no service discovery required!
+-->
+
+好吧，那太好了，你可以通过 HTTP 进行leader election 并找到 leader，但是你如何从自己的应用程序中使用它呢？这就是 sidecar 的由来。Kubernetes  中，Pods 由一个或多个容器组成。通常情况下，这意味着您将 sidecar containers 添加到主应用程序中以组成 pod。（关于这个主题的更详细的处理，请参阅我之前的博客文章）。
+Leader-election container 可以作为一个 sidecar，您可以从自己的应用程序中使用。Pod 中任何对当前 master 感兴趣的容器都可以简单地访问http://localhost:4040，它们将返回一个包含当前 master 名称的简单 json 对象。由于 pod中 的所有容器共享相同的网络命名空间，因此不需要服务发现！
+
+<!--
+For example, here is a simple Node.js application that connects to the leader election sidecar and prints out whether or not it is currently the master. The leader election sidecar sets its identifier to `hostname` by default.
+
+```    
+var http = require('http');
+// This will hold info about the current master
+var master = {};
+
+  // The web handler for our nodejs application
+  var handleRequest = function(request, response) {
+    response.writeHead(200);
+    response.end("Master is " + master.name);
+  };
+
+  // A callback that is used for our outgoing client requests to the sidecar
+  var cb = function(response) {
+    var data = '';
+    response.on('data', function(piece) { data = data + piece; });
+    response.on('end', function() { master = JSON.parse(data); });
+  };
+
+  // Make an async request to the sidecar at http://localhost:4040
+  var updateMaster = function() {
+    var req = http.get({host: 'localhost', path: '/', port: 4040}, cb);
+    req.on('error', function(e) { console.log('problem with request: ' + e.message); });
+    req.end();
+  };
+
+  / / Set up regular updates
+  updateMaster();
+  setInterval(updateMaster, 5000);
+
+  // set up the web server
+  var www = http.createServer(handleRequest);
+  www.listen(8080);
+  ```
+  Of course, you can use this sidecar from any language that you choose that supports HTTP and JSON.
+-->
+
+例如，这里有一个简单的 Node.js 应用程序，它连接到 leader election sidecar 并打印出它当前是否是 master。默认情况下，leader election sidecar 将其标识符设置为 `hostname`。
+
+```    
+var http = require('http');
+// This will hold info about the current master
+var master = {};
+
+  // The web handler for our nodejs application
+  var handleRequest = function(request, response) {
+    response.writeHead(200);
+    response.end("Master is " + master.name);
+  };
+
+  // A callback that is used for our outgoing client requests to the sidecar
+  var cb = function(response) {
+    var data = '';
+    response.on('data', function(piece) { data = data + piece; });
+    response.on('end', function() { master = JSON.parse(data); });
+  };
+
+  // Make an async request to the sidecar at http://localhost:4040
+  var updateMaster = function() {
+    var req = http.get({host: 'localhost', path: '/', port: 4040}, cb);
+    req.on('error', function(e) { console.log('problem with request: ' + e.message); });
+    req.end();
+  };
+
+  / / Set up regular updates
+  updateMaster();
+  setInterval(updateMaster, 5000);
+
+  // set up the web server
+  var www = http.createServer(handleRequest);
+  www.listen(8080);
+  ```
+ 当然，您可以从任何支持 HTTP 和 JSON 的语言中使用这个 sidecar。
+
+<!--
+#### Conclusion
+
+
+  Hopefully I've shown you how easy it is to build leader election for your distributed application using Kubernetes. In future installments we'll show you how Kubernetes is making building distributed systems even easier. In the meantime, head over to [Google Container Engine][2] or [kubernetes.io][3] to get started with Kubernetes.
+
+  [1]: https://github.com/kubernetes/contrib/pull/353
+  [2]: https://cloud.google.com/container-engine/
+  [3]: http://kubernetes.io/
+-->
+
+#### 结论
+
+
+ 希望我已经向您展示了使用 Kubernetes 为您的分布式应用程序构建 leader election 是多么容易。在以后的部分中，我们将向您展示 Kubernetes 如何使构建分布式系统变得更加容易。同时，转到[Google Container Engine][2]或[kubernetes.io][3]开始使用Kubernetes。
+
+  [1]: https://github.com/kubernetes/contrib/pull/353
+  [2]: https://cloud.google.com/container-engine/
+  [3]: http://kubernetes.io/
@@ -0,0 +1,79 @@
+---
+title: " 为什么 Kubernetes 不用 libnetwork "
+date: 2016-01-14
+slug: why-kubernetes-doesnt-use-libnetwork
+url: /blog/2016/01/Why-Kubernetes-Doesnt-Use-Libnetwork
+---
+
+<!-- ---
+title: " Why Kubernetes doesn’t use libnetwork "
+date: 2016-01-14
+slug: why-kubernetes-doesnt-use-libnetwork
+url: /blog/2016/01/Why-Kubernetes-Doesnt-Use-Libnetwork
+--- -->
+
+<!-- Kubernetes has had a very basic form of network plugins since before version 1.0 was released — around the same time as Docker's [libnetwork](https://github.com/docker/libnetwork) and Container Network Model ([CNM](https://github.com/docker/libnetwork/blob/master/docs/design.md)) was introduced. Unlike libnetwork, the Kubernetes plugin system still retains its "alpha" designation. Now that Docker's network plugin support is released and supported, an obvious question we get is why Kubernetes has not adopted it yet. After all, vendors will almost certainly be writing plugins for Docker — we would all be better off using the same drivers, right?   -->
+
+在 1.0 版本发布之前，Kubernetes 已经有了一个非常基础的网络插件形式-大约在引入 Docker’s [libnetwork](https://github.com/docker/libnetwork) 和 Container Network Model ([CNM](https://github.com/docker/libnetwork/blob/master/docs/design.md)) 的时候。与 libnetwork 不同，Kubernetes 插件系统仍然保留它的 'alpha' 名称。现在 Docker 的网络插件支持已经发布并得到支持，我们发现一个明显的问题是 Kubernetes 尚未采用它。毕竟，供应商几乎肯定会为 Docker 编写插件-我们最好还是用相同的驱动程序，对吧？
+
+<!-- Before going further, it's important to remember that Kubernetes is a system that supports multiple container runtimes, of which Docker is just one. Configuring networking is a facet of each runtime, so when people ask "will Kubernetes support CNM?" what they really mean is "will kubernetes support CNM drivers with the Docker runtime?" It would be great if we could achieve common network support across runtimes, but that’s not an explicit goal.   -->
+
+在进一步说明之前，重要的是记住 Kubernetes 是一个支持多种容器运行时的系统， Docker 只是其中之一。配置网络只是每一个运行时的一个方面，所以当人们问起“ Kubernetes 会支持CNM吗？”，他们真正的意思是“ Kubernetes 会支持 Docker 运行时的 CNM 驱动吗？”如果我们能够跨运行时实现通用的网络支持会很棒，但这不是一个明确的目标。
+
+<!-- Indeed, Kubernetes has not adopted CNM/libnetwork for the Docker runtime. In fact, we’ve been investigating the alternative Container Network Interface ([CNI](https://github.com/appc/cni/blob/master/SPEC.md)) model put forth by CoreOS and part of the App Container ([appc](https://github.com/appc)) specification. Why? There are a number of reasons, both technical and non-technical.   -->
+
+实际上， Kubernetes 还没有为 Docker 运行时采用 CNM/libnetwork 。事实上，我们一直在研究 CoreOS 提出的替代 Container Network Interface ([CNI](https://github.com/appc/cni/blob/master/SPEC.md)) 模型以及 App Container ([appc](https://github.com/appc)) 规范的一部分。为什么我们要这么做？有很多技术和非技术的原因。
+
+<!-- First and foremost, there are some fundamental assumptions in the design of Docker's network drivers that cause problems for us.   -->
+
+首先，Docker 的网络驱动程序设计中存在一些基本假设，这些假设会给我们带来问题。
+
+<!-- Docker has a concept of "local" and "global" drivers. Local drivers (such as "bridge") are machine-centric and don’t do any cross-node coordination. Global drivers (such as "overlay") rely on [libkv](https://github.com/docker/libkv) (a key-value store abstraction) to coordinate across machines. This key-value store is a another plugin interface, and is very low-level (keys and values, no semantic meaning). To run something like Docker's overlay driver in a Kubernetes cluster, we would either need cluster admins to run a whole different instance of [consul](https://github.com/hashicorp/consul), [etcd](https://github.com/coreos/etcd) or [zookeeper](https://zookeeper.apache.org/) (see [multi-host networking](https://docs.docker.com/engine/userguide/networking/get-started-overlay/)), or else we would have to provide our own libkv implementation that was backed by Kubernetes.  -->
+
+Docker 有一个“本地”和“全局”驱动程序的概念。本地驱动程序（例如 "bridge" ）以机器为中心，不进行任何跨节点协调。全局驱动程序（例如 "overlay" ）依赖于 [libkv](https://github.com/docker/libkv) （一个键值存储抽象库）来协调跨机器。这个键值存储是另一个插件接口，并且是非常低级的（键和值，没有其他含义）。 要在 Kubernetes 集群中运行类似 Docker's overlay 驱动程序，我们要么需要集群管理员来运行 [consul](https://github.com/hashicorp/consul), [etcd](https://github.com/coreos/etcd) 或 [zookeeper](https://zookeeper.apache.org/) 的整个不同实例 (see [multi-host networking](https://docs.docker.com/engine/userguide/networking/get-started-overlay/)) 否则我们必须提供我们自己的 libkv 实现，那被 Kubernetes 支持。
+
+<!-- The latter sounds attractive, and we tried to implement it, but the libkv interface is very low-level, and the schema is defined internally to Docker. We would have to either directly expose our underlying key-value store or else offer key-value semantics (on top of our structured API which is itself implemented on a key-value system). Neither of those are very attractive for performance, scalability and security reasons. The net result is that the whole system would significantly be more complicated, when the goal of using Docker networking is to simplify things.   -->
+
+后者听起来很有吸引力，并且我们尝试实现它，但 libkv 接口是非常低级的，并且架构在内部定义为 Docker 。我们必须直接暴露我们的底层键值存储，或者提供键值语义（在我们的结构化API之上，它本身是在键值系统上实现的）。对于性能，可伸缩性和安全性原因，这些都不是很有吸引力。最终结果是，当使用 Docker 网络的目标是简化事情时，整个系统将显得更加复杂。
+
+<!-- For users that are willing and able to run the requisite infrastructure to satisfy Docker global drivers and to configure Docker themselves, Docker networking should "just work." Kubernetes will not get in the way of such a setup, and no matter what direction the project goes, that option should be available. For default installations, though, the practical conclusion is that this is an undue burden on users and we therefore cannot use Docker's global drivers (including "overlay"), which eliminates a lot of the value of using Docker's plugins at all.   -->
+
+对于愿意并且能够运行必需的基础架构以满足 Docker 全局驱动程序并自己配置 Docker 的用户， Docker 网络应该“正常工作。” Kubernetes 不会妨碍这样的设置，无论项目的方向如何，该选项都应该可用。但是对于默认安装，实际的结论是这对用户来说是一个不应有的负担，因此我们不能使用 Docker 的全局驱动程序（包括 "overlay" ），这消除了使用 Docker 插件的很多价值。
+
+<!-- Docker's networking model makes a lot of assumptions that aren’t valid for Kubernetes. In docker versions 1.8 and 1.9, it includes a fundamentally flawed implementation of "discovery" that results in corrupted `/etc/hosts` files in containers ([docker #17190](https://github.com/docker/docker/issues/17190)) — and this cannot be easily turned off. In version 1.10 Docker is planning to [bundle a new DNS server](https://github.com/docker/docker/issues/17195), and it’s unclear whether this will be able to be turned off. Container-level naming is not the right abstraction for Kubernetes — we already have our own concepts of service naming, discovery, and binding, and we already have our own DNS schema and server (based on the well-established [SkyDNS](https://github.com/skynetservices/skydns)). The bundled solutions are not sufficient for our needs but are not disableable.   -->
+
+Docker 的网络模型做出了许多对 Kubernetes 无效的假设。在 docker 1.8 和 1.9 版本中，它包含一个从根本上有缺陷的“发现”实现，导致容器中的 `/etc/hosts` 文件损坏 ([docker #17190](https://github.com/docker/docker/issues/17190)) - 并且这不容易被关闭。在 1.10 版本中，Docker 计划 [捆绑一个新的DNS服务器](https://github.com/docker/docker/issues/17195)，目前还不清楚是否可以关闭它。容器级命名不是 Kubernetes 的正确抽象 - 我们已经有了自己的服务命名，发现和绑定概念，并且我们已经有了自己的 DNS 模式和服务器（基于完善的 [SkyDNS](https://github.com/skynetservices/skydns) ）。捆绑的解决方案不足以满足我们的需求，但不能禁用。
+
+<!-- Orthogonal to the local/global split, Docker has both in-process and out-of-process ("remote") plugins. We investigated whether we could bypass libnetwork (and thereby skip the issues above) and drive Docker remote plugins directly. Unfortunately, this would mean that we could not use any of the Docker in-process plugins, "bridge" and "overlay" in particular, which again eliminates much of the utility of libnetwork.   -->
+
+与本地/全局拆分正交， Docker 具有进程内和进程外（ "remote" ）插件。我们调查了是否可以绕过 libnetwork （从而跳过上面的问题）并直接驱动 Docker remote 插件。不幸的是，这意味着我们无法使用任何 Docker 进程中的插件，特别是 "bridge" 和 "overlay"，这再次消除了 libnetwork 的大部分功能。
+
+<!-- On the other hand, CNI is more philosophically aligned with Kubernetes. It's far simpler than CNM, doesn't require daemons, and is at least plausibly cross-platform (CoreOS’s [rkt](https://coreos.com/rkt/docs/) container runtime supports it). Being cross-platform means that there is a chance to enable network configurations which will work the same across runtimes (e.g. Docker, Rocket, Hyper). It follows the UNIX philosophy of doing one thing well.   -->
+
+另一方面， CNI 在哲学上与 Kubernetes 更加一致。它比 CNM 简单得多，不需要守护进程，并且至少是合理的跨平台（ CoreOS 的 [rkt](https://coreos.com/rkt/docs/) 容器运行时支持它）。跨平台意味着有机会启用跨运行时（例如 Docker ， Rocket ， Hyper ）运行相同的网络配置。 它遵循 UNIX 的理念，即做好一件事。
+
+<!-- Additionally, it's trivial to wrap a CNI plugin and produce a more customized CNI plugin — it can be done with a simple shell script. CNM is much more complex in this regard. This makes CNI an attractive option for rapid development and iteration. Early prototypes have proven that it's possible to eject almost 100% of the currently hard-coded network logic in kubelet into a plugin.   -->
+
+此外，包装 CNI 插件并生成更加个性化的 CNI 插件是微不足道的 - 它可以通过简单的 shell 脚本完成。 CNM 在这方面要复杂得多。这使得 CNI 对于快速开发和迭代是有吸引力的选择。早期的原型已经证明，可以将 kubelet 中几乎 100％ 的当前硬编码网络逻辑弹出到插件中。
+
+<!-- We investigated [writing a "bridge" CNM driver](https://groups.google.com/forum/#!topic/kubernetes-sig-network/5MWRPxsURUw) for Docker that ran CNI drivers. This turned out to be very complicated. First, the CNM and CNI models are very different, so none of the "methods" lined up. We still have the global vs. local and key-value issues discussed above. Assuming this driver would declare itself local, we have to get info about logical networks from Kubernetes.   -->
+
+我们调查了为 Docker [编写 "bridge" CNM驱动程序](https://groups.google.com/forum/#!topic/kubernetes-sig-network/5MWRPxsURUw) 并运行 CNI 驱动程序。事实证明这非常复杂。首先， CNM 和 CNI 模型非常不同，因此没有一种“方法”协调一致。 我们仍然有上面讨论的全球与本地和键值问题。假设这个驱动程序会声明自己是本地的，我们必须从 Kubernetes 获取有关逻辑网络的信息。
+
+<!-- Unfortunately, Docker drivers are hard to map to other control planes like Kubernetes. Specifically, drivers are not told the name of the network to which a container is being attached — just an ID that Docker allocates internally. This makes it hard for a driver to map back to any concept of network that exists in another system.   -->
+
+不幸的是， Docker 驱动程序很难映射到像 Kubernetes 这样的其他控制平面。具体来说，驱动程序不会被告知连接容器的网络名称 - 只是 Docker 内部分配的 ID 。这使得驱动程序很难映射回另一个系统中存在的任何网络概念。
+
+<!-- This and other issues have been brought up to Docker developers by network vendors, and are usually closed as "working as intended" ([libnetwork #139](https://github.com/docker/libnetwork/issues/139), [libnetwork #486](https://github.com/docker/libnetwork/issues/486), [libnetwork #514](https://github.com/docker/libnetwork/pull/514), [libnetwork #865](https://github.com/docker/libnetwork/issues/865), [docker #18864](https://github.com/docker/docker/issues/18864)), even though they make non-Docker third-party systems more difficult to integrate with. Throughout this investigation Docker has made it clear that they’re not very open to ideas that deviate from their current course or that delegate control. This is very worrisome to us, since Kubernetes complements Docker and adds so much functionality, but exists outside of Docker itself.   -->
+
+这个问题和其他问题已由网络供应商提出给 Docker 开发人员，并且通常关闭为“按预期工作”，([libnetwork #139](https://github.com/docker/libnetwork/issues/139), [libnetwork #486](https://github.com/docker/libnetwork/issues/486), [libnetwork #514](https://github.com/docker/libnetwork/pull/514), [libnetwork #865](https://github.com/docker/libnetwork/issues/865), [docker #18864](https://github.com/docker/docker/issues/18864))，即使它们使非 Docker 第三方系统更难以与之集成。在整个调查过程中， Docker 明确表示他们对偏离当前路线或委托控制的想法不太欢迎。这对我们来说非常令人担忧，因为 Kubernetes 补充了 Docker 并增加了很多功能，但它存在于 Docker 之外。
+
+<!-- For all of these reasons we have chosen to invest in CNI as the Kubernetes plugin model. There will be some unfortunate side-effects of this. Most of them are relatively minor (for example, `docker inspect` will not show an IP address), but some are significant. In particular, containers started by `docker run` might not be able to communicate with containers started by Kubernetes, and network integrators will have to provide CNI drivers if they want to fully integrate with Kubernetes. On the other hand, Kubernetes will get simpler and more flexible, and a lot of the ugliness of early bootstrapping (such as configuring Docker to use our bridge) will go away.   -->
+
+出于所有这些原因，我们选择投资 CNI 作为 Kubernetes 插件模型。这会有一些不幸的副作用。它们中的大多数都相对较小（例如， `docker inspect` 不会显示 IP 地址），但有些是重要的。特别是，由 `docker run` 启动的容器可能无法与 Kubernetes 启动的容器通信，如果网络集成商想要与 Kubernetes 完全集成，则必须提供 CNI 驱动程序。另一方面， Kubernetes 将变得更简单，更灵活，早期引入的许多丑陋的（例如配置 Docker 使用我们的网桥）将会消失。
+
+<!-- As we proceed down this path, we’ll certainly keep our eyes and ears open for better ways to integrate and simplify. If you have thoughts on how we can do that, we really would like to hear them — find us on [slack](http://slack.k8s.io/) or on our [network SIG mailing-list](https://groups.google.com/forum/#!forum/kubernetes-sig-network).   -->
+
+当我们沿着这条道路前进时，我们肯定会保持眼睛和耳朵的开放，以便更好地整合和简化。如果您对我们如何做到这一点有所想法，我们真的希望听到它们 - 在 [slack](http://slack.k8s.io/) 或者 [network SIG mailing-list](https://groups.google.com/forum/#!forum/kubernetes-sig-network) 找到我们。
+
+Tim Hockin, Software Engineer, Google
@@ -0,0 +1,84 @@
+---
+title: " KubeCon EU 2016：伦敦 Kubernetes 社区 "
+date: 2016-02-24
+slug: kubecon-eu-2016-kubernetes-community-in
+url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
+---
+
+<!--
+---
+title: " KubeCon EU 2016: Kubernetes Community in London "
+date: 2016-02-24
+slug: kubecon-eu-2016-kubernetes-community-in
+url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
+---
+-->
+
+<!--
+KubeCon EU 2016 is the inaugural [European Kubernetes](http://kubernetes.io/) community conference that follows on the American launch in November 2015. KubeCon is fully dedicated to education and community engagement for[Kubernetes](http://kubernetes.io/) enthusiasts, production users and the surrounding ecosystem.
+-->
+KubeCon EU 2016 是首届[欧洲 Kubernetes](http://kubernetes.io/) 社区会议，紧随 2015 年 11 月召开的北美会议。KubeCon 致力于为 [Kubernetes](http://kubernetes.io/) 爱好者、产品用户和周围的生态系统提供教育和社区参与。
+
+<!--
+Come join us in London and hang out with hundreds from the Kubernetes community and experience a wide variety of deep technical expert talks and use cases.
+-->
+快来加入我们在伦敦，与 Kubernetes 社区的数百人一起出去，体验各种深入的技术专家讲座和用例。
+
+<!--
+Don’t miss these great speaker sessions at the conference:
+-->
+不要错过这些优质的演讲：
+
+<!--
+* “Kubernetes Hardware Hacks: Exploring the Kubernetes API Through Knobs, Faders, and Sliders” by Ian Lewis and Brian Dorsey, Developer Advocate, Google -* [http://sched.co/6Bl3](http://sched.co/6Bl3)  
+
+* “rktnetes: what's new with container runtimes and Kubernetes” by Jonathan Boulle, Developer and Team Lead at CoreOS -* [http://sched.co/6BY7](http://sched.co/6BY7)
+
+* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google -* [http://sched.co/6BUP](http://sched.co/6BUP)&nbsp;
+* “[What is OpenStack's role in a Kubernetes world?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” By Thierry Carrez, Director of Engineering, OpenStack Foundation -* http://sched.co/6BYC
+* “A Practical Guide to Container Scheduling” by Mandy Waite, Developer Advocate, Google -* [http://sched.co/6BZa](http://sched.co/6BZa)  
+
+* “[Kubernetes in Production in The New York Times newsroom](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis, Web Developer, New York Times -* [http://sched.co/67f2](http://sched.co/67f2)
+* “[Creating an Advanced Load Balancing Solution for Kubernetes with NGINX](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” by Andrew Hutchings, Technical Product Manager, NGINX -* http://sched.co/6Bc9
+* And many more http://kubeconeurope2016.sched.org/
+-->
+
+* “Kubernetes 硬件黑客：通过旋钮、推杆和滑块探索 Kubernetes API” 演讲者 Ian Lewis 和 Brian Dorsey，谷歌开发布道师* [http://sched.co/6Bl3](http://sched.co/6Bl3)  
+
+* “rktnetes: 容器运行时和 Kubernetes 的新功能” 演讲者 Jonathan Boulle, CoreOS 的主程 -* [http://sched.co/6BY7](http://sched.co/6BY7)
+
+* “Kubernetes 文档：贡献、修复问题、收集奖金” 作者：John Mulhausen，首席技术作家，谷歌 -* [http://sched.co/6BUP](http://sched.co/6BUP)&nbsp;
+* “[OpenStack 在 Kubernetes 的世界中扮演什么角色？](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” 作者：Thierry carez, OpenStack 基金会工程总监 -* http://sched.co/6BYC
+* “容器调度的实用指南” 作者：Mandy Waite，开发者倡导者，谷歌 -* [http://sched.co/6BZa](http://sched.co/6BZa)  
+
+* “[《纽约时报》编辑部正在制作 Kubernetes](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis，《纽约时报》网站开发人员 -* [http://sched.co/67f2](http://sched.co/67f2)
+* “[使用 NGINX 为 Kubernetes 创建一个高级负载均衡解决方案](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” 作者：Andrew Hutchings, NGINX 技术产品经理 -* http://sched.co/6Bc9
+* 还有更多 http://kubeconeurope2016.sched.org/
+
+<!--
+Get your KubeCon EU [tickets here](https://ti.to/kubecon/kubecon-eu-2016).
+-->
+[在这里](https://ti.to/kubecon/kubecon-eu-2016)获取您的 KubeCon EU 门票。
+
+<!--
+Venue Location: CodeNode * 10 South Pl, London, United Kingdom  
+Accommodations: [hotels](https://skillsmatter.com/contact-us#hotels)   
+Website: [kubecon.io](https://www.kubecon.io/)   
+Twitter: [@KubeConio](https://twitter.com/kubeconio) #KubeCon
+Google is a proud Diamond sponsor of KubeCon EU 2016. Come to London next month, March 10th & 11th, and visit booth #13 to learn all about Kubernetes, Google Container Engine (GKE) and Google Cloud Platform!  
+-->
+会场地址：CodeNode * 英国伦敦南广场 10 号
+酒店住宿：[酒店](https://skillsmatter.com/contact-us)
+网站：[kubecon.io] (https://www.kubecon.io/)
+推特：[@KubeConio] (https://twitter.com/kubeconio)
+谷歌是 KubeCon EU 2016 的钻石赞助商。下个月 3 月 10 - 11 号来伦敦，参观 13 号展位，了解 Kubernetes，Google Container Engine（GKE），Google Cloud Platform 的所有信息!
+
+<!--
+_KubeCon is organized by KubeAcademy, LLC, a community-driven group of developers focused on the education of developers and the promotion of Kubernetes._  
+
+-* Sarah Novotny, Kubernetes Community Manager, Google  
+-->
+
+_KubeCon 是由 KubeAcademy、LLC 组织的，这是一个由社区驱动的开发者团体，专注于开发人员的教育和 kubernet.com 的推广
+-* Sarah Novotny, 谷歌的 Kubernetes 社区经理
+
@@ -0,0 +1,117 @@
+---
+title: " Kubernetes 社区会议记录 - 20160204 "
+date: 2016-02-09
+slug: kubernetes-community-meeting-notes
+url: /blog/2016/02/Kubernetes-Community-Meeting-Notes
+---
+<!--
+---
+title: " Kubernetes community meeting notes - 20160204 "
+date: 2016-02-09
+slug: kubernetes-community-meeting-notes
+url: /blog/2016/02/Kubernetes-Community-Meeting-Notes
+---
+-->
+<!--
+####  February 4th - rkt demo (congratulations on the 1.0, CoreOS!), eBay puts k8s on Openstack and considers Openstack on k8s, SIGs, and flaky test surge makes progress.
+-->
+####  2月4日 - rkt演示（祝贺 1.0 版本， CoreOS！）， eBay 将 k8s 放在 Openstack 上并认为 Openstack 在 k8s， SIG 和片状测试激增方面取得了进展。
+
+<!--
+The Kubernetes contributing community meets most Thursdays at 10:00PT to discuss the project's status via a videoconference. Here are the notes from the latest meeting.
+-->
+Kubernetes 贡献社区在每周四 10:00 PT 开会,通过视频会议讨论项目状态。以下是最近一次会议的笔记。
+
+<!--
+* Note taker: Rob Hirschfeld
+* Demo (20 min): CoreOS rkt + Kubernetes [Shaya Potter]
+    * expect to see integrations w/ rkt & k8s in the coming months ("rkt-netes"). not integrated into the v1.2 release.
+    * Shaya gave a demo (8 minutes into meeting for video reference)
+        * CLI of rkt shown spinning up containers
+        * [note: audio is garbled at points]
+        * Discussion about integration w/ k8s & rkt
+        * rkt community sync next week: https://groups.google.com/forum/#!topic/rkt-dev/FlwZVIEJGbY
+        * Dawn Chen:
+            * The remaining issues of integrating rkt with kubernetes: 1) cadivsor 2) DNS 3) bugs related to logging
+            * But need more work on e2e test suites
+-->
+* 书记员：Rob Hirschfeld
+* 演示视频（20分钟）：CoreOS rkt + Kubernetes[Shaya Potter]
+    * 期待在未来几个月内看到与rkt和k8s的整合（“rkt-netes”）。 还没有集成到 v1.2版本中。   
+    * Shaya 做了一个演示（8分钟的会议视频参考）
+        * rkt的CLI显示了旋转容器
+        * [注意：音频在点数上是乱码]
+        * 关于 k8s&rkt 整合的讨论
+        * 下周 rkt 社区同步：https://groups.google.com/forum/#!topic/rkt-dev/FlwZVIEJGbY
+        * Dawn Chen:
+            * 将 rkt 与 kubernetes 集成的其余问题：1）cadivsor 2） DNS 3）与日志记录相关的错误
+            * 但是需要在 e2e 测试套件上做更多的工作
+<!--    
+* Use Case (10 min): eBay k8s on OpenStack and OpenStack on k8s [Ashwin Raveendran]
+    * eBay is currently running Kubernetes on OpenStack
+    * Goal for eBay is to manage the OpenStack control plane w/ k8s.  Goal would be to achieve upgrades
+    * OpenStack Kolla creates containers for the control plane.  Uses Ansible+Docker for management of the containers.  
+    * Working on k8s control plan management - Saltstack is proving to be a management challenge at the scale they want to operate.  Looking for automated management of the k8s control plane.
+-->
+* 用例（10分钟）：在 OpenStack 上的 eBay k8s 和 k8s 上的 OpenStack [Ashwin Raveendran]
+    * eBay 目前正在 OpenStack 上运行 Kubernetes
+    * eBay 的目标是管理带有 k8s 的 OpenStack 控制平面。目标是实现升级。
+    * OpenStack Kolla 为控制平面创建容器。使用 Ansible+Docker 来管理容器。
+    * 致力于 k8s 控制计划管理 - Saltstack 被证明是他们想运营的规模的管理挑战。寻找 k8s 控制平面的自动化管理。
+<!--
+* SIG Report
+* Testing update [Jeff, Joe, and Erick]
+    * Working to make the workflow about contributing to K8s easier to understanding
+        * [pull/19714][1] has flow chart of the bot flow to help users understand
+    * Need a consistent way to run tests w/ hacking config scripts (you have to fake a Jenkins process right now)
+    * Want to create necessary infrastructure to make test setup less flaky
+    * want to decouple test start (single or full) from Jenkins
+    * goal is to get to point where you have 1 script to run that can be pointed to any cluster
+    * demo included Google internal views - working to try get that external.
+    * want to be able to collect test run results
+    * Bob Wise calls for testing infrastructure to be a blocker on v1.3
+    * Long discussion about testing practices…
+        * consensus that we want to have tests work over multiple platforms.
+        * would be helpful to have a comprehensive state dump for test reports
+        * "phone-home" to collect stack traces - should be available
+-->
+*  SIG 报告
+*  测试更新 [Jeff, Joe, 和 Erick]
+    *  努力使有助于 K8s 的工作流程更容易理解
+        * [pull/19714][1]有 bot 流程图来帮助用户理解
+    *  需要一种一致的方法来运行测试 w/hacking 配置脚本（你现在必须伪造一个 Jenkins 进程）
+    *  想要创建必要的基础设施，使测试设置不那么薄弱
+    *  想要将测试开始（单次或完整）与 Jenkins分离
+    *  目标是指出你有一个可以指向任何集群的脚本
+    *  演示包括 Google 内部视图 - 努力尝试获取外部视图。
+    *  希望能够收集测试运行结果
+    *  Bob Wise 不赞同在 v1.3 版本进行测试方面的基础设施建设。
+    *  关于测试实践的长期讨论…
+       * 我们希望在多个平台上进行测试的共识。
+       * 为测试报告提供一个全面转储会很有帮助
+       * 可以使用"phone-home"收集异常
+       
+
+<!--
+* 1.2 Release Watch
+* CoC [Sarah]
+* GSoC [Sarah]
+-->
+* 1.2发布观察
+* CoC [Sarah]
+* GSoC [Sarah]
+
+<!--
+To get involved in the Kubernetes community consider joining our [Slack channel][2], taking a look at the [Kubernetes project][3] on GitHub, or join the [Kubernetes-dev Google group][4]. If you're really excited, you can do all of the above and join us for the next community conversation -- February 11th, 2016. Please add yourself or a topic you want to know about to the [agenda][5] and get a calendar invitation by joining [this group][6].   
+-->
+要参与 Kubernetes 社区，请考虑加入我们的[Slack 频道][2]，查看 GitHub上的 [Kubernetes 项目][3]，或加入[Kubernetes-dev Google 小组][4]。如果你真的很兴奋，你可以完成上述所有工作并加入我们的下一次社区对话-2016年2月11日。请将您自己或您想要了解的主题添加到[议程][5]并通过加入[此组][6]来获取日历邀请。
+
+ "https://youtu.be/IScpP8Cj0hw?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ"
+
+
+[1]: https://github.com/kubernetes/kubernetes/pull/19714
+[2]: http://slack.k8s.io/
+[3]: https://github.com/kubernetes/
+[4]: https://groups.google.com/forum/#!forum/kubernetes-dev
+[5]: https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit#
+[6]: https://groups.google.com/forum/#!forum/kubernetes-community-video-chat
@@ -1,3 +1,10 @@
+---
+title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
+date: 2016-04-18
+slug: kubernetes-network-policy-apis
+url: /blog/2016/04/Kubernetes-Network-Policy-APIs
+---
+
 <!-- ---
 title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
 date: 2016-04-18
@@ -5,13 +12,6 @@ slug: kubernetes-network-policy-apis
 url: /blog/2016/04/Kubernetes-Network-Policy-APIs
 --- -->

---
-title: "SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
-date: 2016-04-18
-slug: kubernetes-network-policy-apis
-url: /blog/2016/04/Kubernetes-Network-Policy-APIs
---
-
 <!-- _Editor’s note: This week we’re featuring [Kubernetes Special Interest Groups](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)); Today’s post is by the Network-SIG team describing network policy APIs coming in 1.3 - policies for security, isolation and multi-tenancy._ -->

 编者按：这一周，我们的封面主题是 [Kubernetes 特别兴趣小组](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs))；今天的文章由网络兴趣小组撰写，来谈谈 1.3 版本中即将出现的网络策略 API - 针对安全，隔离和多租户的策略。
@@ -1,10 +1,3 @@
-<!-- ---
-title: " How to deploy secure, auditable, and reproducible Kubernetes clusters on AWS "
-date: 2016-04-15
-slug: kubernetes-on-aws_15
-url: /blog/2016/04/Kubernetes-On-Aws_15
--- -->
-
 ---
 title: " 如何在AWS上部署安全，可审计，可复现的k8s集群 "
 date: 2016-04-15
@@ -12,6 +5,13 @@ slug: kubernetes-on-aws_15
 url: /blog/2016/04/Kubernetes-On-Aws_15
 ---

+<!-- ---
+title: " How to deploy secure, auditable, and reproducible Kubernetes clusters on AWS "
+date: 2016-04-15
+slug: kubernetes-on-aws_15
+url: /blog/2016/04/Kubernetes-On-Aws_15
+--- -->
+
 <!-- _Today’s guest post is written by Colin Hom, infrastructure engineer at [CoreOS](https://coreos.com/), the company delivering Google’s Infrastructure for Everyone Else (#GIFEE) and running the world's containers securely on CoreOS Linux, Tectonic and Quay._

 _Join us at [CoreOS Fest Berlin](https://coreos.com/fest/), the Open Source Distributed Systems Conference, and learn more about CoreOS and Kubernetes._ -->
@@ -0,0 +1,72 @@
+---
+title: " Citrix + Kubernetes = 全垒打 "
+date: 2016-07-14
+slug: citrix-netscaler-and-kubernetes
+url: /blog/2016/07/Citrix-Netscaler-And-Kubernetes
+---
+
+<!--
+---
+title: " Citrix + Kubernetes = A Home Run "
+date: 2016-07-14
+slug: citrix-netscaler-and-kubernetes
+url: /blog/2016/07/Citrix-Netscaler-And-Kubernetes
+---
+-->
+
+<!--
+_Editor’s note: today’s guest post is by Mikko Disini, a Director of Product Management at Citrix Systems, sharing their collaboration experience on a Kubernetes integration.&nbsp;_  
+-->
+编者按：今天的客座文章来自 Citrix Systems 的产品管理总监 Mikko Disini，他分享了他们在 Kubernetes 集成上的合作经验。&nbsp;_ 
+
+<!--
+Technical collaboration is like sports. If you work together as a team, you can go down the homestretch and pull through for a win. That’s our experience with the Google Cloud Platform team.  
+-->
+技术合作就像体育运动。如果你能像一个团队一样合作，你就能在最后关头取得胜利。这就是我们对谷歌云平台团队的经验。
+
+<!--
+Recently, we approached Google Cloud Platform (GCP) to collaborate on behalf of Citrix customers and the broader enterprise market looking to migrate workloads.&nbsp;This migration required including the [NetScaler Docker load balancer](https://www.citrix.com/blogs/2016/06/20/the-best-docker-load-balancer-at-dockercon-in-seattle-this-week/), CPX, into Kubernetes nodes and resolving any issues with getting traffic into the CPX proxies. &nbsp;  
+-->
+最近，我们与 Google 云平台（GCP）联系，代表 Citrix 客户以及更广泛的企业市场，希望就工作负载的迁移进行协作。此迁移需要将 [NetScaler Docker 负载均衡器]https://www.citrix.com/blogs/2016/06/20/the-best-docker-load-balancer-at-dockercon-in-seattle-this-week/) CPX 包含到 Kubernetes 节点中，并解决将流量引入 CPX 代理的任何问题。  
+
+<!--
+**Why NetScaler and Kubernetes?**  
+-->
+
+**为什么是 NetScaler 和 Kubernetes**
+
+<!--
+1. Citrix customers want the same Layer 4 to Layer 7 capabilities from NetScaler that they have on-prem as they move to the cloud as they begin deploying their container and microservices architecture with Kubernetes&nbsp;
+2. Kubernetes provides a proven infrastructure for running containers and VMs with automated workload delivery
+3. NetScaler CPX provides Layer 4 to Layer 7 services and highly efficient telemetry data to a logging and analytics platform, [NetScaler Management and Analytics System](https://www.citrix.com/blogs/2016/05/24/introducing-the-next-generation-netscaler-management-and-analytics-system/)
+-->
+
+1. Citrix 的客户希望他们开始使用 Kubernetes 部署他们的容器和微服务体系结构时，能够像当初迁移到云计算时一样，享有 NetScaler 所提供的第 4 层到第 7 层能力&nbsp;
+2. Kubernetes 提供了一套经过验证的基础设施，可用来运行容器和虚拟机，并自动交付工作负载；  
+3. NetScaler CPX 提供第 4 层到第 7 层的服务，并为日志和分析平台 [NetScaler 管理和分析系统](https://www.citrix.com/blogs/2016/05/24/introducing-the-next-generation-netscaler-management-and-analytics-system/) 提供高效的度量数据。
+
+<!--
+I wish all our experiences working together with a technical partner were as good as working with GCP. We had a list of issues to enable our use cases and were able to collaborate swiftly on a solution. To resolve these, GCP team offered in depth technical assistance, working with Citrix such that NetScaler CPX can spin up and take over as a client-side proxy running on each host.&nbsp;  
+-->
+我希望我们所有与技术合作伙伴一起工作的经验都能像与 GCP 一起工作一样好。我们有一个列表，包含支持我们的用例所需要解决的问题。我们能够快速协作形成解决方案。为了解决这些问题，GCP 团队提供了深入的技术支持，与 Citrix 合作，从而使得 NetScaler CPX 能够在每台主机上作为客户端代理启动运行。
+
+<!--
+Next, NetScaler CPX needed to be inserted in the data path of GCP ingress load balancer so that NetScaler CPX can spread traffic to front end web servers. The NetScaler team made modifications so that NetScaler CPX listens to API server events and configures itself to create a VIP, IP table rules and server rules to take ingress traffic and load balance across front end applications. Google Cloud Platform team provided feedback and assistance to verify modifications made to overcome the technical hurdles. Done!  
+-->
+接下来，需要在 GCP 入口负载均衡器的数据路径中插入 NetScaler CPX，使 NetScaler CPX 能够将流量分散到前端 web 服务器。NetScaler 团队进行了修改，以便 NetScaler CPX 监听 API 服务器事件，并配置自己来创建 VIP、IP 表规则和服务器规则，以便跨前端应用程序接收流量和负载均衡。谷歌云平台团队提供反馈和帮助，验证为克服技术障碍所做的修改。完成了!
+
+<!--
+NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.&nbsp;  
+-->
+NetScaler CPX 用例在 [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernets-1.3 - bridge -cloud-native-and-enterprise-workload) 中提供支持。Citrix 的客户和更广泛的企业市场将有机会基于 Kubernetes 享用 NetScaler 服务，从而降低将工作负载转移到云平台的阻力。&nbsp;
+
+<!--
+You can learn more about&nbsp;NetScaler CPX [here](https://www.citrix.com/networking/microservices.html).  
+-->
+您可以在[此处](https://www.citrix.com/networking/microservices.html)了解有关 NetScaler CPX 的更多信息。
+
+<!--
+_&nbsp;-- Mikko Disini, Director of Product Management - NetScaler, Citrix Systems_
+-->
+_&nbsp;-- Mikko Disini，Citrix Systems NetScaler 产品管理总监
+
@@ -0,0 +1,139 @@
+---
+title: " Dashboard - Kubernetes 的全功能 Web 界面 "
+date: 2016-07-15
+slug: dashboard-web-interface-for-kubernetes
+url: /blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
+---
+
+<!--
+---
+title: " Dashboard - Full Featured Web Interface for Kubernetes "
+date: 2016-07-15
+slug: dashboard-web-interface-for-kubernetes
+url: /blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
+---
+-->
+
+<!--
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_  
+
+[Kubernetes Dashboard](http://github.com/kubernetes/dashboard) is a project that aims to bring a general purpose monitoring and operational web interface to the Kubernetes world.&nbsp;Three months ago we [released](https://kubernetes.io/blog/2016/04/building-awesome-user-interfaces-for-kubernetes) the first production ready version, and since then the dashboard has made massive improvements. In a single UI, you’re able to perform majority of possible interactions with your Kubernetes clusters without ever leaving your browser. This blog post breaks down new features introduced in the latest release and outlines the roadmap for the future.&nbsp;  
+-->
+
+_编者按：这篇文章是[一系列深入的文章](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) 中关于Kubernetes 1.3的新内容的一部分_
+[Kubernetes Dashboard](http://github.com/kubernetes/dashboard)是一个旨在为 Kubernetes 世界带来通用监控和操作 Web 界面的项目。三个月前，我们[发布](https://kubernetes.io/blog/2016/04/building-awesome-user-interfaces-for-kubernetes)第一个面向生产的版本，从那时起 dashboard 已经做了大量的改进。在一个 UI 中，您可以在不离开浏览器的情况下，与 Kubernetes 集群执行大多数可能的交互。这篇博客文章分解了最新版本中引入的新功能，并概述了未来的路线图。
+
+<!--
+**Full-Featured Dashboard**  
+
+Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.  
+-->
+
+**全功能的 Dashboard** 
+
+由于社区和项目成员的大量贡献，我们能够为[Kubernetes 1.3发行版](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads)提供许多新功能。我们一直在认真听取用户的反馈(参见[摘要信息图表](http://static.lwy.io/img/kubernetes_dashboard_infographic.png))，并解决了最高优先级的请求和难点。
+-->
+
+<!--
+The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.&nbsp;  
+
+
+
+ [![](https://lh3.googleusercontent.com/p9bMGxPx4jE6_Z2KB-MktmyuAxyFst-bEk29M_Bn0Bj5ul7uzinH6u5WjHsMmqhGvBwlABZt06dwQ5qkBZiLq_EM1oddCmpwChvXDNXZypaS5l8uzkKuZj3PBUmzTQT4dgDxSXgz) ](https://lh3.googleusercontent.com/p9bMGxPx4jE6_Z2KB-MktmyuAxyFst-bEk29M_Bn0Bj5ul7uzinH6u5WjHsMmqhGvBwlABZt06dwQ5qkBZiLq_EM1oddCmpwChvXDNXZypaS5l8uzkKuZj3PBUmzTQT4dgDxSXgz)
+-->
+
+Dashboard UI 现在处理所有工作负载资源。这意味着无论您运行什么工作负载类型，它都在 web 界面中可见，并且您可以对其进行操作更改。例如，可以使用[Pet Sets](/docs/user-guide/petset/)修改有状态的 mysql 安装，使用部署对 web 服务器进行滚动更新，或使用守护程序安装群集监视。
+
+
+
+ [![](https://lh3.googleusercontent.com/p9bMGxPx4jE6_Z2KB-MktmyuAxyFst-bEk29M_Bn0Bj5ul7uzinH6u5WjHsMmqhGvBwlABZt06dwQ5qkBZiLq_EM1oddCmpwChvXDNXZypaS5l8uzkKuZj3PBUmzTQT4dgDxSXgz) ](https://lh3.googleusercontent.com/p9bMGxPx4jE6_Z2KB-MktmyuAxyFst-bEk29M_Bn0Bj5ul7uzinH6u5WjHsMmqhGvBwlABZt06dwQ5qkBZiLq_EM1oddCmpwChvXDNXZypaS5l8uzkKuZj3PBUmzTQT4dgDxSXgz)
+
+<!--
+In addition to viewing resources, you can create, edit, update, and delete them. This feature enables many use cases. For example, you can kill a failed Pod, do a rolling update on a Deployment, or just organize your resources. You can also export and import YAML configuration files of your cloud apps and store them in a version control system.
+
+
+
+ ![](https://lh6.googleusercontent.com/zz-qjNcGgvWXrK1LIipUdIdPyeWJ1EyPVJxRnSvI6pMcLBkxDxpQt-ObsIiZsS_X0RjVBWtXYO5TCvhsymb__CGXFzKuPUnUrB4HKnAMsxtYdWLwMmHEb8c9P9Chzlo5ePHRKf5O)
+-->
+
+除了查看资源外，还可以创建、编辑、更新和删除资源。这个特性支持许多用例。例如，您可以杀死一个失败的 pod，对部署进行滚动更新，或者只组织资源。您还可以导出和导入云应用程序的 yaml 配置文件，并将它们存储在版本控制系统中。
+
+
+
+ ![](https://lh6.googleusercontent.com/zz-qjNcGgvWXrK1LIipUdIdPyeWJ1EyPVJxRnSvI6pMcLBkxDxpQt-ObsIiZsS_X0RjVBWtXYO5TCvhsymb__CGXFzKuPUnUrB4HKnAMsxtYdWLwMmHEb8c9P9Chzlo5ePHRKf5O)
+
+<!--
+The release includes a beta view of cluster nodes for administration and operational use cases. The UI lists all nodes in the cluster to allow for overview analysis and quick screening for problematic nodes. The details view shows all information about the node and links to pods running on it.
+
+
+
+ ![](https://lh6.googleusercontent.com/3CSTUy-8Tz-yAL9tCqxNUqMcWJYKK0dwk7kidE9zy-L-sXFiD4A4Y2LKEqbJKgI6Fl6xbzYxsziI8dULVXPJbu6eU0ci7hNtqi3tTuhdbVD6CG3EXw151fvt2MQuqumHRbab6g-_)
+-->
+
+这个版本包括一个用于管理和操作用例的集群节点的 beta 视图。UI 列出集群中的所有节点，以便进行总体分析和快速筛选有问题的节点。details 视图显示有关该节点的所有信息以及指向在其上运行的 pod 的链接。
+
+
+
+ ![](https://lh6.googleusercontent.com/3CSTUy-8Tz-yAL9tCqxNUqMcWJYKK0dwk7kidE9zy-L-sXFiD4A4Y2LKEqbJKgI6Fl6xbzYxsziI8dULVXPJbu6eU0ci7hNtqi3tTuhdbVD6CG3EXw151fvt2MQuqumHRbab6g-_)
+
+<!--
+There are also many smaller scope new features that the we shipped with the release, namely: support for namespaced resources, internationalization, performance improvements, and many bug fixes (find out more in the [release notes](https://github.com/kubernetes/dashboard/releases/tag/v1.1.0)). All these improvements result in a better and simpler user experience of the product.
+-->
+
+我们随发行版提供的还有许多小范围的新功能，即：支持命名空间资源、国际化、性能改进和许多错误修复(请参阅[发行说明](https://github.com/kubernetes/dashboard/releases/tag/v1.1.0)中的更多内容)。所有这些改进都会带来更好、更简单的产品用户体验。
+
+<!--
+**Future Work**
+
+
+
+The team has ambitious plans for the future spanning across multiple use cases. We are also open to all feature requests, which you can post on our [issue tracker](https://github.com/kubernetes/dashboard/issues).
+-->
+
+**Future Work**
+
+
+
+该团队对跨越多个用例的未来有着雄心勃勃的计划。我们还对所有功能请求开放，您可以在我们的[问题跟踪程序](https://github.com/kubernetes/dashboard/issues)上发布这些请求。
+
+<!--
+Here is a list of our focus areas for the following months:
+
+- [Handle more Kubernetes resources](https://github.com/kubernetes/dashboard/issues/961) - To show all resources that a cluster user may potentially interact with. Once done, Dashboard can act as a complete replacement for CLI.&nbsp;
+- [Monitoring and troubleshooting](https://github.com/kubernetes/dashboard/issues/962) - To add resource usage statistics/graphs to the objects shown in Dashboard. This focus area will allow for actionable debugging and troubleshooting of cloud applications.
+- [Security, auth and logging in](https://github.com/kubernetes/dashboard/issues/964) - Make Dashboard accessible from networks external to a Cluster and work with custom authentication systems.
+-->
+
+以下是我们接下来几个月的重点领域：
+
+- [Handle more Kubernetes resources](https://github.com/kubernetes/dashboard/issues/961) - 显示群集用户可能与之交互的所有资源。一旦完成，dashboard 就可以完全替代cli。
+- [Monitoring and troubleshooting](https://github.com/kubernetes/dashboard/issues/962) - 将资源使用统计信息/图表添加到 Dashboard 中显示的对象。这个重点领域将允许对云应用程序进行可操作的调试和故障排除。
+- [Security, auth and logging in](https://github.com/kubernetes/dashboard/issues/964) - 使仪表板可从群集外部的网络访问，并使用自定义身份验证系统。
+
+<!--
+**Connect With Us**
+
+
+
+We would love to talk with you and hear your feedback!
+
+- Email us at the [SIG-UI mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-ui)
+- Chat with us on the Kubernetes Slack&nbsp;[#SIG-UI channel](https://kubernetes.slack.com/messages/sig-ui/)
+- Join our meetings: 4PM CEST. See the [SIG-UI calendar](https://calendar.google.com/calendar/embed?src=google.com_52lm43hc2kur57dgkibltqc6kc%40group.calendar.google.com&ctz=Europe/Warsaw) for details.
+
+
+
+
+
+_-- Piotr Bryk, Software Engineer, Google_
+-->
+
+**联系我们**
+
+
+
+我们很乐意与您交谈并听取您的反馈！
+
+- 请在[SIG-UI邮件列表](https://groups.google.com/forum/向我们发送电子邮件！论坛/kubernetes sig ui)
+- 在 kubernetes slack 上与我们聊天。[#SIG-UI channel](https://kubernetes.slack.com/messages/sig-ui/)
+- 参加我们的会议：东部时间下午4点。请参阅[SIG-UI日历](https://calendar.google.com/calendar/embed?src=google.com_52lm43hc2kur57dgkibltqc6kc%40group.calendar.google.com&ctz=Europe/Warsaw)了解详细信息。
@@ -0,0 +1,89 @@
+---
+title: " Kubernetes 生日快乐。哦，这是你要去的地方！ "
+date: 2016-07-21
+slug: oh-the-places-you-will-go
+url: /blog/2016/07/Oh-The-Places-You-Will-Go
+---
+
+<!--
+---
+title: " Happy Birthday Kubernetes. Oh, the places you’ll go! "
+date: 2016-07-21
+slug: oh-the-places-you-will-go
+url: /blog/2016/07/Oh-The-Places-You-Will-Go
+---
+-->
+
+<!--
+_Editor’s note, Today’s guest post is from an independent Kubernetes contributor, Justin Santa Barbara, sharing his reflection on growth of the project from inception to its future._  
+
+**Dear K8s,**  
+
+_It’s hard to believe you’re only one - you’ve grown up so fast. On the occasion of your first birthday, I thought I would write a little note about why I was so excited when you were born, why I feel fortunate to be part of the group that is raising you, and why I’m eager to watch you continue to grow up!_  
+-->
+
+_编者按，今天的嘉宾帖子来自一位独立的 kubernetes 撰稿人 Justin Santa Barbara，分享了他对项目从一开始到未来发展的思考。_  
+
+**亲爱的 K8s,**  
+
+_很难相信你是唯一的一个 - 成长这么快的。在你一岁生日的时候，我想我可以写一个小纸条，告诉你为什么我在你出生的时候那么兴奋，为什么我觉得很幸运能成为抚养你长大的一员，为什么我渴望看到你继续成长！_  
+
+<!--
+_--Justin_  
+
+You started with an excellent foundation - good declarative functionality, built around a solid API with a well defined schema and the machinery so that we could evolve going forwards. And sure enough, over your first year you grew so fast: autoscaling, HTTP load-balancing support (Ingress), support for persistent workloads including clustered databases (PetSets). You’ve made friends with more clouds (welcome Azure & OpenStack to the family), and even started to span zones and clusters (Federation). And these are just some of the most visible changes - there’s so much happening inside that brain of yours!  
+
+I think it’s wonderful you’ve remained so open in all that you do - you seem to write down everything on GitHub - for better or worse. I think we’ve all learned a lot about that on the way, like the perils of having engineers make scaling statements that are then weighed against claims made without quite the same framework of precision and rigor. But I’m proud that you chose not to lower your standards, but rose to the challenge and just ran faster instead - it might not be the most realistic approach, but it is the only way to move mountains!  
+-->
+
+_--Justin_ 
+
+你从一个优秀的基础 - 良好的声明性功能开始，它是围绕一个具有良好定义的模式和机制的坚实的 API 构建的，这样我们就可以向前发展了。果然，在你的第一年里，你增长得如此之快：autoscaling、HTTP load-balancing support (Ingress)、support for persistent workloads including clustered databases (PetSets)。你已经和更多的云交了朋友(欢迎 azure 和 openstack 加入家庭)，甚至开始跨越区域和集群(Federation)。这些只是一些最明显的变化 - 在你的大脑里发生了太多的变化！
+
+我觉得你一直保持开放的态度真是太好了 - 你好像把所有的东西都写在 github 上 - 不管是好是坏。我想我们在这方面都学到了很多，比如让工程师做缩放声明的风险，然后在没有完全相同的精确性和严谨性框架的情况下，将这些声明与索赔进行权衡。但我很自豪你选择了不降低你的标准，而是上升到挑战，只是跑得更快 - 这可能不是最现实的办法，但这是唯一的方式能移动山！
+
+<!--
+And yet, somehow, you’ve managed to avoid a lot of the common dead-ends that other open source software has fallen into, particularly as those projects got bigger and the developers end up working on it more than they use it directly. How did you do that? There’s a probably-apocryphal story of an employee at IBM that makes a huge mistake, and is summoned to meet with the big boss, expecting to be fired, only to be told “We just spent several million dollars training you. Why would we want to fire you?”. Despite all the investment google is pouring into you (along with Redhat and others), I sometimes wonder if the mistakes we are avoiding could be worth even more. There is a very open development process, yet there’s also an “oracle” that will sometimes course-correct by telling us what happens two years down the road if we make a particular design decision. This is a parent you should probably listen to!  
+-->
+
+然而，不知何故，你已经设法避免了许多其他开源软件陷入的共同死胡同，特别是当那些项目越来越大，开发人员最终要做的比直接使用它更多的时候。你是怎么做到的？有一个很可能是虚构的故事，讲的是 IBM 的一名员工犯了一个巨大的错误，被传唤去见大老板，希望被解雇，却被告知“我们刚刚花了几百万美元培训你。我们为什么要解雇你？“。尽管谷歌对你进行了大量的投资(包括 redhat 和其他公司)，但我有时想知道，我们正在避免的错误是否更有价值。有一个非常开放的开发过程，但也有一个“oracle”，它有时会通过告诉我们两年后如果我们做一个特定的设计决策会发生什么来纠正错误。这是你应该听的父母！
+
+<!--
+And so although you’re only a year old, you really have an [old soul](http://queue.acm.org/detail.cfm?id=2898444). I’m just one of the [many people raising you](https://kubernetes.io/blog/2016/07/happy-k8sbday-1), but it’s a wonderful learning experience for me to be able to work with the people that have built these incredible systems and have all this domain knowledge. Yet because we started from scratch (rather than taking the existing Borg code) we’re at the same level and can still have genuine discussions about how to raise you. Well, at least as close to the same level as we could ever be, but it’s to their credit that they are all far too nice ever to mention it!  
+
+If I would pick just two of the wise decisions those brilliant people made:  
+-->
+
+所以，尽管你只有一岁，你真的有一个[旧灵魂](http://queue.acm.org/detail.cfm？ID=2898444)。我只是[很多人抚养你]中的一员(https://kubernetes.io/blog/2016/07/happy-k8sbday-1)，但对我来说，能够与那些建立了这些令人难以置信的系统并拥有所有这些领域知识的人一起工作是一次极好的学习经历。然而，因为我们是白手起家(而不是采用现有的 Borg 代码)，我们处于同一水平，仍然可以就如何培养你进行真正的讨论。好吧，至少和我们的水平一样接近，但值得称赞的是，他们都太好了，从来没提过！
+
+如果我选择两个聪明人做出的明智决定：
+
+<!--
+- Labels & selectors give us declarative “pointers”, so we can say “why” we want things, rather than listing the things directly. It’s the secret to how you can scale to [great heights](https://kubernetes.io/blog/2016/07/thousand-instances-of-cassandra-using-kubernetes-pet-set); not by naming each step, but saying “a thousand more steps just like that first one”.
+- Controllers are state-synchronizers: we specify the goals, and your controllers will indefatigably work to bring the system to that state. They work through that strongly-typed API foundation, and are used throughout the code, so Kubernetes is more of a set of a hundred small programs than one big one. It’s not enough to scale to thousands of nodes technically; the project also has to scale to thousands of developers and features; and controllers help us get there.
+-->
+
+- 标签和选择器给我们声明性的“pointers”，所以我们可以说“为什么”我们想要东西，而不是直接列出东西。这是如何扩展到[伟大高度]的秘密(https://kubernetes.io/blog/2016/07/thousand-instances-of-cassandra-using-kubernetes-pet-set)；不是命名每一步，而是说“像第一步一样多走一千步”。
+- 控制器是状态同步器：我们指定目标，您的控制器将不遗余力地工作，使系统达到该状态。它们工作在强类型 API 基础上，并且贯穿整个代码，因此 Kubernetes 比一个大的程序多一百个小程序。仅仅从技术上扩展到数千个节点是不够的；这个项目还必须扩展到数千个开发人员和特性；控制器帮助我们达到目的。
+
+<!--
+And so on we will go! We’ll be replacing those controllers and building on more, and the API-foundation lets us build anything we can express in that way - with most things just a label or annotation away! But your thoughts will not be defined by language: with third party resources you can express anything you choose. Now we can build Kubernetes without building in Kubernetes, creating things that feel as much a part of Kubernetes as anything else. Many of the recent additions, like ingress, DNS integration, autoscaling and network policies were done or could be done in this way. Eventually it will be hard to imagine you before these things, but tomorrow’s standard functionality can start today, with no obstacles or gatekeeper, maybe even for an audience of one.  
+
+So I’m looking forward to seeing more and more growth happen further and further from the core of Kubernetes. We had to work our way through those phases; starting with things that needed to happen in the kernel of Kubernetes - like replacing replication controllers with deployments. Now we’re starting to build things that don’t require core changes. But we’re still still talking about infrastructure separately from applications. It’s what comes next that gets really interesting: when we start building applications that rely on the Kubernetes APIs. We’ve always had the Cassandra example that uses the Kubernetes API to self-assemble, but we haven’t really even started to explore this more widely yet. In the same way that the S3 APIs changed how we build things that remember, I think the k8s APIs are going to change how we build things that think.  
+-->
+
+等等我们就走！我们将取代那些控制器，建立更多，API 基金会让我们构建任何我们可以用这种方式表达的东西 - 大多数东西只是标签或注释远离！但你的思想不会由语言来定义：有了第三方资源，你可以表达任何你选择的东西。现在我们可以不用在 Kubernetes 建造Kubernetes 了，创造出与其他任何东西一样感觉是 Kubernetes 的一部分的东西。最近添加的许多功能，如ingress、DNS integration、autoscaling and network policies ，都已经完成或可以通过这种方式完成。最终，在这些事情发生之前很难想象你会是怎样的一个人，但是明天的标准功能可以从今天开始，没有任何障碍或看门人，甚至对一个听众来说也是这样。
+
+所以我期待着看到越来越多的增长发生在离 Kubernetes 核心越来越远的地方。我们必须通过这些阶段来工作；从需要在 kubernetes 内核中发生的事情开始——比如用部署替换复制控制器。现在我们开始构建不需要核心更改的东西。但我们仍然在讨论基础设施和应用程序。接下来真正有趣的是：当我们开始构建依赖于 kubernetes api 的应用程序时。我们一直有使用 kubernetes api 进行自组装的 cassandra 示例，但我们还没有真正开始更广泛地探讨这个问题。正如 S3 APIs 改变了我们构建记忆事物的方式一样，我认为 k8s APIs 也将改变我们构建思考事物的方式。
+
+<!--
+So I’m looking forward to your second birthday: I can try to predict what you’ll look like then, but I know you’ll surpass even the most audacious things I can imagine. Oh, the places you’ll go!  
+
+
+_-- Justin Santa Barbara, Independent Kubernetes Contributor_  
+-->
+
+所以我很期待你的二岁生日：我可以试着预测你那时的样子，但我知道你会超越我所能想象的最大胆的东西。哦，这是你要去的地方！
+
+
+_-- Justin Santa Barbara, 独立的 Kubernetes 贡献者_  
@@ -0,0 +1,72 @@
+---
+title: " Kubernetes 1.8 的五天 "
+date: 2017-10-24
+slug: five-days-of-kubernetes-18
+url: /blog/2017/10/Five-Days-Of-Kubernetes-18
+---
+
+<!--
+---
+title: " Five Days of Kubernetes 1.8 "
+date: 2017-10-24
+slug: five-days-of-kubernetes-18
+url: /blog/2017/10/Five-Days-Of-Kubernetes-18
+---
+-->
+
+<!--
+Kubernetes 1.8 is live, made possible by hundreds of contributors pushing thousands of commits in this latest releases.  
+-->
+Kubernetes 1.8 是现场直播，数百名贡献者在这个最新版本中推出了成千上万的提交。
+
+<!--
+The community has tallied more than 66,000 commits in the main repo and continues rapid growth outside of the main repo, which signals growing maturity and stability for the project. The community has logged more than 120,000 commits across all repos and 17,839 commits across all repos for v1.7.0 to v1.8.0 alone.  
+-->
+社区已经有超过 66,000 个提交在主仓库，并在主仓库之外继续快速增长，这标志着该项目日益成熟和稳定。仅 v1.7.0 到 v1.8.0，社区就记录了所有仓库的超过 120,000 次提交和 17839 次提交。
+
+<!--
+With the help of our growing community of 1,400 plus contributors, we issued more than 3,000 PRs and pushed more than 5,000 commits to deliver Kubernetes 1.8 with significant security and workload support updates. This all points to increased stability, a result of our project-wide focus on maturing [process](https://github.com/kubernetes/sig-release), formalizing [architecture](https://github.com/kubernetes/community/tree/master/sig-architecture), and strengthening Kubernetes’ [governance model](https://github.com/kubernetes/community/tree/master/community/elections/2017).  
+-->
+在拥有 1400 多名贡献者，并且不断发展壮大的社区的帮助下，我们合并了 3000 多个 PR，并发布了 5000 多个提交，最后的 Kubernetes 1.8 在安全和工作负载方面添加了很多的更新。
+这一切都表明稳定性的提高，这是我们整个项目关注成熟[流程](https://github.com/kubernetes/sig-release)、形式化[架构](https://github.com/kubernetes/community/tree/master/sig-architecture)和加强 Kubernetes 的[治理模型](https://github.com/kubernetes/community/tree/master/community/elections/2017)的结果。
+
+<!--
+While many improvements have been contributed, we highlight key features in this series of in-depth&nbsp;posts listed below. [Follow along](https://twitter.com/kubernetesio) and see what’s new and improved with storage, security and more.  
+-->
+虽然有很多改进，但我们在下面列出的这一系列深度文章中突出了一些关键特性。[跟随](https://twitter.com/kubernetesio)并了解存储，安全等方面的新功能和改进功能。
+
+<!--
+**Day 1:** [5 Days of Kubernetes 1.8](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)  
+**Day 2:** [kubeadm v1.8 Introduces Easy Upgrades for Kubernetes Clusters](https://kubernetes.io/blog/2017/10/kubeadm-v18-released)  
+**Day 3:** [Kubernetes v1.8 Retrospective: It Takes a Village to Raise a Kubernetes](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
+**Day 4:** [Using RBAC, Generally Available in Kubernetes v1.8](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18)  
+**Day 5:** [Enforcing Network Policies in Kubernetes](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes)  
+-->
+
+**第一天：** [Kubernetes 1.8 的五天](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)  
+**第二天：** [kubeadm v1.8 为 Kubernetes 集群引入了简单的升级](https://kubernetes.io/blog/2017/10/kubeadm-v18-released)  
+**第三天：** [Kubernetes v1.8 回顾：提升一个 Kubernetes 需要一个 Village](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
+**第四天：** [使用 RBAC，一般在 Kubernetes v1.8 中提供](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18)  
+**第五天：** [在 Kubernetes 执行网络策略](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes)  
+
+<!--
+**Connect**  
+-->
+
+**链接**  
+
+<!--
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates&nbsp;
+- Connect with the community on [Slack](http://slack.k8s.io/)
+- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
+-->
+
+- 在 [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) 上发布问题（或回答问题）
+- 加入 [K8sPort](http://k8sport.org/) 布道师的社区门户网站
+- 在 Twitter [@Kubernetesio](https://twitter.com/kubernetesio) 关注我们以获取最新更新
+- 与 [Slack](http://slack.k8s.io/) 上的社区联系
+- 参与 [GitHub](https://github.com/kubernetes/kubernetes) 上的 Kubernetes 项目 
+
+
@@ -0,0 +1,32 @@
+---
+title: " Kubernetes 中自动缩放 "
+date: 2017-11-17
+slug: autoscaling-in-kubernetes
+url: /blog/2017/11/Autoscaling-In-Kubernetes
+---
+
+<!--
+---
+title: " Autoscaling in Kubernetes "
+date: 2017-11-17
+slug: autoscaling-in-kubernetes
+url: /blog/2017/11/Autoscaling-In-Kubernetes
+---
+-->
+
+<!--
+Kubernetes allows developers to automatically adjust cluster sizes and the number of pod replicas based on current traffic and load. These adjustments reduce the amount of unused nodes, saving money and resources. In this talk, Marcin Wielgus of Google walks you through the current state of pod and node autoscaling in Kubernetes: .how it works, and how to use it, including best practices for deployments in production applications.  
+-->
+Kubernetes 允许开发人员根据当前的流量和负载自动调整集群大小和 pod 副本的数量。这些调整减少了未使用节点的数量，节省了资金和资源。
+在这次演讲中，谷歌的 Marcin Wielgus 将带领您了解 Kubernetes 中 pod 和 node 自动调焦的当前状态：它是如何工作的，以及如何使用它，包括在生产应用程序中部署的最佳实践。
+
+<!--
+Enjoyed this talk? Join us for more exciting sessions on scaling and automating your Kubernetes clusters at KubeCon in Austin on December 6-8. [Register Now](https://www.eventbrite.com/e/kubecon-cloudnativecon-north-america-registration-37824050754?_ga=2.9666039.317115486.1510003873-1623727562.1496428006)  
+-->
+喜欢这个演讲吗？ 12 月 6 日至 8 日，在 Austin 参加 KubeCon 关于扩展和自动化您的 Kubernetes 集群的更令人兴奋的会议。[现在注册](https://www.eventbrite.com/e/kubecon-cloudnativecon-north-america-registration-37824050754?_ga=2.9666039.317115486.1510003873-1623727562.1496428006)。
+
+<!--
+Be sure to check out [Automating and Testing Production Ready Kubernetes Clusters in the Public Cloud](http://sched.co/CU64) by Ron Lipke, Senior Developer, Platform as a Service, Gannet/USA Today Network.
+-->
+一定要查看由 Ron Lipke， Gannet/USA Today Network, 平台即服务高级开发人员，在[公共云中自动化和测试产品就绪的 Kubernetes 集群](http://sched.co/CU64)。
+
@@ -0,0 +1,728 @@
+---
+title: 在 Kubernetes 上开发
+date: 2018-05-01
+slug: developing-on-kubernetes
+---
+
+<!--
+---
+title: Developing on Kubernetes
+date: 2018-05-01
+slug: developing-on-kubernetes
+---
+-->
+
+<!--**Authors**:-->
+**作者**： [Michael Hausenblas](https://twitter.com/mhausenblas) (Red Hat), [Ilya Dmitrichenko](https://twitter.com/errordeveloper) (Weaveworks)
+
+<!-- 
+How do you develop a Kubernetes app? That is, how do you write and test an app that is supposed to run on Kubernetes? This article focuses on the challenges, tools and methods you might want to be aware of to successfully write Kubernetes apps alone or in a team setting. 
+-->
+
+您将如何开发一个 Kubernates 应用？也就是说，您如何编写并测试一个要在 Kubernates 上运行的应用程序？本文将重点介绍在独自开发或者团队协作中，您可能希望了解到的为了成功编写 Kubernetes 应用程序而需面临的挑战，工具和方法。
+
+<!--
+We’re assuming you are a developer, you have a favorite programming language, editor/IDE, and a testing framework available. The overarching goal is to introduce minimal changes to your current workflow when developing the app for Kubernetes. For example, if you’re a Node.js developer and are used to a hot-reload setup—that is, on save in your editor the running app gets automagically updated—then dealing with containers and container images, with container registries, Kubernetes deployments, triggers, and more can not only be overwhelming but really take all the fun out if it.
+-->
+
+我们假定您是一位开发人员，有您钟爱的编程语言，编辑器/IDE（集成开发环境），以及可用的测试框架。在针对 Kubernates 开发应用时，最重要的目标是减少对当前工作流程的影响，改变越少越好，尽量做到最小。举个例子，如果您是 Node.js 开发人员，习惯于那种热重载的环境 - 也就是说您在编辑器里一做保存，正在运行的程序就会自动更新 - 那么跟容器、容器镜像或者镜像仓库打交道，又或是跟 Kubernetes 部署、triggers 以及更多头疼东西打交道，不仅会让人难以招架也真的会让开发过程完全失去乐趣。
+
+<!--
+In the following, we’ll first discuss the overall development setup, then review tools of the trade, and last but not least do a hands-on walkthrough of three exemplary tools that allow for iterative, local app development against Kubernetes.
+-->
+
+在下文中，我们将首先讨论 Kubernetes 总体开发环境，然后回顾常用工具，最后进行三个示例性工具的实践演练。这些工具允许针对 Kubernetes 进行本地应用程序的开发和迭代。
+
+<!--
+## Where to run your cluster?
+-->
+
+## 您的集群运行在哪里？
+
+<!--
+As a developer you want to think about where the Kubernetes cluster you’re developing against runs as well as where the development environment sits. Conceptually there are four development modes:
+-->
+
+作为开发人员，您既需要考虑所针对开发的 Kubernetes 集群运行在哪里，也需要思考开发环境如何配置。概念上，有四种开发模式：
+
+![Dev Modes](/images/blog/2018-05-01-developing-on-kubernetes/dok-devmodes_preview.png)
+
+<!--
+A number of tools support pure offline development including Minikube, Docker for Mac/Windows, Minishift, and the ones we discuss in detail below. Sometimes, for example, in a microservices setup where certain microservices already run in the cluster, a proxied setup (forwarding traffic into and from the cluster) is preferable and Telepresence is an example tool in this category. The live mode essentially means you’re building and/or deploying against a remote cluster and, finally, the pure online mode means both your development environment and the cluster are remote, as this is the case with, for example, [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) or [Cloud 9](https://github.com/errordeveloper/k9c). Let’s now have a closer look at the basics of offline development: running Kubernetes locally.
+-->
+
+许多工具支持纯 offline 开发，包括 Minikube、Docker（Mac 版/Windows 版）、Minishift 以及下文中我们将详细讨论的几种。有时，比如说在一个微服务系统中，已经有若干微服务在运行，proxied 模式（通过转发把数据流传进传出集群）就非常合适，Telepresence 就是此类工具的一个实例。live 模式，本质上是您基于一个远程集群进行构建和部署。最后，纯 online 模式意味着您的开发环境和运行集群都是远程的，典型的例子是 [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) 或者 [Cloud 9](https://github.com/errordeveloper/k9c)。现在让我们仔细看看离线开发的基础：在本地运行 Kubernetes。
+
+<!--
+[Minikube](/docs/getting-started-guides/minikube/) is a popular choice for those who prefer to run Kubernetes in a local VM. More recently Docker for [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) and [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) started shipping Kubernetes as an experimental package (in the “edge” channel). Some reasons why you may want to prefer using Minikube over the Docker desktop option are:
+-->
+
+[Minikube](/docs/getting-started-guides/minikube/) 在更加喜欢于本地 VM 上运行 Kubernetes 的开发人员中，非常受欢迎。不久前，Docker 的 [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) 版和 [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) 版，都试验性地开始自带 Kubernetes（需要下载 “edge” 安装包）。在两者之间，以下原因也许会促使您选择 Minikube 而不是 Docker 桌面版：
+
+<!--
+* You already have Minikube installed and running
+* You prefer to wait until Docker ships a stable package
+* You’re a Linux desktop user
+* You are a Windows user who doesn’t have Windows 10 Pro with Hyper-V
+-->
+
+* 您已经安装了 Minikube 并且它运行良好
+* 您想等到 Docker 出稳定版本
+* 您是 Linux 桌面用户
+* 您是 Windows 用户，但是没有配有 Hyper-V 的 Windows 10 Pro
+
+<!--
+Running a local cluster allows folks to work offline and that you don’t have to pay for using cloud resources. Cloud provider costs are often rather affordable and free tiers exists, however some folks prefer to avoid having to approve those costs with their manager as well as potentially incur unexpected costs, for example, when leaving cluster running over the weekend.
+-->
+
+运行一个本地集群，开发人员可以离线工作，不用支付云服务。云服务收费一般不会太高，并且免费的等级也有，但是一些开发人员不喜欢为了使用云服务而必须得到经理的批准，也不愿意支付意想不到的费用，比如说忘了下线而集群在周末也在运转。
+
+<!--
+Some developers prefer to use a remote Kubernetes cluster, and this is usually to allow for larger compute and storage capacity and also enable collaborative workflows more easily. This means it’s easier for you to pull in a colleague to help with debugging or share access to an app in the team. Additionally, for some developers it can be critical to mirror production environment as closely as possible, especially when it comes down to external cloud services, say,  proprietary databases, object stores, message queues, external load balancer, or mail delivery systems.
+-->
+
+有些开发人员却更喜欢远程的 Kubernetes 集群，这样他们通常可以获得更大的计算能力和存储容量，也简化了协同工作流程。您可以更容易的拉上一个同事来帮您调试，或者在团队内共享一个应用的使用。再者，对某些开发人员来说，尽可能的让开发环境类似生产环境至关重要，尤其是您依赖外部厂商的云服务时，如：专有数据库、云对象存储、消息队列、外商的负载均衡器或者邮件投递系统。
+
+<!--
+In summary, there are good reasons for you to develop against a local cluster as well as a remote one. It very much depends on in which phase you are: from early prototyping and/or developing alone to integrating a set of more stable microservices.
+-->
+
+总之，无论您选择本地或者远程集群，理由都足够多。这很大程度上取决于您所处的阶段：从早期的原型设计/单人开发到后期面对一批稳定微服务的集成。
+
+<!--
+Now that you have a basic idea of the options around the runtime environment, let’s move on to how to iteratively develop and deploy your app.
+-->
+
+既然您已经了解到运行环境的基本选项，那么我们就接着讨论如何迭代式的开发并部署您的应用。
+
+<!--
+## The tools of the trade
+-->
+
+## 常用工具
+
+<!--
+We are now going to review tooling allowing you to develop apps on Kubernetes with the focus on having minimal impact on your existing workflow. We strive to provide an unbiased description including implications of using each of the tools in general terms.
+-->
+
+我们现在回顾既可以允许您可以在 Kubernetes 上开发应用程序又尽可能最小地改变您现有的工作流程的一些工具。我们致力于提供一份不偏不倚的描述，也会提及使用某个工具将会意味着什么。
+
+<!--
+Note that this is a tricky area since even for established technologies such as, for example, JSON vs YAML vs XML or REST vs gRPC vs SOAP a lot depends on your background, your preferences and organizational settings. It’s even harder to compare tooling in the Kubernetes ecosystem as things evolve very rapidly and new tools are announced almost on a weekly basis; during the preparation of this post alone, for example, [Gitkube](https://gitkube.sh/) and [Watchpod](https://github.com/MinikubeAddon/watchpod) came out. To cover these new tools as well as related, existing tooling such as [Weave Flux](https://github.com/weaveworks/flux) and OpenShift’s [S2I](https://docs.openshift.com/container-platform/3.9/creating_images/s2i.html) we are planning a follow-up blog post to the one you’re reading.
+-->
+
+请注意这很棘手，因为即使在成熟定型的技术中做选择，比如说在 JSON、YAML、XML、REST、gRPC 或者 SOAP 之间做选择，很大程度也取决于您的背景、喜好以及公司环境。在 Kubernetes 生态系统内比较各种工具就更加困难，因为技术发展太快，几乎每周都有新工具面市；举个例子，仅在准备这篇博客的期间，[Gitkube](https://gitkube.sh/) 和 [Watchpod](https://github.com/MinikubeAddon/watchpod) 相继出品。为了进一步覆盖到这些新的，以及一些相关的已推出的工具，例如 [Weave Flux](https://github.com/weaveworks/flux) 和 OpenShift 的 [S2I](https://docs.openshift.com/container-platform/3.9/creating_images/s2i.html)，我们计划再写一篇跟进的博客。
+
+### Draft
+
+
+<!--
+[Draft](https://github.com/Azure/draft) aims to help you get started deploying any app to Kubernetes. It is capable of applying heuristics as to what programming language your app is written in and generates a Dockerfile along with a Helm chart. It then runs the build for you and deploys resulting image to the target cluster via the Helm chart. It also allows user to setup port forwarding to localhost very easily.
+-->
+
+[Draft](https://github.com/Azure/draft) 旨在帮助您将任何应用程序部署到 Kubernetes。它能够检测到您的应用所使用的编程语言，并且生成一份 Dockerfile 和 Helm 图表。然后它替您启动构建并且依照 Helm 图表把所生产的镜像部署到目标集群。它也可以让您很容易地设置到 localhost 的端口映射。
+
+<!--
+Implications:
+-->
+
+这意味着：
+
+<!--
+* User can customise the chart and Dockerfile templates however they like, or even create a [custom pack](https://github.com/Azure/draft/blob/master/docs/reference/dep-003.md) (with Dockerfile, the chart and more) for future use
+-->
+* 用户可以任意地自定义 Helm 图表和 Dockerfile 模版，或者甚至创建一个 [custom pack](https://github.com/Azure/draft/blob/master/docs/reference/dep-003.md)（使用 Dockerfile、Helm 图表以及其他）以备后用
+
+<!--
+* It’s not very simple to guess how just any app is supposed to be built, in some cases user may need to tweak Dockerfile and the Helm chart that Draft generates
+-->
+* 要想理解一个应用应该怎么构建并不容易，在某些情况下，用户也许需要修改 Draft 生成的 Dockerfile 和 Heml 图表
+
+<!--
+* With [Draft version 0.12.0](https://github.com/Azure/draft/releases/tag/v0.12.0) or older, every time user wants to test a change, they need to wait for Draft to copy the code to the cluster, then run the build, push the image and release updated chart; this can timely, but it results in an image being for every single change made by the user (whether it was committed to git or not)
+-->
+* 如果使用 [Draft version 0.12.0](https://github.com/Azure/draft/releases/tag/v0.12.0)<sup>1</sup> 或者更老版本，每一次用户想要测试一个改动，他们需要等 Draft 把代码拷贝到集群，运行构建，推送镜像并且发布更新后的图表；这些步骤可能进行得很快，但是每一次用户的改动都会产生一个镜像（无论是否提交到 git ）
+
+<!--
+* As of Draft version 0.12.0, builds are executed locally
+* User doesn’t have an option to choose something other than Helm for deployment
+* It can watch local changes and trigger deployments, but this feature is not enabled by default
+-->
+* 在 Draft 0.12.0版本，构建是本地进行的
+* 用户不能选择 Helm 以外的工具进行部署
+* 它可以监控本地的改动并且触发部署，但是这个功能默认是关闭的
+
+<!--
+* It allows developer to use either local or remote Kubernetes cluster
+* Deploying to production is up to the user, Draft authors recommend their other project – Brigade
+* Can be used instead of Skaffold, and along the side of Squash
+-->
+* 它允许开发人员使用本地或者远程的 Kubernates 集群
+* 如何部署到生产环境取决于用户， Draft 的作者推荐了他们的另一个项目 - Brigade
+* 可以代替 Skaffold， 并且可以和 Squash 一起使用
+
+<!--
+More info:
+-->
+
+更多信息：
+
+* [Draft: Kubernetes container development made easy](https://kubernetes.io/blog/2017/05/draft-kubernetes-container-development)
+* [Getting Started Guide](https://github.com/Azure/draft/blob/master/docs/getting-started.md)
+
+【1】：此处疑为 0.11.0，因为 0.12.0 已经支持本地构建，见下一条
+
+### Skaffold
+
+<!--
+[Skaffold](https://github.com/GoogleCloudPlatform/skaffold) is a tool that aims to provide portability for CI integrations with different build system, image registry and deployment tools. It is different from Draft, yet somewhat comparable. It has a basic capability for generating manifests, but it’s not a prominent feature. Skaffold is extendible and lets user pick tools for use in each of the steps in building and deploying their app.
+-->
+
+[Skaffold](https://github.com/GoogleCloudPlatform/skaffold) 让 CI 集成具有可移植性的，它允许用户采用不同的构建系统，镜像仓库和部署工具。它不同于 Draft，同时也具有一定的可比性。它具有生成系统清单的基本能力，但那不是一个重要功能。Skaffold 易于扩展，允许用户在构建和部署应用的每一步选取相应的工具。
+
+<!--
+Implications:
+-->
+
+这意味着：
+
+<!--
+* Modular by design
+* Works independently of CI vendor, user doesn’t need Docker or Kubernetes plugin
+* Works without CI as such, i.e. from the developer’s laptop
+* It can watch local changes and trigger deployments
+-->
+* 模块化设计
+* 不依赖于 CI，用户不需要 Docker 或者 Kubernetes 插件
+* 没有 CI 也可以工作，也就是说，可以在开发人员的电脑上工作
+* 它可以监控本地的改动并且触发部署
+
+<!--
+* It allows developer to use either local or remote Kubernetes cluster
+* It can be used to deploy to production, user can configure how exactly they prefer to do it and provide different kind of pipeline for each target environment
+* Can be used instead of Draft, and along the side with most other tools
+-->
+* 它允许开发人员使用本地或者远程的 Kubernetes 集群
+* 它可以用于部署生产环境，用户可以精确配置，也可以为每一套目标环境提供不同的生产线
+* 可以代替 Draft，并且和其他工具一起使用
+
+<!--
+More info:
+-->
+
+更多信息：
+
+* [Introducing Skaffold: Easy and repeatable Kubernetes development](https://cloudplatform.googleblog.com/2018/03/introducing-Skaffold-Easy-and-repeatable-Kubernetes-development.html)
+* [Getting Started Guide](https://github.com/GoogleCloudPlatform/skaffold#getting-started-with-local-tooling)
+
+### Squash
+
+<!--
+[Squash](https://github.com/solo-io/squash) consists of a debug server that is fully integrated with Kubernetes, and a IDE plugin. It allows you to insert breakpoints and do all the fun stuff you are used to doing when debugging an application using an IDE. It bridges IDE debugging experience with your Kubernetes cluster by allowing you to attach the debugger to a pod running in your Kubernetes cluster.
+-->
+[Squash](https://github.com/solo-io/squash) 包含一个与 Kubernetes 全面集成的调试服务器，以及一个 IDE 插件。它允许您插入断点和所有的调试操作，就像您所习惯的使用 IDE 调试一个程序一般。它允许您将调试器应用到 Kubernetes 集群中运行的 pod 上，从而让您可以使用 IDE 调试 Kubernetes 集群。
+
+<!--
+Implications:
+-->
+
+这意味着：
+
+<!--
+* Can be used independently of other tools you chose
+* Requires a privileged DaemonSet
+* Integrates with popular IDEs
+* Supports Go, Python, Node.js, Java and gdb
+-->
+* 不依赖您选择的其它工具
+* 需要一组特权 DaemonSet
+* 可以和流行 IDE 集成
+* 支持 Go、Python、Node.js、Java 和 gdb
+
+<!--
+* User must ensure application binaries inside the container image are compiled with debug symbols
+* Can be used in combination with any other tools described here
+* It can be used with either local or remote Kubernetes cluster
+-->
+* 用户必须确保容器中的应用程序使编译时使用了调试符号
+* 可与此处描述的任何其他工具结合使用
+* 它可以与本地或远程 Kubernetes 集群一起使用
+
+<!--
+More info:
+-->
+
+更多信息：
+
+* [Squash: A Debugger for Kubernetes Apps](https://www.youtube.com/watch?v=5TrV3qzXlgI)
+* [Getting Started Guide](https://github.com/solo-io/squash/blob/master/docs/getting-started.md)
+
+### Telepresence
+
+<!--
+[Telepresence](https://www.telepresence.io/) connects containers running on developer’s workstation with a remote Kubernetes cluster using a two-way proxy and emulates in-cluster environment as well as provides access to config maps and secrets. It aims to improve iteration time for container app development by eliminating the need for deploying app to the cluster and leverages local container to abstract network and filesystem interface in order to make it appear as if the app was running in the cluster.
+-->
+[Telepresence](https://www.telepresence.io/) 使用双向代理将开发人员工作站上运行的容器与远程 Kubernetes 集群连接起来，并模拟集群内环境以及提供对配置映射和机密的访问。它消除了将应用部署到集群的需要，并利用本地容器抽象出网络和文件系统接口，以使其看起来应用好像就在集群中运行，从而改进容器应用程序开发的迭代时间。
+
+<!--
+Implications:
+-->
+
+这意味着：
+
+<!--
+* It can be used independently of other tools you chose
+* Using together with Squash is possible, although Squash would have to be used for pods in the cluster, while conventional/local debugger would need to be used for debugging local container that’s connected to the cluster via Telepresence
+* Telepresence imposes some network latency
+-->
+* 它不依赖于其它您选取的工具
+* 可以同 Squash 一起使用，但是 Squash 必须用于调试集群中的 pods，而传统/本地调试器需要用于调试通过 Telepresence 连接到集群的本地容器
+* Telepresence 会产生一些网络延迟
+
+<!--
+* It provides connectivity via a side-car process - sshuttle, which is based on SSH
+* More intrusive dependency injection mode with LD_PRELOAD/DYLD_INSERT_LIBRARIES is also available
+* It is most commonly used with a remote Kubernetes cluster, but can be used with a local one also
+-->
+* 它通过辅助进程提供连接 -  sshuttle，基于SSH的一个工具
+* 还提供了使用 LD_PRELOAD/DYLD_INSERT_LIBRARIES 的更具侵入性的依赖注入模式
+* 它最常用于远程 Kubernetes 集群，但也可以与本地集群一起使用
+
+<!--
+More info:
+-->
+
+更多信息：
+
+* [Telepresence: fast, realistic local development for Kubernetes microservices](https://www.telepresence.io/)
+* [Getting Started Guide](https://www.telepresence.io/tutorials/docker)
+* [How It Works](https://www.telepresence.io/discussion/how-it-works)
+
+### Ksync
+
+<!--
+[Ksync](https://github.com/vapor-ware/ksync) synchronizes application code (and configuration) between your local machine and the container running in Kubernetes, akin to what [oc rsync](https://docs.openshift.com/container-platform/3.9/dev_guide/copy_files_to_container.html) does in OpenShift. It aims to improve iteration time for app development by eliminating build and deployment steps.
+-->
+
+
+[Ksync](https://github.com/vapor-ware/ksync) 在本地计算机和运行在 Kubernetes 中的容器之间同步应用程序代码（和配置），类似于 [oc rsync](https://docs.openshift.com/container-platform/3.9/dev_guide/copy_files_to_container.html) 在 OpenShift 中的角色。它旨在通过消除构建和部署步骤来缩短应用程序开发的迭代时间。
+
+
+<!--
+Implications:
+-->
+
+这意味着：
+
+<!--
+* It bypasses container image build and revision control
+* Compiled language users have to run builds inside the pod (TBC)
+* Two-way sync – remote files are copied to local directory
+* Container is restarted each time remote filesystem is updated
+* No security features – development only
+-->
+* 它绕过容器图像构建和修订控制
+* 使用编译语言的用户必须在 pod（TBC）内运行构建
+* 双向同步 - 远程文件会复制到本地目录
+* 每次更新远程文件系统时都会重启容器
+* 无安全功能 - 仅限开发
+
+<!--
+* Utilizes [Syncthing](https://github.com/syncthing/syncthing), a Go library for peer-to-peer sync
+* Requires a privileged DaemonSet running in the cluster
+* Node has to use Docker with overlayfs2 – no other CRI implementations are supported at the time of writing
+-->
+* 使用 [Syncthing](https://github.com/syncthing/syncthing)，一个用于点对点同步的 Go 语言库
+* 需要一个在集群中运行的特权 DaemonSet
+* Node 必须使用带有 overlayfs2 的 Docker  - 在写作本文时，尚不支持其他 CRI 实现
+
+<!--
+More info:
+-->
+
+更多信息：
+
+* [Getting Started Guide](https://github.com/vapor-ware/ksync#getting-started)
+* [How It Works](https://github.com/vapor-ware/ksync/blob/master/docs/architecture.md)
+* [Katacoda scenario to try out ksync in your browser](https://www.katacoda.com/vaporio/scenarios/ksync)
+* [Syncthing Specification](https://docs.syncthing.net/specs/)
+
+<!--
+## Hands-on walkthroughs
+-->
+
+## 实践演练
+
+
+<!--
+The app we will be using for the hands-on walkthroughs of the tools in the following is a simple [stock market simulator](https://github.com/kubernauts/dok-example-us), consisting of two microservices:
+-->
+
+我们接下来用于练习使用工具的应用是一个简单的[股市模拟器](https://github.com/kubernauts/dok-example-us)，包含两个微服务：
+
+<!--
+* The `stock-gen` microservice is written in Go and generates stock data randomly and exposes it via HTTP endpoint `/stockdata`.
+‎* A second microservice, `stock-con` is a Node.js app that consumes the stream of stock data from `stock-gen` and provides an aggregation in form of a moving average via the HTTP endpoint `/average/$SYMBOL` as well as a health-check endpoint at `/healthz`.
+-->
+
+* `stock-gen`（股市数据生成器）微服务是用 Go 编写的，随机生成股票数据并通过 HTTP 端点 `/ stockdata` 公开
+* 第二个微服务，`stock-con`（股市数据消费者）是一个 Node.js 应用程序，它使用来自 `stock-gen` 的股票数据流，并通过 HTTP 端点 `/average/$SYMBOL` 提供股价移动平均线，也提供一个健康检查端点 `/healthz`。
+
+<!--
+Overall, the default setup of the app looks as follows:
+-->
+
+总体上，此应用的默认配置如下图所示：
+
+![Default Setup](/images/blog/2018-05-01-developing-on-kubernetes/dok-architecture_preview.png)
+
+<!--
+In the following we’ll do a hands-on walkthrough for a representative selection of tools discussed above: ksync, Minikube with local build, as well as Skaffold. For each of the tools we do the following:
+-->
+
+在下文中，我们将选取以上讨论的代表性工具进行实践演练：ksync，具有本地构建的 Minikube 以及 Skaffold。对于每个工具，我们执行以下操作：
+
+<!--
+* Set up the respective tool incl. preparations for the deployment and local consumption of the `stock-con` microservice.
+* Perform a code update, that is, change the source code of the `/healthz` endpoint in the `stock-con` microservice and observe the updates.
+-->
+
+* 设置相应的工具，包括部署准备和 `stock-con` 微服务数据的本地读取
+* 执行代码更新，即更改 `stock-con` 微服务的 `/healthz` 端点的源代码并观察网页刷新
+
+<!--
+Note that for the target Kubernetes cluster we’ve been using Minikube locally, but you can also a remote cluster for ksync and Skaffold if you want to follow along.
+-->
+
+请注意，我们一直使用 Minikube 的本地 Kubernetes 集群，但是您也可以使用 ksync 和 Skaffold 的远程集群跟随练习。
+
+<!--
+### Walkthrough: ksync
+-->
+
+### 实践演练：ksync
+
+<!--
+As a preparation, install [ksync](https://vapor-ware.github.io/ksync/#installation) and then carry out the following steps to prepare the development setup:
+-->
+
+作为准备，安装 [ksync](https://vapor-ware.github.io/ksync/#installation)，然后执行以下步骤配置开发环境：
+
+```
+$ mkdir -p $(pwd)/ksync
+$ kubectl create namespace dok
+$ ksync init -n dok
+```
+<!--
+With the basic setup completed we're ready to tell ksync’s local client to watch a certain Kubernetes namespace and then we create a spec to define what we want to sync (the directory `$(pwd)/ksync` locally with `/app` in the container). Note that target pod is specified via the selector parameter:
+-->
+
+
+完成基本设置后，我们可以告诉 ksync 的本地客户端监控 Kubernetes 的某个命名空间，然后我们创建一个规范来定义我们想要同步的文件夹（本地的 `$(pwd)/ksync` 和容器中的 `/ app` ）。请注意，目标 pod 是用 selector 参数指定：
+
+```
+$ ksync watch -n dok
+$ ksync create -n dok --selector=app=stock-con $(pwd)/ksync /app
+$ ksync get -n dok
+```
+
+<!--
+Now we deploy the stock generator and the stock consumer microservice:
+-->
+
+现在我们部署股价数据生成器和股价数据消费者微服务：
+
+```
+$ kubectl -n=dok apply \
+      -f https://raw.githubusercontent.com/kubernauts/dok-example-us/master/stock-gen/app.yaml
+$ kubectl -n=dok apply \
+      -f https://raw.githubusercontent.com/kubernauts/dok-example-us/master/stock-con/app.yaml
+```
+<!--
+Once both deployments are created and the pods are running, we forward the `stock-con` service for local consumption (in a separate terminal session):
+-->
+
+
+一旦两个部署建好并且 pod 开始运行，我们转发 `stock-con` 服务以供本地读取（另开一个终端窗口）：
+
+```
+$ kubectl get -n dok po --selector=app=stock-con  \
+                     -o=custom-columns=:metadata.name --no-headers |  \
+                     xargs -IPOD kubectl -n dok port-forward POD 9898:9898
+```
+<!--
+With that we should be able to consume the `stock-con` service from our local machine; we do this by regularly checking the response of the `healthz` endpoint like so (in a separate terminal session):
+-->
+
+
+这样，通过定期查询 `healthz` 端点，我们就应该能够从本地机器上读取 `stock-con` 服务，查询命令如下（在一个单独的终端窗口）：
+
+```
+$ watch curl localhost:9898/healthz
+```
+<!--
+Now change the code in the `ksync/stock-con`directory, for example update the [`/healthz` endpoint code in `service.js`](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52) by adding a field to the JSON response and observe how the pod gets updated and the response of the `curl localhost:9898/healthz` command changes. Overall you should have something like the following in the end:
+-->
+
+
+现在，改动 `ksync/stock-con` 目录中的代码，例如改动 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52)，在其 JSON 形式的响应中新添一个字段并观察 pod 如何更新以及 `curl localhost：9898/healthz` 命令的输出发生何种变化。总的来说，您最后应该看到类似的内容：
+
+
+![Preview](/images/blog/2018-05-01-developing-on-kubernetes/dok-ksync_preview.png)
+
+
+<!--
+### Walkthrough: Minikube with local build
+-->
+
+### 实践演练：带本地构建的 Minikube
+
+<!--
+For the following you will need to have Minikube up and running and we will leverage the Minikube-internal Docker daemon for building images, locally. As a preparation, do the following
+-->
+
+
+对于以下内容，您需要启动并运行 Minikube，我们将利用 Minikube 自带的 Docker daemon 在本地构建镜像。作为准备，请执行以下操作
+
+```
+$ git clone https://github.com/kubernauts/dok-example-us.git && cd dok-example-us
+$ eval $(minikube docker-env)
+$ kubectl create namespace dok
+```
+
+<!--
+Now we deploy the stock generator and the stock consumer microservice:
+-->
+
+现在我们部署股价数据生成器和股价数据消费者微服务：
+
+
+```
+$ kubectl -n=dok apply -f stock-gen/app.yaml
+$ kubectl -n=dok apply -f stock-con/app.yaml
+```
+<!--
+Once both deployments are created and the pods are running, we forward the `stock-con` service for local consumption (in a separate terminal session):
+-->
+
+
+一旦两个部署建好并且 pod 开始运行，我们转发 `stock-con` 服务以供本地读取（另开一个终端窗口）：
+
+```
+$ kubectl get -n dok po --selector=app=stock-con  \
+                     -o=custom-columns=:metadata.name --no-headers |  \
+                     xargs -IPOD kubectl -n dok port-forward POD 9898:9898 &
+$ watch curl localhost:9898/healthz
+```
+<!--
+Now change the code in the `stock-con`directory, for example, update the [`/healthz` endpoint code in `service.js`](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52) by adding a field to the JSON response. Once you’re done with your code update, the last step is to build a new container image and kick off a new deployment like shown below:
+-->
+
+现在，改一下 `ksync/stock-con` 目录中的代码，例如修改 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52)，在其 JSON 形式的响应中添加一个字段。在您更新完代码后，最后一步是构建新的容器镜像并启动新部署，如下所示：
+
+
+```
+$ docker build -t stock-con:dev -f Dockerfile .
+$ kubectl -n dok set image deployment/stock-con *=stock-con:dev
+```
+<!--
+Overall you should have something like the following in the end:
+-->
+
+总的来说，您最后应该看到类似的内容：
+
+![Local Preview](/images/blog/2018-05-01-developing-on-kubernetes/dok-minikube-localdev_preview.png)
+
+<!--
+### Walkthrough: Skaffold
+-->
+
+### 实践演练：Skaffold
+
+<!--
+To perform this walkthrough you first need to install [Skaffold](https://github.com/GoogleContainerTools/skaffold#installation). Once that is done, you can do the following steps to prepare the development setup:
+-->
+
+要进行此演练，首先需要安装 [Skaffold](https://github.com/GoogleContainerTools/skaffold#installation)。完成后，您可以执行以下步骤来配置开发环境：
+
+```
+$ git clone https://github.com/kubernauts/dok-example-us.git && cd dok-example-us
+$ kubectl create namespace dok
+```
+<!--
+Now we deploy the stock generator (but not the stock consumer microservice, that is done via Skaffold):
+-->
+
+现在我们部署股价数据生成器（但是暂不部署股价数据消费者，此服务将使用 Skaffold 完成）：
+
+```
+$ kubectl -n=dok apply -f stock-gen/app.yaml
+```
+
+<!--
+Note that initially we experienced an authentication error when doing `skaffold dev` and needed to apply a fix as described in [Issue 322](https://github.com/GoogleContainerTools/skaffold/issues/322). Essentially it means changing the content of `~/.docker/config.json` to:
+-->
+
+
+请注意，最初我们在执行 `skaffold dev` 时发生身份验证错误，为避免此错误需要安装[问题322](https://github.com/GoogleContainerTools/skaffold/issues/322) 中所述的修复。本质上，需要将 `〜/.docker/config.json` 的内容改为：
+
+
+```
+{
+   "auths": {}
+}
+```
+
+<!--
+Next, we had to patch `stock-con/app.yaml` slightly to make it work with Skaffold:
+-->
+
+接下来，我们需要略微改动 `stock-con/app.yaml`，这样 Skaffold 才能正常使用此文件：
+
+<!--
+Add a `namespace` field to both the `stock-con` deployment and the service with the value of `dok`.
+Change the `image` field of the container spec to `quay.io/mhausenblas/stock-con` since Skaffold manages the container image tag on the fly.
+-->
+
+在 `stock-con` 部署和服务中添加一个 `namespace` 字段，其值为 `dok`
+
+将容器规范的 `image` 字段更改为 `quay.io/mhausenblas/stock-con`，因为 Skaffold 可以即时管理容器镜像标签。
+
+<!--
+ The resulting `app.yaml` file stock-con looks as follows:
+ -->
+最终的 stock-con 的 `app.yaml` 文件看起来如下：
+
+
+```
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  labels:
+    app: stock-con
+  name: stock-con
+  namespace: dok
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: stock-con
+    spec:
+      containers:
+      - name: stock-con
+        image: quay.io/mhausenblas/stock-con
+        env:
+        - name: DOK_STOCKGEN_HOSTNAME
+          value: stock-gen
+        - name: DOK_STOCKGEN_PORT
+          value: "9999"
+        ports:
+        - containerPort: 9898
+          protocol: TCP
+        livenessProbe:
+          initialDelaySeconds: 2
+          periodSeconds: 5
+          httpGet:
+            path: /healthz
+            port: 9898
+        readinessProbe:
+          initialDelaySeconds: 2
+          periodSeconds: 5
+          httpGet:
+            path: /healthz
+            port: 9898
+---
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: stock-con
+  name: stock-con
+  namespace: dok
+spec:
+  type: ClusterIP
+  ports:
+  - name: http
+    port: 80
+    protocol: TCP
+    targetPort: 9898
+  selector:
+    app: stock-con
+```
+<!--
+The final step before we can start development is to configure Skaffold. So, create a file `skaffold.yaml` in the `stock-con/` directory with the following content:
+ -->
+
+我们能够开始开发之前的最后一步是配置 Skaffold。因此，在 `stock-con/` 目录中创建文件 `skaffold.yaml`，其中包含以下内容：
+
+```
+apiVersion: skaffold/v1alpha2
+kind: Config
+build:
+  artifacts:
+  - imageName: quay.io/mhausenblas/stock-con
+    workspace: .
+    docker: {}
+  local: {}
+deploy:
+  kubectl:
+    manifests:
+      - app.yaml
+```
+<!--
+Now we’re ready to kick off the development. For that execute the following in the `stock-con/` directory:
+ -->
+
+现在我们准备好开始开发了。为此，在 `stock-con/` 目录中执行以下命令：
+
+```
+$ skaffold dev
+```
+<!--
+Above command triggers a build of the `stock-con` image and then a deployment. Once the pod of the `stock-con` deployment is running, we again forward the `stock-con` service for local consumption (in a separate terminal session) and check the response of the `healthz` endpoint:
+ -->
+
+
+上面的命令将触发 `stock-con` 图像的构建和部署。一旦 `stock-con` 部署的 pod 开始运行，我们再次转发 `stock-con` 服务以供本地读取（在单独的终端窗口中）并检查 `healthz` 端点的响应：
+
+```bash
+$ kubectl get -n dok po --selector=app=stock-con  \
+                     -o=custom-columns=:metadata.name --no-headers |  \
+                     xargs -IPOD kubectl -n dok port-forward POD 9898:9898 &
+$ watch curl localhost:9898/healthz
+```
+<!--
+If you now change the code in the `stock-con`directory, for example, by updating the [`/healthz` endpoint code in `service.js`](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52) by adding a field to the JSON response, you should see Skaffold noticing the change and create a new image as well as deploy it. The resulting screen would look something like this:
+ -->
+ 
+现在，如果您修改一下 `stock-con` 目录中的代码，例如 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52)，在其 JSON 形式的响应中添加一个字段，您应该看到 Skaffold 可以检测到代码改动并创建新图像以及部署它。您的屏幕看起来应该类似这样：
+ 
+ 
+![Skaffold Preview](/images/blog/2018-05-01-developing-on-kubernetes/dok-skaffold_preview.png)
+<!--
+By now you should have a feeling how different tools enable you to develop apps on Kubernetes and if you’re interested to learn more about tools and or methods, check out the following resources:
+ -->
+
+至此，您应该对不同的工具如何帮您在 Kubernetes 上开发应用程序有了一定的概念，如果您有兴趣了解有关工具和/或方法的更多信息，请查看以下资源：
+
+* Blog post by Shahidh K Muhammed on [Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold](https://blog.hasura.io/draft-vs-gitkube-vs-helm-vs-ksonnet-vs-metaparticle-vs-skaffold-f5aa9561f948) (03/2018)
+* Blog post by Gergely Nemeth on [Using Kubernetes for Local Development](https://nemethgergely.com/using-kubernetes-for-local-development/index.html), with a focus on Skaffold (03/2018)
+* Blog post by Richard Li on [Locally developing Kubernetes services (without waiting for a deploy)](https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99), with a focus on Telepresence
+* Blog post by Abhishek Tiwari on [Local Development Environment for Kubernetes using Minikube](https://abhishek-tiwari.com/local-development-environment-for-kubernetes-using-minikube/) (09/2017)
+* Blog post by Aymen El Amri on [Using Kubernetes for Local Development — Minikube](https://medium.com/devopslinks/using-kubernetes-minikube-for-local-development-c37c6e56e3db) (08/2017)
+* Blog post by Alexis Richardson on [GitOps - Operations by Pull Request](https://www.weave.works/blog/gitops-operations-by-pull-request) (08/2017)
+* Slide deck [GitOps: Drive operations through git](https://docs.google.com/presentation/d/1d3PigRVt_m5rO89Ob2XZ16bW8lRSkHHH5k816-oMzZo/), with a focus on Gitkube by Tirumarai Selvan (03/2018)
+* Slide deck [Developing apps on Kubernetes](https://speakerdeck.com/mhausenblas/developing-apps-on-kubernetes), a talk Michael Hausenblas gave at a CNCF Paris meetup  (04/2018)
+* YouTube videos:
+    * [TGI Kubernetes 029: Developing Apps with Ksync](https://www.youtube.com/watch?v=QW85Y0Ug3KY )
+    * [TGI Kubernetes 030: Exploring Skaffold](https://www.youtube.com/watch?v=McwwWhCXMxc)
+    * [TGI Kubernetes 031: Connecting with Telepresence](https://www.youtube.com/watch?v=zezeBAJ_3w8)
+    * [TGI Kubernetes 033: Developing with Draft](https://www.youtube.com/watch?v=8B1D7cTMPgA)
+* Raw responses to the [Kubernetes Application Survey](https://docs.google.com/spreadsheets/d/12ilRCly2eHKPuicv1P_BD6z__PXAqpiaR-tDYe2eudE/edit) 2018 by SIG Apps
+
+<!--
+With that we wrap up this post on how to go about developing apps on Kubernetes, we hope you learned something and if you have feedback and/or want to point out a tool that you found useful, please let us know via Twitter: [Ilya](https://twitter.com/errordeveloper) and [Michael](https://twitter.com/mhausenblas).
+-->
+
+有了这些，我们这篇关于如何在 Kubernetes 上开发应用程序的博客就可以收尾了，希望您有所收获，如果您有反馈和/或想要指出您认为有用的工具，请通过 Twitter 告诉我们：[Ilya](https://twitter.com/errordeveloper) 和 [Michael](https://twitter.com/mhausenblas)
@@ -0,0 +1,67 @@
+---
+title: 'Kubernetes 1 11：向 discuss kubernetes 问好'
+layout: blog
+date: 2018-05-30
+---
+
+<!--
+---
+title: ' Kubernetes 1 11：say-hello-to-discuss-kubernetes '
+cn-approvers:
+- congfairy
+layout: blog
+date: 2018-05-30
+---
+-->
+
+<!--   
+
+Author: Jorge Castro (Heptio)
+
+-->
+
+作者: Jorge Castro (Heptio)
+
+<!-- 
+
+Communication is key when it comes to engaging a community of over 35,000 people in a global and remote environment. Keeping track of everything in the Kubernetes community can be an overwhelming task. On one hand we have our official resources, like Stack Overflow, GitHub, and the mailing lists, and on the other we have more ephemeral resources like Slack, where you can hop in, chat with someone, and then go on your merry way. 
+
+-->
+
+就一个超过 35,000 人的全球性社区而言，参与其中时沟通是非常关键的。 跟踪 Kubernetes 社区中的所有内容可能是一项艰巨的任务。 一方面，我们有官方资源，如 Stack Overflow，GitHub 和邮件列表，另一方面，我们有更多瞬时性的资源，如 Slack，你可以加入进去、与某人聊天然后各走各路。
+
+
+<!--
+
+Slack is great for casual and timely conversations and keeping up with other community members, but communication can't be easily referenced in the future. Plus it can be hard to raise your hand in a room filled with 35,000 participants and find a voice. Mailing lists are useful when trying to reach a specific group of people with a particular ask and want to keep track of responses on the thread, but can be daunting with a large amount of people. Stack Overflow and GitHub are ideal for collaborating on projects or questions that involve code and need to be searchable in the future, but certain topics like "What's your favorite CI/CD tool" or "Kubectl tips and tricks" are offtopic there.
+
+While our current assortment of communication channels are valuable in their own rights, we found that there was still a gap between email and real time chat. Across the rest of the web, many other open source projects like Docker, Mozilla, Swift, Ghost, and Chef have had success building communities on top of Discourse, an open source discussion platform. So what if we could use this tool to bring our discussions together under a modern roof, with an open API, and perhaps not let so much of our information fade into the ether? There's only one way to find out: Welcome to discuss.kubernetes.io
+
+-->
+
+Slack 非常适合随意和及时的对话，并与其他社区成员保持联系，但未来很难轻易引用通信。此外，在35,000名参与者中提问并得到回答很难。邮件列表在有问题尝试联系特定人群并且想要跟踪大家的回应时非常有用，但是对于大量人员来说可能是麻烦的。 Stack Overflow 和 GitHub 非常适合在涉及代码的项目或问题上进行协作，并且如果在将来要进行搜索也很有用，但某些主题如“你最喜欢的 CI/CD 工具是什么”或“[Kubectl提示和技巧](http://discuss.kubernetes.io/t/kubectl-tips-and-tricks/192)“在那里是没有意义的。
+
+虽然我们目前的各种沟通渠道对他们自己来说都很有价值，但我们发现电子邮件和实时聊天之间仍然存在差距。在网络的其他部分，许多其他开源项目，如 Docker、Mozilla、Swift、Ghost 和 Chef，已经成功地在[Discourse](http://www.discourse.org/features)之上构建社区，一个开放的讨论平台。那么，如果我们可以使用这个工具将我们的讨论结合在一个平台下，使用开放的API，或许也不会让我们的大部分信息消失在网络中呢？只有一种方法可以找到：欢迎来到[discuss.kubernetes.io](http://discuss.kubernetes.io)
+
+<!--
+
+Right off the bat we have categories that users can browse. Checking and posting in these categories allow users to participate in things they might be interested in without having to commit to subscribing to a list. Granular notification controls allow the users to subscribe to just the category or tag they want, and allow for responding to topics via email. 
+
+Ecosystem partners and developers now have a place where they can [announce projects](https://discuss.kubernetes.io/c/announcements) that they're working on to users without wondering if it would be offtopic on an official list. We can make this place be not just about core Kubernetes, but about the hundreds of wonderful tools our community is building. 
+
+
+This new community forum gives people a place to go where they can discuss Kubernetes, and a sounding board for developers to make announcements of things happening around Kubernetes, all while being searchable and easily accessible to a wider audience. 
+
+Hop in and take a look. We're just getting started, so you might want to begin by [introducing yourself](https://discuss.kubernetes.io/t/introduce-yourself-here/56) and then browsing around. Apps are also available for [Android](https://play.google.com/store/apps/details?id=com.discourse&hl=en_US&rdid=com.discourse&pli=1)and [iOS](https://itunes.apple.com/us/app/discourse-app/id1173672076?mt=8).  
+ 
+
+-->
+
+马上，我们有用户可以浏览的类别。检查和发布这些类别允许用户参与他们可能感兴趣的事情，而无需订阅列表。精细的通知控件允许用户只订阅他们想要的类别或标签，并允许通过电子邮件回复主题。
+
+生态系统合作伙伴和开发人员现在有一个地方可以[宣布项目](http://discuss.kubernetes.io/c/announcements)，他们正在为用户工作，而不会想知道它是否会在官方列表中脱离主题。我们可以让这个地方不仅仅是关于核心 Kubernetes，而是关于我们社区正在建设的数百个精彩工具。
+
+这个新的社区论坛为人们提供了一个可以讨论 Kubernetes 的地方，也是开发人员在 Kubernetes 周围发布事件的声音板，同时可以搜索并且更容易被更广泛的用户访问。
+
+进来看看。我们刚刚开始，所以，您可能希望从[自我介绍](http://discuss.kubernetes.io/t/introduce-yourself-here/56)开始，到处浏览。也有 [Android](http://play.google.com/store/apps/details?id=com.discourse&hl=en_US&rdid=com.discourse&pli=1) 和 [iOS](http://itunes.apple.com/us/app/discourse-app/id1173672076?mt=8) 应用下载。
+
@@ -0,0 +1,42 @@
+---
+title: Kubernetes 这四年
+approvers:
+cn-approvers:
+- congfairy
+layout: blog
+date: 2018-06-06
+---
+ <!--
+**Author**: Joe Beda (CTO and Founder, Heptio)
+ On June 6, 2014 I checked in the [first commit](https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56) of what would become the public repository for Kubernetes. Many would assume that is where the story starts. It is the beginning of history, right? But that really doesn’t tell the whole story.
+-->
+
+ **作者**：Joe Beda( Heptio 首席技术官兼创始人)
+ 2014 年 6 月 6 日，我检查了 Kubernetes 公共代码库的[第一次 commit](https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56) 。许多人会认为这是故事开始的地方。这难道不是一切开始的地方吗？但这的确不能把整个过程说清楚。
+ 
+ ![k8s_first_commit](/images/blog/2018-06-06-4-years-of-k8s/k8s-first-commit.png)
+ 
+ <!--
+The cast leading up to that commit was large and the success for Kubernetes since then is owed to an ever larger cast.
+ Kubernetes was built on ideas that had been proven out at Google over the previous ten years with Borg. And Borg, itself, owed its existence to even earlier efforts at Google and beyond.
+ Concretely, Kubernetes started as some prototypes from Brendan Burns combined with ongoing work from me and Craig McLuckie to better align the internal Google experience with the Google Cloud experience. Brendan, Craig, and I really wanted people to use this, so we made the case to build out this prototype as an open source project that would bring the best ideas from Borg out into the open.
+ After we got the nod, it was time to actually build the system.  We took Brendan’s prototype (in Java), rewrote it in Go, and built just enough to get the core ideas across.  By this time the team had grown to include Ville Aikas, Tim Hockin, Brian Grant, Dawn Chen and Daniel Smith.  Once we had something working, someone had to sign up to clean things up to get it ready for public launch.  That ended up being me. Not knowing the significance at the time, I created a new repo, moved things over, and checked it in.  So while I have the first public commit to the repo, there was work underway well before that.
+ The version of Kubernetes at that point was really just a shadow of what it was to become.  The core concepts were there but it was very raw.  For example, Pods were called Tasks.  That was changed a day before we went public.  All of this led up to the public announcement of Kubernetes on June 10th, 2014 in a keynote from Eric Brewer at the first DockerCon.  You can watch that video here:
+-->
+
+ 第一次 commit 涉及的人员众多，自那以后 Kubernetes 的成功归功于更大的开发者阵容。
+ Kubernetes 建立在过去十年曾经在 Google 的 Borg 集群管理系统中验证过的思路之上。而 Borg 本身也是 Google 和其他公司早期努力的结果。
+ 具体而言，Kubernetes 最初是从 Brendan Burns 的一些原型开始，结合我和 Craig McLuckie 正在进行的工作，以更好地将 Google 内部实践与 Google Cloud 的经验相结合。 Brendan，Craig 和我真的希望人们使用它，所以我们建议将这个原型构建为一个开源项目，将 Borg 的最佳创意带给大家。
+在我们所有人同意后，就开始着手构建这个系统了。我们采用了 Brendan 的原型（Java 语言），用 Go 语言重写了它，并且以上述核心思想去构建该系统。到这个时候，团队已经成长为包括 Ville Aikas，Tim Hockin，Brian Grant，Dawn Chen 和 Daniel Smith。一旦我们有了一些工作需求，有人必须承担一些脱敏的工作，以便为公开发布做好准备。这个角色最终由我承担。当时，我不知道这件事情的重要性，我创建了一个新的仓库，把代码搬过来，然后进行了检查。所以在我第一次提交 public commit 之前，就有工作已经启动了。
+那时 Kubernetes 的版本只是现在版本的简单雏形。核心概念已经有了，但非常原始。例如，Pods 被称为 Tasks，这在我们推广前一天就被替换。2014年6月10日 Eric Brewe 在第一届 DockerCon 上的演讲中正式发布了 Kubernetes 。您可以在此处观看该视频：
+ 
+
+<center><iframe width="560" height="315" src="https://www.youtube.com/embed/YrxnVKZeqK8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe></center>  
+
+ <!--
+ But, however raw, that modest start was enough to pique the interest of a community that started strong and has only gotten stronger.  Over the past four years Kubernetes has exceeded the expectations of all of us that were there early on. We owe the Kubernetes community a huge debt.  The success the project has seen  is based not just on code and technology but also the way that an amazing group of people have come together to create something special.  The best expression of this is the [set of Kubernetes values](https://github.com/kubernetes/steering/blob/master/values.md) that Sarah Novotny helped curate.
+ Here is to another 4 years and beyond! 🎉🎉🎉
+-->
+
+ 但是，无论多么原始，这小小的一步足以激起一个开始强大而且变得更强大的社区的兴趣。在过去的四年里，Kubernetes 已经超出了我们所有人的期望。我们对 Kubernetes 社区的所有人员表示感谢。该项目所取得的成功不仅基于代码和技术，还基于一群出色的人聚集在一起所做的有意义的事情。Sarah Novotny 策划的一套 [Kubernetes 价值观](https://github.com/kubernetes/steering/blob/master/values.md)是以上最好的表现形式。
+ 让我们一起期待下一个4年！🎉🎉🎉
@@ -0,0 +1,129 @@
+---
+title: 'Kubernetes 内的动态 Ingress'
+layout: blog
+---
+
+<!--
+title: Dynamic Ingress in Kubernetes
+date:  2018-06-07
+Author: Richard Li (Datawire)
+-->
+
+作者: Richard Li (Datawire)
+
+<!--
+Kubernetes makes it easy to deploy applications that consist of many microservices, but one of the key challenges with this type of architecture is dynamically routing ingress traffic to each of these services.  One approach is Ambassador, a Kubernetes-native open source API Gateway built on the Envoy Proxy. Ambassador is designed for dynamic environment where services may come and go frequently.
+Ambassador is configured using Kubernetes annotations. Annotations are used to configure specific mappings from a given Kubernetes service to a particular URL. A mapping can include a number of annotations for configuring a route. Examples include rate limiting, protocol, cross-origin request sharing, traffic shadowing, and routing rules.
+-->
+
+Kubernetes 可以轻松部署由许多微服务组成的应用程序，但这种架构的关键挑战之一是动态地将流量路由到这些服务中的每一个。
+一种方法是使用 [Ambassador](https://www.getambassador.io)，
+一个基于 [Envoy Proxy](https://www.envoyproxy.io) 构建的 Kubernetes 原生开源 API 网关。
+Ambassador 专为动态环境而设计，这类环境中的服务可能被频繁添加或删除。
+
+Ambassador 使用 Kubernetes 注解进行配置。
+注解用于配置从给定 Kubernetes 服务到特定 URL 的具体映射关系。
+每个映射中可以包括多个注解，用于配置路由。
+注解的例子有速率限制、协议、跨源请求共享（CORS）、流量影射和路由规则等。
+
+<!--
+## A Basic Ambassador Example
+Ambassador is typically installed as a Kubernetes deployment, and is also available as a Helm chart. To configure Ambassador, create a Kubernetes service with the Ambassador annotations. Here is an example that configures Ambassador to route requests to /httpbin/ to the public httpbin.org service:
+-->
+
+## 一个简单的 Ambassador 示例
+
+Ambassador 通常作为 Kubernetes Deployment 来安装，也可以作为 Helm Chart 使用。
+配置 Ambassador 时，请使用 Ambassador 注解创建 Kubernetes 服务。
+下面是一个例子，用来配置 Ambassador，将针对 /httpbin/ 的请求路由到公共的 httpbin.org 服务：
+
+```
+apiVersion: v1
+kind: Service
+metadata:
+  name: httpbin
+  annotations:
+    getambassador.io/config: |
+      ---
+      apiVersion: ambassador/v0
+      kind:  Mapping
+      name:  httpbin_mapping
+      prefix: /httpbin/
+      service: httpbin.org:80
+      host_rewrite: httpbin.org
+spec:
+  type: ClusterIP
+  ports:
+    - port: 80
+```
+
+<!--
+A mapping object is created with a prefix of /httpbin/ and a service name of httpbin.org. The host_rewrite annotation specifies that the HTTP host header should be set to httpbin.org.
+-->
+
+例子中创建了一个 Mapping 对象，其 prefix 设置为 /httpbin/，service 名称为 httpbin.org。
+其中的 host_rewrite 注解指定 HTTP 的 host 头部字段应设置为 httpbin.org。
+
+<!--
+## Kubeflow
+Kubeflow provides a simple way to easily deploy machine learning infrastructure on Kubernetes. The Kubeflow team needed a proxy that provided a central point of authentication and routing to the wide range of services used in Kubeflow, many of which are ephemeral in nature.
+<center><i>Kubeflow architecture, pre-Ambassador</center></i>
+-->
+
+## Kubeflow
+
+[Kubeflow](https://github.com/kubeflow/kubeflow) 提供了一种简单的方法，用于在 Kubernetes 上轻松部署机器学习基础设施。
+Kubeflow 团队需要一个代理，为 Kubeflow 中所使用的各种服务提供集中化的认证和路由能力；Kubeflow 中许多服务本质上都是生命期很短的。
+
+<center><i>Kubeflow architecture, pre-Ambassador</center></i>
+
+<!--
+## Service configuration
+With Ambassador, Kubeflow can use a distributed model for configuration. Instead of a central configuration file, Ambassador allows each service to configure its route in Ambassador via Kubernetes annotations. Here is a simplified example configuration:
+-->
+
+## 服务配置
+
+有了 Ambassador，Kubeflow 可以使用分布式模型进行配置。
+Ambassador 不使用集中的配置文件，而是允许每个服务通过 Kubernetes 注解在 Ambassador 中配置其路由。
+下面是一个简化的配置示例：
+
+```
+---
+apiVersion: ambassador/v0
+kind:  Mapping
+name: tfserving-mapping-test-post
+prefix: /models/test/
+rewrite: /model/test/:predict
+method: POST
+service: test.kubeflow:8000
+```
+
+<!--
+In this example, the “test” service uses Ambassador annotations to dynamically configure a route to the service, triggered only when the HTTP method is a POST, and the annotation also specifies a rewrite rule.
+-->
+
+示例中，“test” 服务使用 Ambassador 注解来为服务动态配置路由。
+所配置的路由仅在 HTTP 方法是 POST 时触发；注解中同时还给出了一条重写规则。
+
+<!--
+With Ambassador, Kubeflow manages routing easily with Kubernetes annotations. Kubeflow configures a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic  to specific backends. For example, when deploying TensorFlow services,  Kubeflow creates and and annotates a K8s service so that the model will be served at https://<ingress host>/models/<model name>/. Kubeflow can also use the Envoy Proxy to do the actual L7 routing. Using Ambassador, Kubeflow takes advantage of additional routing configuration like URL rewriting and method-based routing.
+If you’re interested in using Ambassador with Kubeflow, the standard Kubeflow install automatically installs and configures Ambassador.
+If you’re interested in using Ambassador as an API Gateway or Kubernetes ingress solution for your non-Kubeflow services, check out the Getting Started with Ambassador guide.
+## Kubeflow and Ambassador
+-->
+
+## Kubeflow 和 Ambassador
+
+通过 Ambassador，Kubeflow 可以使用 Kubernetes 注解轻松管理路由。
+Kubeflow 配置同一个 Ingress 对象，将流量定向到 Ambassador，然后根据需要创建具有 Ambassador 注解的服务，以将流量定向到特定后端。
+例如，在部署 TensorFlow 服务时，Kubeflow 会创建 Kubernetes 服务并为其添加注解，
+以便用户能够在 `https://<ingress主机>/models/<模型名称>/` 处访问到模型本身。
+Kubeflow 还可以使用 Envoy Proxy 来进行实际的 L7 路由。
+通过 Ambassador，Kubeflow 能够更充分地利用 URL 重写和基于方法的路由等额外的路由配置能力。
+
+如果您对在 Kubeflow 中使用 Ambassador 感兴趣，标准的 Kubeflow 安装会自动安装和配置 Ambassador。
+
+如果您有兴趣将 Ambassador 用作 API 网关或 Kubernetes 的 Ingress 解决方案，
+请参阅 [Ambassador 入门指南](https://www.getambassador.io/user-guide/getting-started)。
+
@@ -0,0 +1,241 @@
+<!--
+---
+layout: blog
+title:  'The Machines Can Do the Work, a Story of Kubernetes Testing, CI, and Automating the Contributor Experience'
+date:   2018-08-29
+---
+-->
+
+---
+layout: blog
+title: '机器可以完成这项工作，一个关于 kubernetes 测试、CI 和自动化贡献者体验的故事'
+date: 2019-08-29
+---
+
+<!--
+**Author**: Aaron Crickenberger (Google) and Benjamin Elder (Google)
+-->
+
+**作者**：Aaron Crickenberger（谷歌）和 Benjamin Elder（谷歌）
+
+<!--
+_“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.”_ - [Kubernetes Community Values](https://git.k8s.io/community/values.md#automation-over-process)
+-->
+
+_”大型项目有很多不那么令人兴奋，但却很辛苦的工作。比起辛苦工作，我们更重视把时间花在自动化重复性工作上，如果这项工作无法实现自动化，我们的文化就是承认并奖励所有类型的贡献。然而，英雄主义是不可持续的。“_ - [Kubernetes Community Values](https://git.k8s.io/community/values.md#automation-over-process)
+
+<!--
+Like many open source projects, Kubernetes is hosted on GitHub. We felt the barrier to participation would be lowest if the project lived where developers already worked, using tools and processes developers already knew. Thus the project embraced the service fully: it was the basis of our workflow, our issue tracker, our documentation, our blog platform, our team structure, and more.
+-->
+
+像许多开源项目一样，Kubernetes 托管在 GitHub 上。 如果项目位于在开发人员已经工作的地方，使用的开发人员已经知道的工具和流程，那么参与的障碍将是最低的。 因此，该项目完全接受了这项服务：它是我们工作流程，问题跟踪，文档，博客平台，团队结构等的基础。
+
+<!--
+This strategy worked. It worked so well that the project quickly scaled past its contributors’ capacity as humans. What followed was an incredible journey of automation and innovation. We didn’t just need to rebuild our airplane mid-flight without crashing, we needed to convert it into a rocketship and launch into orbit. We needed machines to do the work.
+-->
+
+这个策略奏效了。 它运作良好，以至于该项目迅速超越了其贡献者的人类能力。 接下来是一次令人难以置信的自动化和创新之旅。 我们不仅需要在飞行途中重建我们的飞机而不会崩溃，我们需要将其转换为火箭飞船并发射到轨道。 我们需要机器来完成这项工作。
+
+<!--
+## The Work
+-->
+
+##　工作
+
+<!--
+Initially, we focused on the fact that we needed to support the sheer volume of tests mandated by a complex distributed system such as Kubernetes. Real world failure scenarios had to be exercised via end-to-end (e2e) tests to ensure proper functionality. Unfortunately, e2e tests were susceptible to flakes (random failures) and took anywhere from an hour to a day to complete.
+-->
+
+最初，我们关注的事实是，我们需要支持复杂的分布式系统（如 Kubernetes）所要求的大量测试。 真实世界中的故障场景必须通过端到端（e2e）测试来执行，确保正确的功能。 不幸的是，e2e 测试容易受到薄片（随机故障）的影响，并且需要花费一个小时到一天才能完成。
+
+<!--
+Further experience revealed other areas where machines could do the work for us:
+-->
+
+进一步的经验揭示了机器可以为我们工作的其他领域：
+
+<!--
+* PR Workflow
+  * Did the contributor sign our CLA?
+  * Did the PR pass tests?
+  * Is the PR mergeable?
+  * Did the merge commit pass tests?
+* Triage
+  * Who should be reviewing PRs?
+  * Is there enough information to route an issue to the right people?
+  * Is an issue still relevant?
+* Project Health
+  * What is happening in the project?
+  * What should we be paying attention to?
+  -->
+
+* Pull Request 工作流程
+  * 贡献者是否签署了我们的 CLA？
+  * Pull Request 通过测试吗？
+  * Pull Request 可以合并吗？
+  * 合并提交是否通过了测试？
+* 鉴别分类
+  * 谁应该审查 Pull Request？
+  * 是否有足够的信息将问题发送给合适的人？
+  * 问题是否依旧存在？
+* 项目健康
+  * 项目中发生了什么？
+  * 我们应该注意什么？
+
+<!--
+As we developed automation to improve our situation, we followed a few guiding principles:
+-->
+
+当我们开发自动化来改善我们的情况时，我们遵循了以下几个指导原则：
+
+<!--
+* Follow the push/pull control loop patterns that worked well for Kubernetes
+* Prefer stateless loosely coupled services that do one thing well
+* Prefer empowering the entire community over empowering a few core contributors
+* Eat our own dogfood and avoid reinventing wheels
+-->
+
+* 遵循适用于 Kubernetes 的推送/拉取控制循环模式
+* 首选无状态松散耦合服务
+* 更倾向于授权整个社区权利，而不是赋予少数核心贡献者权力
+* 做好自己的事，而不要重新造轮子
+
+<!--
+## Enter Prow
+-->
+
+## 了解 Prow
+
+<!--
+This led us to create [Prow](https://git.k8s.io/test-infra/prow) as the central component for our automation. Prow is sort of like an [If This, Then That](https://ifttt.com/) for GitHub events, with a built-in library of [commands](https://prow.k8s.io/command-help), [plugins](https://prow.k8s.io/plugins), and utilities. We built Prow on top of Kubernetes to free ourselves from worrying about resource management and scheduling, and ensure a more pleasant operational experience.
+-->
+
+这促使我们创建 [Prow](https://git.k8s.io/test-infra/prow) 作为我们自动化的核心组件。 Prow有点像 [If This, Then That](https://ifttt.com/) 用于 GitHub 事件， 内置 [commands](https://prow.k8s.io/command-help)， [plugins](https://prow.k8s.io/plugins)， 和实用程序。 我们在  Kubernetes 之上建立了 Prow，让我们不必担心资源管理和日程安排，并确保更愉快的运营体验。
+
+<!--
+Prow lets us do things like:
+-->
+
+Prow 让我们做以下事情：
+
+<!--
+* Allow our community to triage issues/PRs by commenting commands such as “/priority critical-urgent”, “/assign mary” or “/close”
+* Auto-label PRs based on how much code they change, or which files they touch
+* Age out issues/PRs that have remained inactive for too long
+* Auto-merge PRs that meet our PR workflow requirements
+* Run CI jobs defined as [Knative Builds](https://github.com/knative/build), Kubernetes Pods, or Jenkins jobs
+* Enforce org-wide and per-repo GitHub policies like [branch protection](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector) and [GitHub labels](https://github.com/kubernetes/test-infra/tree/master/label_sync)
+-->
+
+* 允许我们的社区通过评论诸如“/priority critical-urgent”，“/assign mary”或“/close”之类的命令对 issues/Pull Requests 进行分类
+* 根据用户更改的代码数量或创建的文件自动标记 Pull Requests
+* 标出长时间保持不活动状态 issues/Pull Requests
+* 自动合并符合我们PR工作流程要求的 Pull Requests
+* 运行定义为[Knative Builds](https://github.com/knative/build)的 Kubernetes Pods或 Jenkins jobs的 CI 作业
+* 实施组织范围和重构 GitHub 仓库策略，如[Knative Builds]（https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector）和[GitHub labels]（https://github.com/kubernetes/test-infra/tree/master/label_sync）
+
+<!--
+Prow was initially developed by the engineering productivity team building Google Kubernetes Engine, and is actively contributed to by multiple members of Kubernetes SIG Testing. Prow has been adopted by several other open source projects, including Istio, JetStack, Knative and OpenShift. [Getting started with Prow](https://github.com/kubernetes/test-infra/blob/master/prow/getting_started.md) takes a Kubernetes cluster and `kubectl apply starter.yaml` (running pods on a Kubernetes cluster).
+-->
+
+Prow最初由构建 Google Kubernetes Engine 的工程效率团队开发，并由 Kubernetes SIG Testing 的多个成员积极贡献。 Prow 已被其他几个开源项目采用，包括 Istio，JetStack，Knative 和 OpenShift。 [Getting started with Prow](https://github.com/kubernetes/test-infra/blob/master/prow/getting_started.md)需要一个 Kubernetes 集群和 `kubectl apply starter.yaml`（在 Kubernetes 集群上运行 pod）。
+
+<!--
+Once we had Prow in place, we began to hit other scaling bottlenecks, and so produced additional tooling to support testing at the scale required by Kubernetes, including:
+-->
+
+一旦我们安装了 Prow，我们就开始遇到其他的问题，因此需要额外的工具以支持 Kubernetes 所需的规模测试，包括：
+
+<!--
+- [Boskos](https://github.com/kubernetes/test-infra/tree/master/boskos): manages job resources (such as GCP projects) in pools, checking them out for jobs and cleaning them up automatically ([with monitoring](http://velodrome.k8s.io/dashboard/db/boskos-dashboard?orgId=1))
+- [ghProxy](https://github.com/kubernetes/test-infra/tree/master/ghproxy): a reverse proxy HTTP cache optimized for use with the GitHub API, to ensure our token usage doesn’t hit API limits ([with monitoring](http://velodrome.k8s.io/dashboard/db/github-cache?refresh=1m&orgId=1))
+- [Greenhouse](https://github.com/kubernetes/test-infra/tree/master/greenhouse): allows us to use a remote bazel cache to provide faster build and test results for PRs ([with monitoring](http://velodrome.k8s.io/dashboard/db/bazel-cache?orgId=1))
+- [Splice](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/splice): allows us to test and merge PRs in a batch, ensuring our merge velocity is not limited to our test velocity
+- [Tide](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/tide): allows us to merge PRs selected via GitHub queries rather than ordered in a queue, allowing for significantly higher merge velocity in tandem with splice
+-->
+
+- [Boskos](https://github.com/kubernetes/test-infra/tree/master/boskos): 管理池中的作业资源（例如 GCP 项目），检查它们是否有工作并自动清理它们 ([with monitoring](http://velodrome.k8s.io/dashboard/db/boskos-dashboard?orgId=1))
+- [ghProxy](https://github.com/kubernetes/test-infra/tree/master/ghproxy): 优化用于 GitHub API 的反向代理 HTTP 缓存，以确保我们的令牌使用不会达到 API 限制 ([with monitoring](http://velodrome.k8s.io/dashboard/db/github-cache?refresh=1m&orgId=1))
+- [Greenhouse](https://github.com/kubernetes/test-infra/tree/master/greenhouse): 允许我们使用远程 bazel 缓存为 Pull requests 提供更快的构建和测试结果 ([with monitoring](http://velodrome.k8s.io/dashboard/db/bazel-cache?orgId=1))
+- [Splice](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/splice): 允许我们批量测试和合并 Pull requests，确保我们的合并速度不仅限于我们的测试速度
+- [Tide](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/tide): 允许我们合并通过 GitHub 查询选择的 Pull requests，而不是在队列中排序，允许显着更高合并速度与拼接一起
+
+<!--
+## Scaling Project Health
+-->
+
+##　关注项目健康状况
+
+<!--
+With workflow automation addressed, we turned our attention to project health. We chose to use Google Cloud Storage (GCS) as our source of truth for all test data, allowing us to lean on established infrastructure, and allowed the community to contribute results. We then built a variety of tools to help individuals and the project as a whole make sense of this data, including:
+-->
+
+随着工作流自动化的实施，我们将注意力转向了项目健康。我们选择使用 Google Cloud Storage (GCS)作为所有测试数据的真实来源，允许我们依赖已建立的基础设施，并允许社区贡献结果。然后，我们构建了各种工具来帮助个人和整个项目理解这些数据，包括：
+
+<!--
+* [Gubernator](https://github.com/kubernetes/test-infra/tree/master/gubernator): display the results and test history for a given PR
+* [Kettle](https://github.com/kubernetes/test-infra/tree/master/kettle): transfer data from GCS to a publicly accessible bigquery dataset
+* [PR dashboard](https://k8s-gubernator.appspot.com/pr): a workflow-aware dashboard that allows contributors to understand which PRs require attention and why
+* [Triage](https://storage.googleapis.com/k8s-gubernator/triage/index.html): identify common failures that happen across all jobs and tests
+* [Testgrid](https://k8s-testgrid.appspot.com/): display test results for a given job across all runs, summarize test results across groups of jobs
+-->
+
+* [Gubernator](https://github.com/kubernetes/test-infra/tree/master/gubernator): 显示给定 Pull Request 的结果和测试历史
+* [Kettle](https://github.com/kubernetes/test-infra/tree/master/kettle): 将数据从 GCS 传输到可公开访问的 bigquery 数据集
+* [PR dashboard](https://k8s-gubernator.appspot.com/pr): 一个工作流程识别仪表板，允许参与者了解哪些 Pull Request 需要注意以及为什么
+* [Triage](https://storage.googleapis.com/k8s-gubernator/triage/index.html): 识别所有作业和测试中发生的常见故障
+* [Testgrid](https://k8s-testgrid.appspot.com/): 显示所有运行中给定作业的测试结果，汇总各组作业的测试结果
+
+<!--
+We approached the Cloud Native Computing Foundation (CNCF) to develop DevStats to glean insights from our GitHub events such as:
+-->
+
+我们与云计算本地计算基金会（CNCF）联系，开发 DevStats，以便从我们的 GitHub 活动中收集见解，例如：
+
+<!--
+* [Which prow commands are people most actively using](https://k8s.devstats.cncf.io/d/5/bot-commands-repository-groups?orgId=1)
+* [PR reviews by contributor over time](https://k8s.devstats.cncf.io/d/46/pr-reviews-by-contributor?orgId=1&var-period=d7&var-repo_name=All&var-reviewers=All)
+* [Time spent in each phase of our PR workflow](https://k8s.devstats.cncf.io/d/44/pr-time-to-approve-and-merge?orgId=1)
+-->
+
+* [Which prow commands are people most actively using](https://k8s.devstats.cncf.io/d/5/bot-commands-repository-groups?orgId=1)
+* [PR reviews by contributor over time](https://k8s.devstats.cncf.io/d/46/pr-reviews-by-contributor?orgId=1&var-period=d7&var-repo_name=All&var-reviewers=All)
+* [Time spent in each phase of our PR workflow](https://k8s.devstats.cncf.io/d/44/pr-time-to-approve-and-merge?orgId=1)
+
+<!--
+## Into the Beyond
+-->
+
+## Into the Beyond
+
+<!--
+Today, the Kubernetes project spans over 125 repos across five orgs. There are 31 Special Interests Groups and 10 Working Groups coordinating development within the project. In the last year the project has had [participation from over 13,800 unique developers](https://k8s.devstats.cncf.io/d/13/developer-activity-counts-by-repository-group?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All) on GitHub.
+-->
+
+今天，Kubernetes 项目跨越了5个组织125个仓库。有31个特殊利益集团和10个工作组在项目内协调发展。在过去的一年里，该项目有 [来自13800多名独立开发人员的参与](https://k8s.devstats.cncf.io/d/13/developer-activity-counts-by-repository-group?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All)。
+
+<!--
+On any given weekday our Prow instance [runs over 10,000 CI jobs](http://velodrome.k8s.io/dashboard/db/bigquery-metrics?panelId=10&fullscreen&orgId=1&from=now-6M&to=now); from March 2017 to March 2018 it ran 4.3 million jobs. Most of these jobs involve standing up an entire Kubernetes cluster, and exercising it using real world scenarios. They allow us to ensure all supported releases of Kubernetes work across cloud providers, container engines, and networking plugins. They make sure the latest releases of Kubernetes work with various optional features enabled, upgrade safely, meet performance requirements, and work across architectures.
+-->
+
+在任何给定的工作日，我们的 Prow 实例[运行超过10,000个 CI 工作](http://velodrome.k8s.io/dashboard/db/bigquery-metrics?panelId=10&fullscreen&orgId=1&from=now-6M&to=now); 从2017年3月到2018年3月，它有430万个工作岗位。 这些工作中的大多数涉及建立整个 Kubernetes 集群，并使用真实场景来实施它。 它们使我们能够确保所有受支持的 Kubernetes 版本跨云提供商，容器引擎和网络插件工作。 他们确保最新版本的 Kubernetes 能够启用各种可选功能，安全升级，满足性能要求，并跨架构工作。
+
+<!--
+With today’s [announcement from CNCF](https://www.cncf.io/announcement/2018/08/29/cncf-receives-9-million-cloud-credit-grant-from-google) – noting that Google Cloud has begun transferring ownership and management of the Kubernetes project’s cloud resources to CNCF community contributors, we are excited to embark on another journey. One that allows the project infrastructure to be owned and operated by the community of contributors, following the same open governance model that has worked for the rest of the project. Sound exciting to you? Come talk to us at #sig-testing on kubernetes.slack.com.
+-->
+
+今天[来自CNCF的公告](https://www.cncf.io/announcement/2018/08/29/cncf-receives-9-million-cloud-credit-grant-from-google) - 注意到    Google Cloud 有开始将 Kubernetes 项目的云资源的所有权和管理权转让给 CNCF 社区贡献者，我们很高兴能够开始另一个旅程。 允许项目基础设施由贡献者社区拥有和运营，遵循对项目其余部分有效的相同开放治理模型。 听起来令人兴奋。 请来 kubernetes.slack.com 上的 #sig-testing on kubernetes.slack.com 与我们联系。
+
+<!--
+Want to find out more? Come check out these resources:
+-->
+
+想了解更多？ 快来看看这些资源：
+
+<!--
+* [Prow: Testing the way to Kubernetes Next](https://bentheelder.io/posts/prow)
+* [Automation and the Kubernetes Contributor Experience](https://www.youtube.com/watch?v=BsIC7gPkH5M)
+-->
+
+* [Prow: Testing the way to Kubernetes Next](https://bentheelder.io/posts/prow)
+* [Automation and the Kubernetes Contributor Experience](https://www.youtube.com/watch?v=BsIC7gPkH5M)
@@ -0,0 +1,306 @@
+---
+layout: blog
+title: 'KubeDirector：在 Kubernetes 上运行复杂状态应用程序的简单方法'
+date: 2018-10-03
+---
+
+<!--
+layout: blog
+title: 'KubeDirector: The easy way to run complex stateful applications on Kubernetes'
+date: 2018-10-03
+-->
+
+<!--
+**Author**: Thomas Phelan (BlueData)
+-->
+
+**作者**：Thomas Phelan（BlueData）
+
+<!--
+KubeDirector is an open source project designed to make it easy to run complex stateful scale-out application clusters on Kubernetes. KubeDirector is built using the custom resource definition (CRD) framework and leverages the native Kubernetes API extensions and design philosophy. This enables transparent integration with Kubernetes user/resource management as well as existing clients and tools.
+-->
+KubeDirector 是一个开源项目，旨在简化在 Kubernetes 上运行复杂的有状态扩展应用程序集群。KubeDirector 使用自定义资源定义（CRD）
+框架构建，并利用了本地 Kubernetes API 扩展和设计哲学。这支持与 Kubernetes 用户/资源 管理以及现有客户端和工具的透明集成。
+
+<!--
+We recently [introduced the KubeDirector project](https://medium.com/@thomas_phelan/operation-stateful-introducing-bluek8s-and-kubernetes-director-aa204952f619/), as part of a broader open source Kubernetes initiative we call BlueK8s. I’m happy to announce that the pre-alpha
+code for [KubeDirector](https://github.com/bluek8s/kubedirector/) is now available. And in this blog post, I’ll show how it works.
+-->
+我们最近[介绍了 KubeDirector 项目](https://medium.com/@thomas_phelan/operation-stateful-introducing-bluek8s-and-kubernetes-director-aa204952f619/)，作为我们称为 BlueK8s 的更广泛的 Kubernetes 开源项目的一部分。我很高兴地宣布 [KubeDirector](https://github.com/bluek8s/kubedirector/) 的
+pre-alpha 代码现在已经可用。在这篇博客文章中，我将展示它是如何工作的。
+
+<!--
+KubeDirector provides the following capabilities:
+-->
+KubeDirector 提供以下功能：
+
+<!--
+*	The ability to run non-cloud native stateful applications on Kubernetes without modifying the code. In other words, it’s not necessary to decompose these existing applications to fit a microservices design pattern.
+*	Native support for preserving application-specific configuration and state.
+*	An application-agnostic deployment pattern, minimizing the time to onboard new stateful applications to Kubernetes.
+-->
+
+*	无需修改代码即可在 Kubernetes 上运行非云原生有状态应用程序。换句话说，不需要分解这些现有的应用程序来适应微服务设计模式。
+*	本机支持保存特定于应用程序的配置和状态。
+*	与应用程序无关的部署模式，最大限度地减少将新的有状态应用程序装载到 Kubernetes 的时间。
+
+<!--
+KubeDirector enables data scientists familiar with data-intensive distributed applications such as Hadoop, Spark, Cassandra, TensorFlow, Caffe2, etc. to run these applications on Kubernetes -- with a minimal learning curve and no need to write GO code. The applications controlled by KubeDirector are defined by some basic metadata and an associated package of configuration artifacts.  The application metadata is referred to as a KubeDirectorApp resource.
+-->
+KubeDirector 使熟悉数据密集型分布式应用程序（如 Hadoop、Spark、Cassandra、TensorFlow、Caffe2 等）的数据科学家能够在 Kubernetes 上运行这些应用程序 -- 只需极少的学习曲线，无需编写 GO 代码。由 KubeDirector 控制的应用程序由一些基本元数据和相关的配置工件包定义。应用程序元数据称为 KubeDirectorApp 资源。
+
+<!--
+To understand the components of KubeDirector, clone the repository on [GitHub](https://github.com/bluek8s/kubedirector/) using a command similar to:
+-->
+要了解 KubeDirector 的组件，请使用类似于以下的命令在 [GitHub](https://github.com/bluek8s/kubedirector/) 上克隆存储库：
+
+```
+git clone http://<userid>@github.com/bluek8s/kubedirector.
+```
+
+<!--
+The KubeDirectorApp definition for the Spark 2.2.1 application is located
+in the file `kubedirector/deploy/example_catalog/cr-app-spark221e2.json`.
+-->
+Spark 2.2.1 应用程序的 KubeDirectorApp 定义位于文件 `kubedirector/deploy/example_catalog/cr-app-spark221e2.json` 中。
+
+ ```
+ ~> cat kubedirector/deploy/example_catalog/cr-app-spark221e2.json
+ {
+    "apiVersion": "kubedirector.bluedata.io/v1alpha1",
+    "kind": "KubeDirectorApp",
+    "metadata": {
+        "name" : "spark221e2"
+    },
+    "spec" : {
+        "systemctlMounts": true,
+        "config": {
+            "node_services": [
+                {
+                    "service_ids": [
+                        "ssh",
+                        "spark",
+                        "spark_master",
+                        "spark_worker"
+                    ],
+…
+```
+
+<!--
+The configuration of an application cluster is referred to as a KubeDirectorCluster resource. The
+KubeDirectorCluster definition for a sample Spark 2.2.1 cluster is located in the file
+`kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml`.
+-->
+应用程序集群的配置称为 KubeDirectorCluster 资源。示例 Spark 2.2.1 集群的 KubeDirectorCluster 定义位于文件
+`kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml` 中。
+
+```
+~> cat kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml
+apiVersion: "kubedirector.bluedata.io/v1alpha1"
+kind: "KubeDirectorCluster"
+metadata:
+  name: "spark221e2"
+spec:
+  app: spark221e2
+  roles:
+  - name: controller
+    replicas: 1
+    resources:
+      requests:
+        memory: "4Gi"
+        cpu: "2"
+      limits:
+        memory: "4Gi"
+        cpu: "2"
+  - name: worker
+    replicas: 2
+    resources:
+      requests:
+        memory: "4Gi"
+        cpu: "2"
+      limits:
+        memory: "4Gi"
+        cpu: "2"
+  - name: jupyter
+…
+```
+
+<!--
+## Running Spark on Kubernetes with KubeDirector
+-->
+
+## 使用 KubeDirector 在 Kubernetes 上运行 Spark
+
+<!--
+With KubeDirector, it’s easy to run Spark clusters on Kubernetes.
+-->
+使用 KubeDirector，可以轻松在 Kubernetes 上运行 Spark 集群。
+
+<!--
+First, verify that Kubernetes (version 1.9 or later) is running, using the command `kubectl version`
+-->
+首先，使用命令 `kubectl version` 验证 Kubernetes（版本 1.9 或更高）是否正在运行
+
+```
+~> kubectl version
+Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T18:02:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
+Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}                                    
+```
+
+<!--
+Deploy the KubeDirector service and the example KubeDirectorApp resource definitions with the commands:
+-->
+使用以下命令部署 KubeDirector 服务和示例 KubeDirectorApp 资源定义：
+
+```
+cd kubedirector
+make deploy
+```
+
+<!--
+These will start the KubeDirector pod:
+-->
+这些将启动 KubeDirector pod：
+
+```
+~> kubectl get pods
+NAME                           READY     STATUS     RESTARTS     AGE
+kubedirector-58cf59869-qd9hb   1/1       Running    0            1m     
+```
+
+<!--
+List the installed KubeDirector applications with `kubectl get KubeDirectorApp`
+-->
+`kubectl get KubeDirectorApp` 列出中已安装的 KubeDirector 应用程序
+
+```
+~> kubectl get KubeDirectorApp
+NAME           AGE
+cassandra311   30m
+spark211up     30m
+spark221e2     30m
+```
+
+<!--
+Now you can launch a Spark 2.2.1 cluster using the example KubeDirectorCluster file and the
+`kubectl create -f deploy/example_clusters/cr-cluster-spark211up.yaml` command.
+Verify that the Spark cluster has been started:
+-->
+现在，您可以使用示例 KubeDirectorCluster 文件和 `kubectl create -f deploy/example_clusters/cr-cluster-spark211up.yaml` 命令
+启动 Spark 2.2.1 集群。验证 Spark 集群已经启动:
+
+```
+~> kubectl get pods
+NAME                             READY     STATUS    RESTARTS   AGE
+kubedirector-58cf59869-djdwl     1/1       Running   0          19m
+spark221e2-controller-zbg4d-0    1/1       Running   0          23m
+spark221e2-jupyter-2km7q-0       1/1       Running   0          23m
+spark221e2-worker-4gzbz-0        1/1       Running   0          23m
+spark221e2-worker-4gzbz-1        1/1       Running   0          23m
+```
+
+<!--
+The running services now include the Spark services:
+-->
+现在运行的服务包括 Spark 服务：
+
+```
+~> kubectl get service
+NAME                                TYPE         CLUSTER-IP        EXTERNAL-IP    PORT(S)                                                    AGE
+kubedirector                        ClusterIP    10.98.234.194     <none>         60000/TCP                                                  1d
+kubernetes                          ClusterIP    10.96.0.1         <none>         443/TCP                                                    1d
+svc-spark221e2-5tg48                ClusterIP    None              <none>         8888/TCP                                                   21s
+svc-spark221e2-controller-tq8d6-0   NodePort     10.104.181.123    <none>         22:30534/TCP,8080:31533/TCP,7077:32506/TCP,8081:32099/TCP  20s
+svc-spark221e2-jupyter-6989v-0      NodePort     10.105.227.249    <none>         22:30632/TCP,8888:30355/TCP                                20s
+svc-spark221e2-worker-d9892-0       NodePort     10.107.131.165    <none>         22:30358/TCP,8081:32144/TCP                                20s
+svc-spark221e2-worker-d9892-1       NodePort     10.110.88.221     <none>         22:30294/TCP,8081:31436/TCP                                20s
+```
+
+<!--
+Pointing the browser at port 31533 connects to the Spark Master UI:
+-->
+将浏览器指向端口 31533 连接到 Spark 主节点 UI：
+
+![kubedirector](/images/blog/2018-10-03-kubedirector/kubedirector.png)
+
+<!--
+That’s all there is to it!
+In fact, in the example above we also deployed a Jupyter notebook along with the Spark cluster.
+-->
+就是这样!
+事实上，在上面的例子中，我们还部署了一个 Jupyter notebook 和 Spark 集群。
+
+<!--
+To start another application (e.g. Cassandra), just specify another KubeDirectorApp file:
+-->
+要启动另一个应用程序（例如 Cassandra），只需指定另一个 KubeDirectorApp 文件：
+
+```
+kubectl create -f deploy/example_clusters/cr-cluster-cassandra311.yaml
+```
+
+<!--
+See the running Cassandra cluster:
+-->
+查看正在运行的 Cassandra 集群：
+
+```
+~> kubectl get pods
+NAME                              READY     STATUS    RESTARTS   AGE
+cassandra311-seed-v24r6-0         1/1       Running   0          1m
+cassandra311-seed-v24r6-1         1/1       Running   0          1m
+cassandra311-worker-rqrhl-0       1/1       Running   0          1m
+cassandra311-worker-rqrhl-1       1/1       Running   0          1m
+kubedirector-58cf59869-djdwl      1/1       Running   0          1d
+spark221e2-controller-tq8d6-0     1/1       Running   0          22m
+spark221e2-jupyter-6989v-0        1/1       Running   0          22m
+spark221e2-worker-d9892-0         1/1       Running   0          22m
+spark221e2-worker-d9892-1         1/1       Running   0          22m
+```
+
+<!--
+Now you have a Spark cluster (with a Jupyter notebook) and a Cassandra cluster running on Kubernetes.
+Use `kubectl get service` to see the set of services.
+-->
+现在，您有一个 Spark 集群（带有 Jupyter notebook ）和一个运行在 Kubernetes 上的 Cassandra 集群。
+使用 `kubectl get service` 查看服务集。
+
+```
+~> kubectl get service
+NAME                                TYPE         CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                   AGE
+kubedirector                        ClusterIP    10.98.234.194    <none>        60000/TCP                                                 1d
+kubernetes                          ClusterIP    10.96.0.1        <none>        443/TCP                                                   1d
+svc-cassandra311-seed-v24r6-0       NodePort     10.96.94.204     <none>        22:31131/TCP,9042:30739/TCP                               3m
+svc-cassandra311-seed-v24r6-1       NodePort     10.106.144.52    <none>        22:30373/TCP,9042:32662/TCP                               3m
+svc-cassandra311-vhh29              ClusterIP    None             <none>        8888/TCP                                                  3m
+svc-cassandra311-worker-rqrhl-0     NodePort     10.109.61.194    <none>        22:31832/TCP,9042:31962/TCP                               3m
+svc-cassandra311-worker-rqrhl-1     NodePort     10.97.147.131    <none>        22:31454/TCP,9042:31170/TCP                               3m
+svc-spark221e2-5tg48                ClusterIP    None             <none>        8888/TCP                                                  24m
+svc-spark221e2-controller-tq8d6-0   NodePort     10.104.181.123   <none>        22:30534/TCP,8080:31533/TCP,7077:32506/TCP,8081:32099/TCP 24m
+svc-spark221e2-jupyter-6989v-0      NodePort     10.105.227.249   <none>        22:30632/TCP,8888:30355/TCP                               24m
+svc-spark221e2-worker-d9892-0       NodePort     10.107.131.165   <none>        22:30358/TCP,8081:32144/TCP                               24m
+svc-spark221e2-worker-d9892-1       NodePort     10.110.88.221    <none>        22:30294/TCP,8081:31436/TCP                               24m
+```
+
+<!--
+## Get Involved
+-->
+
+## 参与其中
+
+<!--
+KubeDirector is a fully open source, Apache v2 licensed, project – the first of multiple open source projects within a broader initiative we call BlueK8s.
+The pre-alpha code for KubeDirector has just been released and we would love for you to join the growing community of developers, contributors, and adopters.
+Follow [@BlueK8s](https://twitter.com/BlueK8s/) on Twitter and get involved through these channels:
+-->
+KubeDirector 是一个完全开放源码的 Apache v2 授权项目 – 在我们称为 BlueK8s 的更广泛的计划中，它是多个开放源码项目中的第一个。
+KubeDirector 的 pre-alpha 代码刚刚发布，我们希望您加入到不断增长的开发人员、贡献者和使用者社区。
+在 Twitter 上关注 [@BlueK8s](https://twitter.com/BlueK8s/)，并通过以下渠道参与:
+
+<!--
+* KubeDirector [chat room on Slack](https://join.slack.com/t/bluek8s/shared_invite/enQtNDUwMzkwODY5OTM4LTRhYmRmZmE4YzY3OGUzMjA1NDg0MDVhNDQ2MGNkYjRhM2RlMDNjMTI1NDQyMjAzZGVlMDFkNThkNGFjZGZjMGY/)
+*	KubeDirector [GitHub repo](https://github.com/bluek8s/kubedirector/)
+-->
+
+* KubeDirector [Slack 聊天室](https://join.slack.com/t/bluek8s/shared_invite/enQtNDUwMzkwODY5OTM4LTRhYmRmZmE4YzY3OGUzMjA1NDg0MDVhNDQ2MGNkYjRhM2RlMDNjMTI1NDQyMjAzZGVlMDFkNThkNGFjZGZjMGY/)
+*	KubeDirector [GitHub 仓库](https://github.com/bluek8s/kubedirector/)
@@ -0,0 +1,268 @@
+---
+layout: blog
+title: 'Kubernetes 中的拓扑感知数据卷供应'
+date: 2018-10-11
+---
+<!--
+---
+layout: blog
+title: 'Topology-Aware Volume Provisioning in Kubernetes'
+date: 2018-10-11
+---
+-->
+
+<!--
+**Author**: Michelle Au (Google)
+-->
+**作者**: Michelle Au（谷歌）
+
+<!--
+The multi-zone cluster experience with persistent volumes is improving in Kubernetes 1.12 with the topology-aware dynamic provisioning beta feature. This feature allows Kubernetes to make intelligent decisions when dynamically provisioning volumes by getting scheduler input on the best place to provision a volume for a pod.  In multi-zone clusters, this means that volumes will get provisioned in an appropriate zone that can run your pod, allowing you to easily deploy and scale your stateful workloads across failure domains to provide high availability and fault tolerance.
+-->
+通过提供拓扑感知动态卷供应功能，具有持久卷的多区域集群体验在 Kubernetes 1.12 中得到了改进。此功能使得 Kubernetes 在动态供应卷时能做出明智的决策，方法是从调度器获得为 Pod 提供数据卷的最佳位置。在多区域集群环境，这意味着数据卷能够在满足你的 Pod 运行需要的合适的区域被供应，从而允许您跨故障域轻松部署和扩展有状态工作负载，从而提供高可用性和容错能力。
+
+<!--
+## Previous challenges
+-->
+## 以前的挑战
+
+<!--
+Before this feature, running stateful workloads with zonal persistent disks (such as AWS ElasticBlockStore, Azure Disk, GCE PersistentDisk) in multi-zone clusters had many challenges. Dynamic provisioning was handled independently from pod scheduling, which meant that as soon as you created a PersistentVolumeClaim (PVC), a volume would get provisioned. This meant that the provisioner had no knowledge of what pods were using the volume, and any pod constraints it had that could impact scheduling.
+-->
+在此功能被提供之前，在多区域集群中使用区域化的持久磁盘（例如 AWS ElasticBlockStore，Azure Disk，GCE PersistentDisk）运行有状态工作负载存在许多挑战。动态供应独立于 Pod 调度处理，这意味着只要您创建了一个 PersistentVolumeClaim（PVC），一个卷就会被供应。这也意味着供应者不知道哪些 Pod 正在使用该卷，也不清楚任何可能影响调度的 Pod 约束。
+
+<!--
+This resulted in unschedulable pods because volumes were provisioned in zones that:
+-->
+这导致了不可调度的 Pod，因为在以下区域中配置了卷：
+
+<!--
+* did not have enough CPU or memory resources to run the pod
+* conflicted with node selectors, pod affinity or anti-affinity policies
+* could not run the pod due to taints
+-->
+* 没有足够的 CPU 或内存资源来运行 Pod
+* 与节点选择器、Pod 亲和或反亲和策略冲突
+* 由于污点（taint）不能运行 Pod
+
+<!--
+Another common issue was that a non-StatefulSet pod using multiple persistent volumes could have each volume provisioned in a different zone, again resulting in an unschedulable pod.
+-->
+另一个常见问题是，使用多个持久卷的非有状态 Pod 可能会在不同的区域中配置每个卷，从而导致一个不可调度的 Pod。
+
+<!--
+Suboptimal workarounds included overprovisioning of nodes, or manual creation of volumes in the correct zones, making it difficult to dynamically deploy and scale stateful workloads.
+-->
+次优的解决方法包括节点超配，或在正确的区域中手动创建卷，但这会造成难以动态部署和扩展有状态工作负载的问题。
+
+<!--
+The topology-aware dynamic provisioning feature addresses all of the above issues.
+-->
+拓扑感知动态供应功能解决了上述所有问题。
+
+<!--
+## Supported Volume Types
+-->
+## 支持的卷类型
+
+<!--
+In 1.12, the following drivers support topology-aware dynamic provisioning:
+-->
+在 1.12 中，以下驱动程序支持拓扑感知动态供应：
+
+<!--
+* AWS EBS
+* Azure Disk
+* GCE PD (including Regional PD)
+* CSI (alpha) - currently only the GCE PD CSI driver has implemented topology support
+-->
+* AWS EBS
+* Azure Disk
+* GCE PD （包括 Regional PD）
+* CSI（alpha） - 目前只有 GCE PD CSI 驱动实现了拓扑支持
+
+<!--
+## Design Principles
+-->
+## 设计原则
+
+<!--
+While the initial set of supported plugins are all zonal-based, we designed this feature to adhere to the Kubernetes principle of portability across environments. Topology specification is generalized and uses a similar label-based specification like in Pod nodeSelectors and nodeAffinity. This mechanism allows you to define your own topology boundaries, such as racks in on-premise clusters, without requiring modifications to the scheduler to understand these custom topologies.
+-->
+虽然最初支持的插件集都是基于区域的，但我们设计此功能时遵循 Kubernetes 跨环境可移植性的原则。
+拓扑规范是通用的，并使用类似于基于标签的规范，如 Pod nodeSelectors 和 nodeAffinity。
+该机制允许您定义自己的拓扑边界，例如内部部署集群中的机架，而无需修改调度程序以了解这些自定义拓扑。
+
+<!--
+In addition, the topology information is abstracted away from the pod specification, so a pod does not need knowledge of the underlying storage system’s topology characteristics. This means that you can use the same pod specification across multiple clusters, environments, and storage systems.
+-->
+此外，拓扑信息是从 Pod 规范中抽象出来的，因此 Pod 不需要了解底层存储系统的拓扑特征。
+这意味着您可以在多个集群、环境和存储系统中使用相同的 Pod 规范。
+
+<!--
+## Getting Started
+-->
+## 入门
+
+<!--
+To enable this feature, all you need to do is to create a StorageClass with `volumeBindingMode` set to `WaitForFirstConsumer`:
+-->
+要启用此功能，您需要做的就是创建一个将 `volumeBindingMode` 设置为 `WaitForFirstConsumer` 的 StorageClass：
+
+```
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: topology-aware-standard
+provisioner: kubernetes.io/gce-pd
+volumeBindingMode: WaitForFirstConsumer
+parameters:
+  type: pd-standard
+```
+
+<!--
+This new setting instructs the volume provisioner to not create a volume immediately, and instead, wait for a pod using an associated PVC to run through scheduling. Note that previous StorageClass `zone` and `zones` parameters do not need to be specified anymore, as pod policies now drive the decision of which zone to provision a volume in.
+-->
+这个新设置表明卷配置器不立即创建卷，而是等待使用关联的 PVC 的 Pod 通过调度运行。
+请注意，不再需要指定以前的 StorageClass `zone` 和 `zones` 参数，因为现在在哪个区域中配置卷由 Pod 策略决定。
+
+<!--
+Next, create a pod and PVC with this StorageClass. This sequence is the same as before, but with a different StorageClass specified in the PVC. The following is a hypothetical example, demonstrating the capabilities of the new feature by specifying many pod constraints and scheduling policies:
+-->
+接下来，使用此 StorageClass 创建一个 Pod 和 PVC。
+此过程与之前相同，但在 PVC 中指定了不同的 StorageClass。
+以下是一个假设示例，通过指定许多 Pod 约束和调度策略来演示新功能特性：
+
+<!--
+* multiple PVCs in a pod
+* nodeAffinity across a subset of zones
+* pod anti-affinity on zones
+-->
+* 一个 Pod 多个 PVC
+* 跨子区域的节点亲和
+* 同一区域 Pod 反亲和
+
+```
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+spec:   
+  serviceName: "nginx"
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      affinity:
+        nodeAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+            nodeSelectorTerms:
+            - matchExpressions:
+              - key: failure-domain.beta.kubernetes.io/zone
+                operator: In
+                values:
+                - us-central1-a
+                - us-central1-f
+        podAntiAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - labelSelector:
+              matchExpressions:
+              - key: app
+                operator: In
+                values:
+                - nginx
+            topologyKey: failure-domain.beta.kubernetes.io/zone
+      containers:
+      - name: nginx
+        image: gcr.io/google_containers/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+        - name: logs
+          mountPath: /logs
+ volumeClaimTemplates:
+  - metadata:
+      name: www
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      storageClassName: topology-aware-standard
+      resources:
+        requests:
+          storage: 10Gi
+  - metadata:
+      name: logs
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      storageClassName: topology-aware-standard
+      resources:
+        requests:
+          storage: 1Gi
+```
+
+<!--
+Afterwards, you can see that the volumes were provisioned in zones according to the policies set by the pod:
+-->
+之后，您可以看到根据 Pod 设置的策略在区域中配置卷：
+
+```
+$ kubectl get pv -o=jsonpath='{range .items[*]}{.spec.claimRef.name}{"\t"}{.metadata.labels.failure\-domain\.beta\.kubernetes\.io/zone}{"\n"}{end}'
+www-web-0       us-central1-f
+logs-web-0      us-central1-f
+www-web-1       us-central1-a
+logs-web-1      us-central1-a
+```
+
+<!--
+## How can I learn more?
+-->
+## 我怎样才能了解更多？
+
+<!--
+Official documentation on the topology-aware dynamic provisioning feature is available here:https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode
+-->
+有关拓扑感知动态供应功能的官方文档可在此处获取：https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode
+
+<!--
+Documentation for CSI drivers is available at https://kubernetes-csi.github.io/docs/
+-->
+有关 CSI 驱动程序的文档，请访问：https://kubernetes-csi.github.io/docs/
+
+<!--
+## What’s next?
+-->
+## 下一步是什么？
+
+<!--
+We are actively working on improving this feature to support:
+-->
+我们正积极致力于改进此功能以支持：
+
+<!--
+* more volume types, including dynamic provisioning for local volumes
+* dynamic volume attachable count and capacity limits per node
+-->
+* 更多卷类型，包括本地卷的动态供应
+* 动态容量可附加计数和每个节点的容量限制
+
+<!--
+## How do I get involved?
+-->
+## 我如何参与？
+
+<!--
+If you have feedback for this feature or are interested in getting involved with the design and development, join the [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). We’re rapidly growing and always welcome new contributors.
+-->
+如果您对此功能有反馈意见或有兴趣参与设计和开发，请加入 [Kubernetes 存储特别兴趣小组](https://github.com/kubernetes/community/tree/master/sig-storage)（SIG）。我们正在快速成长，并始终欢迎新的贡献者。
+
+<!--
+Special thanks to all the contributors that helped bring this feature to beta, including Cheng Xing ([verult](https://github.com/verult)), Chuqiang Li ([lichuqiang](https://github.com/lichuqiang)), David Zhu ([davidz627](https://github.com/davidz627)), Deep Debroy ([ddebroy](https://github.com/ddebroy)), Jan Šafránek ([jsafrane](https://github.com/jsafrane)), Jordan Liggitt ([liggitt](https://github.com/liggitt)), Michelle Au ([msau42](https://github.com/msau42)), Pengfei Ni ([feiskyer](https://github.com/feiskyer)), Saad Ali ([saad-ali](https://github.com/saad-ali)), Tim Hockin ([thockin](https://github.com/thockin)), and Yecheng Fu ([cofyc](https://github.com/cofyc)).
+-->
+特别感谢帮助推出此功能的所有贡献者，包括 Cheng Xing ([verult](https://github.com/verult))、Chuqiang Li ([lichuqiang](https://github.com/lichuqiang))、David Zhu ([davidz627](https://github.com/davidz627))、Deep Debroy ([ddebroy](https://github.com/ddebroy))、Jan Šafránek ([jsafrane](https://github.com/jsafrane))、Jordan Liggitt ([liggitt](https://github.com/liggitt))、Michelle Au ([msau42](https://github.com/msau42))、Pengfei Ni ([feiskyer](https://github.com/feiskyer))、Saad Ali ([saad-ali](https://github.com/saad-ali))、Tim Hockin ([thockin](https://github.com/thockin))，以及 Yecheng Fu ([cofyc](https://github.com/cofyc))。
@@ -0,0 +1,73 @@
+---
+layout: blog
+title: '2018 年督导委员会选举结果'
+date: 2018-10-15
+---
+<!--
+---
+layout: blog
+title: '2018 Steering Committee Election Results'
+date: 2018-10-15
+---
+-->
+
+<!-- **Authors**: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google) -->
+**作者**: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google)
+
+<!--
+## Results
+-->
+## 结果
+<!--
+The [Kubernetes Steering Committee Election](https://kubernetes.io/blog/2018/09/06/2018-steering-committee-election-cycle-kicks-off/) is now complete and the following candidates came ahead to secure two year terms that start immediately:
+-->
+[Kubernetes 督导委员会选举](https://kubernetes.io/blog/2018/09/06/2018-steering-committee-election-cycle-kicks-off/)现已完成，以下候选人获得了立即开始的两年任期：
+
+* Aaron Crickenberger, Google, [@spiffxp](https://github.com/spiffxp)
+* Davanum Srinivas, Huawei, [@dims](https://github.com/dims)
+* Tim St. Clair, Heptio, [@timothysc](https://github.com/timothysc)
+
+<!--
+## Big Thanks!
+-->
+## 十分感谢！
+
+<!-- 
+* Steering Committee Member Emeritus [Quinton Hoole](https://github.com/quinton-hoole) for his service to the community over the past year. We look forward to
+* The candidates that came forward to run for election. May we always have a strong set of people who want to push community forward like yours in every election.
+* All 307 voters who cast a ballot.
+* And last but not least...Cornell University for hosting [CIVS](https://civs.cs.cornell.edu/)! 
+-->
+* 督导委员会荣誉退休成员 [Quinton Hoole](https://github.com/quinton-hoole)，表扬他在过去一年为社区所作的贡献。我们期待着
+* 参加竞选的候选人。愿我们永远拥有一群强大的人，他们希望在每一次选举中都能像你们一样推动社区向前发展。
+* 共计 307 名选民参与投票。
+* 本次选举由康奈尔大学主办 [CIVS](https://civs.cs.cornell.edu/)！
+
+<!--
+## Get Involved with the Steering Committee
+-->
+## 加入督导委员会
+<!--
+You can follow along to Steering Committee [backlog items](https://git.k8s.io/steering/backlog.md) and weigh in by filing an issue or creating a PR against their [repo](https://github.com/kubernetes/steering). They meet bi-weekly on [Wednesdays at 8pm UTC](https://github.com/kubernetes/steering) and regularly attend Meet Our Contributors.
+-->
+你可以关注督导委员会的[任务清单](https://git.k8s.io/steering/backlog.md)，并通过向他们的[代码仓库](https://github.com/kubernetes/steering)提交 issue 或 PR 的方式来参与。他们也会在[UTC 时间每周三晚 8 点](https://github.com/kubernetes/steering)举行会议，并定期与我们的贡献者见面。
+
+<!--
+Steering Committee Meetings:
+-->
+督导委员会会议：
+
+* [YouTube 播放列表](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM)
+
+<!--
+Meet Our Contributors Steering AMA’s: 
+-->
+与我们的贡献者会面：
+
+<!--
+* [Oct  3 2018](https://youtu.be/x6Jm8p0K-IQ)
+* [Sept 5 2018](https://youtu.be/UbxWV12Or58)
+-->
+
+* [2018 年 10 月 3 日](https://youtu.be/x6Jm8p0K-IQ)
+* [2018 年 7 月 5 日](https://youtu.be/UbxWV12Or58)
@@ -0,0 +1,118 @@
+---
+layout: "Blog"
+title: "Kubernetes 2018 年北美贡献者峰会"
+date: 2018-10-16    
+---
+<!--
+---
+layout: "Blog"
+title: "Kubernetes 2018 North American Contributor Summit"
+date: 2018-10-16    
+---
+-->
+<!--
+**Authors:**
+-->
+**作者：**
+<!--
+[Bob Killen][bob] (University of Michigan)
+[Sahdev Zala][sahdev] (IBM),
+[Ihor Dvoretskyi][ihor] (CNCF) 
+-->
+[Bob Killen][bob]（密歇根大学）
+[Sahdev Zala][sahdev]（IBM），
+[Ihor Dvoretskyi][ihor]（CNCF）
+
+<!--
+The 2018 North American Kubernetes Contributor Summit to be hosted right before
+[KubeCon + CloudNativeCon][kubecon] Seattle is shaping up to be the largest yet.
+-->
+2018 年北美 Kubernetes 贡献者峰会将在西雅图 [KubeCon + CloudNativeCon][kubecon] 会议之前举办，这将是迄今为止规模最大的一次盛会。
+<!--
+It is an event that brings together new and current contributors alike to
+connect and share face-to-face; and serves as an opportunity for existing
+contributors to help shape the future of community development. For new
+community members, it offers a welcoming space to learn, explore and put the
+contributor workflow to practice.
+-->
+这是一个将新老贡献者聚集在一起，面对面交流和分享的活动；并为现有的贡献者提供一个机会，帮助塑造社区发展的未来。它为新的社区成员提供了一个学习、探索和实践贡献工作流程的良好空间。
+
+<!--
+Unlike previous Contributor Summits, the event now spans two-days with a more
+relaxed ‘hallway’ track and general Contributor get-together to be hosted from
+5-8pm on Sunday December 9th at the [Garage Lounge and Gaming Hall][garage], just
+a short walk away from the Convention Center. There, contributors can enjoy
+billiards, bowling, trivia and more; accompanied by a variety of food and drink. 
+-->
+与之前的贡献者峰会不同，本次活动为期两天，有一个更为轻松的行程安排，一般贡献者将于 12 月 9 日（周日）下午 5 点至 8 点在距离会议中心仅几步远的 [Garage Lounge and Gaming Hall][garage] 举办峰会。在那里，贡献者也可以进行台球、保龄球等娱乐活动，而且还有各种食品和饮料。
+
+<!--
+Things pick up the following day, Monday the 10th with three separate tracks: 
+-->
+接下来的一天，也就是 10 号星期一，有三个独立的会议你可以选择参与：
+
+<!--
+### New Contributor Workshop:
+A half day workshop aimed at getting new and first time contributors onboarded
+and comfortable with working within the Kubernetes Community. Staying for the
+duration is required; this is not a workshop you can drop into. 
+-->
+### 新贡献者研讨会：
+
+为期半天的研讨会旨在让新贡献者加入社区，并营造一个良好的 Kubernetes 社区工作环境。
+请在开会期间保持在场，该讨论会不允许随意进出。
+
+<!--
+### Current Contributor Track:
+Reserved for those that are actively engaged with the development of the
+project; the Current Contributor Track includes Talks, Workshops, Birds of a
+Feather, Unconferences, Steering Committee Sessions, and more! Keep an eye on
+the [schedule in GitHub][schedule] as content is frequently being updated.
+-->
+### 当前贡献者追踪：
+
+保留给那些积极参与项目开发的贡献者；目前的贡献者追踪包括讲座、研讨会、聚会、Unconferences 会议、指导委员会会议等等!
+请留意 [GitHub 中的时间表][时间表]，因为内容经常更新。
+
+<!--
+### Docs Sprint:
+SIG-Docs will have a curated list of issues and challenges to be tackled closer
+to the event date.
+-->
+### Docs 冲刺：
+
+SIG-Docs 将在活动日期临近的时候列出一个需要处理的问题和挑战列表。
+
+<!--
+## To Register:
+To register for the Contributor Summit, see the [Registration section of the
+Event Details in GitHub][register]. Please note that registrations are being
+reviewed. If you select the “Current Contributor Track” and are not an active
+contributor, you will be asked to attend the New Contributor Workshop, or asked
+to be put on a waitlist. With thousands of contributors and only 300 spots, we
+need to make sure the right folks are in the room. 
+-->
+## 注册：
+
+要注册贡献者峰会，请参阅 Git Hub 上的[活动详情注册部分][注册]。请注意报名正在审核中。
+如果您选择了 “当前贡献者追踪”，而您却不是一个活跃的贡献者，您将被要求参加新贡献者研讨会，或者被要求进入候补名单。
+成千上万的贡献者只有 300 个位置，我们需要确保正确的人被安排席位。
+
+<!--
+If you have any questions or concerns, please don’t hesitate to reach out to
+the Contributor Summit Events Team at community@kubernetes.io.
+-->
+如果您有任何问题或疑虑，请随时通过 community@kubernetes.io 联系贡献者峰会组织团队。
+
+<!--
+Look forward to seeing everyone there!
+-->
+期待在那里看到每个人！
+
+[bob]: https://twitter.com/mrbobbytables
+[sahdev]: https://twitter.com/sp_zala
+[ihor]: https://twitter.com/idvoretskyi
+[kubecon]: https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
+[garage]: https://www.garagebilliards.com/
+[时间表]: https://git.k8s.io/community/events/2018/12-contributor-summit#agenda
+[注册]:  https://git.k8s.io/community/events/2018/12-contributor-summit#registration
@@ -0,0 +1,89 @@
+---
+layout: blog
+title: 'Kubernetes 文档更新，国际版'
+date: 2018-11-08
+---
+<!--
+---
+layout: blog
+title: 'Kubernetes Docs Updates, International Edition'
+date: 2018-11-08
+---
+-->
+
+<!-- **Author**: Zach Corleissen (Linux Foundation) -->
+**作者**：Zach Corleissen （Linux 基金会）
+
+<!-- As a co-chair of SIG Docs, I'm excited to share that Kubernetes docs have a fully mature workflow for localization (l10n).  -->
+作为文档特别兴趣小组（SIG Docs）的联合主席，我很高兴能与大家分享 Kubernetes 文档在本地化（l10n）方面所拥有的一个完全成熟的工作流。
+
+<!-- ## Abbreviations galore -->
+## 丰富的缩写
+
+<!-- L10n is an abbreviation for _localization_. -->
+L10n 是 _localization_ 的缩写。
+
+<!-- I18n is an abbreviation for _internationalization_.  -->
+I18n 是 _internationalization_ 的缩写。
+
+<!-- I18n is [what you do](https://www.w3.org/International/questions/qa-i18n) to make l10n easier. L10n is a fuller, more comprehensive process than translation (_t9n_). -->
+I18n 定义了[做什么](https://www.w3.org/International/questions/qa-i18n) 能让 l10n 更容易。而 L10n 更全面，相比翻译（ _t9n_ ）具备更完善的流程。
+
+<!-- ## Why localization matters -->
+## 为什么本地化很重要
+
+<!-- The goal of SIG Docs is to make Kubernetes easier to use for as many people as possible. -->
+SIG Docs 的目标是让 Kubernetes 更容易为尽可能多的人使用。
+
+<!-- One year ago, we looked at whether it was possible to host the output of a Chinese team working independently to translate the Kubernetes docs. After many conversations (including experts on OpenStack l10n), [much transformation](https://kubernetes.io/blog/2018/05/05/hugo-migration/), and [renewed commitment to easier localization](https://github.com/kubernetes/website/pull/10485), we realized that open source documentation is, like open source software, an ongoing exercise at the edges of what's possible. -->
+一年前，我们研究了是否有可能由一个独立翻译 Kubernetes 文档的中国团队来主持文档输出。经过多次交谈（包括 OpenStack l10n 的专家），[多次转变](https://kubernetes.io/blog/2018/05/05/hugo-migration/)，以及[重新致力于更轻松的本地化](https://github.com/kubernetes/website/pull/10485)，我们意识到，开源文档就像开源软件一样，是在可能的边缘不断进行实践。
+
+<!-- Consolidating workflows, language labels, and team-level ownership may seem like simple improvements, but these features make l10n scalable for increasing numbers of l10n teams. While SIG Docs continues to iterate improvements, we've paid off a significant amount of technical debt and streamlined l10n in a single workflow. That's great for the future as well as the present. -->
+整合工作流程、语言标签和团队级所有权可能看起来像是十分简单的改进，但是这些功能使 l10n 可以扩展到规模越来越大的 l10n 团队。随着 SIG Docs 不断改进，我们已经在单一工作流程中偿还了大量技术债务并简化了 l10n。这对未来和现在都很有益。
+
+<!-- ## Consolidated workflow -->
+## 整合的工作流程
+
+<!-- Localization is now consolidated in the [kubernetes/website](https://github.com/kubernetes/website) repository. We've configured the Kubernetes CI/CD system, [Prow](https://github.com/kubernetes/test-infra/tree/master/prow), to handle automatic language label assignment as well as team-level PR review and approval. -->
+现在，本地化已整合到 [kubernetes/website](https://github.com/kubernetes/website) 存储库。我们已经配置了 Kubernetes CI/CD 系统，[Prow](https://github.com/kubernetes/test-infra/tree/master/prow) 来处理自动语言标签分配以及团队级 PR 审查和批准。
+
+<!-- ### Language labels  -->
+### 语言标签
+
+<!-- Prow automatically applies language labels based on file path. Thanks to SIG Docs contributor [June Yi](https://github.com/kubernetes/test-infra/pull/9835), folks can also manually assign language labels in pull request (PR) comments. For example, when left as a comment on an issue or PR, this command assigns the label `language/ko` (Korean). -->
+Prow 根据文件路径自动添加语言标签。感谢 SIG Docs 贡献者 [June Yi](https://github.com/kubernetes/test-infra/pull/9835)，他让人们还可以在 pull request（PR）注释中手动分配语言标签。例如，当为 issue 或 PR 留下下述注释时，将为之分配标签 `language/ko`（Korean）。
+
+```
+/language ko
+```
+
+
+<!-- These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the k/website dashboard for [PRs with Chinese content](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh).   -->
+这些存储库标签允许审阅者按语言过滤 PR 和 issue。例如，您现在可以过滤 kubernetes/website 面板中[具有中文内容的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh)。
+
+<!-- ### Team review  -->
+### 团队审核
+
+<!-- L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/master/content/en/OWNERS) in the top subfolder for English content.  -->
+L10n 团队现在可以审查和批准他们自己的 PR。例如，英语的审核和批准权限在位于用于显示英语内容的顶级子文件夹中的 [OWNERS 文件中指定](https://github.com/kubernetes/website/blob/master/content/en/OWNERS)。
+
+<!-- Adding `OWNERS` files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency. -->
+将 `OWNERS` 文件添加到子目录可以让本地化团队审查和批准更改，而无需由可能并不擅长该门语言的审阅者进行批准。
+
+<!-- ## What's next -->
+## 下一步是什么
+
+<!-- We're looking forward to the [doc sprint in Shanghai](https://kccncchina2018english.sched.com/event/HVb2/contributor-summit-doc-sprint-additional-registration-required) to serve as a resource for the Chinese l10n team. -->
+我们期待着[上海的 doc sprint](https://kccncchina2018english.sched.com/event/HVb2/contributor-summit-doc-sprint-additional-registration-required) 能作为中国 l10n 团队的资源。
+
+<!-- We're excited to continue supporting the Japanese and Korean l10n teams, who are making excellent progress. -->
+我们很高兴继续支持正在取得良好进展的日本和韩国 l10n 队伍。
+
+<!-- If you're interested in localizing Kubernetes for your own language or region, check out our [guide to localizing Kubernetes docs](https://kubernetes.io/docs/contribute/localization/) and reach out to a [SIG Docs chair](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for support. -->
+如果您有兴趣将 Kubernetes 本地化为您自己的语言或地区，请查看我们的[本地化 Kubernetes 文档指南](https://kubernetes.io/docs/contribute/localization/)，并联系 [SIG Docs 主席团](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)获取支持。
+
+<!-- ### Get involved with SIG Docs  -->
+### 加入SIG Docs
+
+<!-- If you're interested in Kubernetes documentation, come to a SIG Docs [weekly meeting](https://github.com/kubernetes/community/tree/master/sig-docs#meetings), or join [#sig-docs in Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/details/). -->
+如果您对 Kubernetes 文档感兴趣，请参加 SIG Docs [每周会议](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)，或在 [Kubernetes Slack 加入 #sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/details/)。
@@ -3,7 +3,7 @@ layout: blog
 title: '新贡献者工作坊上海站'
 date: 2018-12-05
 ---
-
+ 
 <!-- 
 ---
 layout: blog
@@ -1,23 +1,21 @@
---
-title: 案例研究
-linkTitle: 案例研究
-bigheader: Kubernetes 用户案例研究
-abstract: 在生产环境中运行 Kubernetes 的用户集合。
-layout: basic
-class: gridPage
-cid: caseStudies
---
-
-<!--
-
---
-title: Case Studies
-linkTitle: Case Studies
-bigheader: Kubernetes User Case Studies
-abstract: A collection of users running Kubernetes in production.
-layout: basic
-class: gridPage
-cid: caseStudies
---
-
-->
+---
+title: 案例分析
+linkTitle: 案例分析
+bigheader: Kubernetes 用户案例分析
+abstract: 在生产环境下使用 Kubernetes 的案例集
+layout: basic
+class: gridPage
+cid: caseStudies
+---
+
+<!--
+---
+title: Case Studies
+linkTitle: Case Studies
+bigheader: Kubernetes User Case Studies
+abstract: A collection of users running Kubernetes in production.
+layout: basic
+class: gridPage
+cid: caseStudies
+---
+-->
@@ -0,0 +1,157 @@
+---
+title: 案例研究：Buffer
+
+case_study_styles: true
+cid: caseStudies
+css: /css/style_buffer.css
+---
+
+<!-- <div class="banner1">
+  <h1>CASE STUDY: <img src="/images/buffer.png" width="18%" style="margin-bottom:-5px;margin-left:10px;"><br>
+  <div class="subhead">Making Deployments Easy for a Small, Distributed Team</div>
+</h1>
+</div> -->
+<div class="banner1">
+  <h1>案例研究: <img src="/images/buffer.png" width="18%" style="margin-bottom:-5px;margin-left:10px;"><br>
+  <div class="subhead">使小型分布式团队轻松部署</div>
+</h1>
+</div>
+
+<!-- <div class="details">
+    Company&nbsp;<b>Buffer</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Around the World</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Social Media Technology</b>
+</div> -->
+<div class="details">
+    公司&nbsp;<b>Buffer</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;位置 &nbsp;<b>全球</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;行业 &nbsp;<b>社交媒体技术公司</b>
+</div>
+
+<hr>
+
+<section class="section1">
+  <div class="cols">
+    <div class="col1">
+
+<!-- <h2>Challenge</h2>
+With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as&nbsp;necessary." -->
+<h2>挑战</h2>
+  Buffer 拥有一支80人的分布式团队，他们遍布全球近十几个时区。这样一个为代理商和营销人员提供社交媒体管理的公司，希望解决其“典型的单一庞大编码基数问题”，架构师 Dan Farrelly 这样说。“我们希望拥有一种流动性的基础架构，开发人员可以创建一个应用程序，可以根据需要部署并横向扩展它”。
+</div>
+
+<div class="col2">
+  <!-- <h2>Solution</h2>
+      Embracing containerization, Buffer moved its infrastructure from Amazon Web Services’ Elastic Beanstalk to Docker on AWS, orchestrated with&nbsp;Kubernetes. -->
+<h2>解决方案</h2>
+拥抱容器化，Buffer 将其基础设施从 AWS 上的 Elastic Beanstalk 迁移到由 Kubernetes 负责编排的 Docker 上。
+      <br>
+      <br>
+<!-- <h2>Impact</h2>
+      The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it’s going to work has shortened things up a lot. Our feedback cycles are a lot faster now&nbsp;too." -->
+<h2>影响</h2>
+Farrelly 说，新系统“提高了我们将新变化进行部署和上线的能力”。“在自己的计算机上构建一些东西，并且知道它是可用的，这已经让事情简单了很多；而且我们的反馈周期现在也快了很多。”
+</div>
+</div>
+</section>
+
+<div class="banner2">
+  <div class="banner2text">
+    <!-- "It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it’s there in the next release or it’s coming in the next few months."<br><br><span style="font-size:16px;letter-spacing:2px;">- DAN FARRELLY, BUFFER ARCHITECT</span> -->
+“我们的团队能够直接使用既有的 Kubernetes 解决方案，这太棒了，而且它还在不断改进中。在意识到我们需要某些功能之前，它就出现在下一个版本中，或者在未来几个月内出现。<br><br><span style="font-size:16px;letter-spacing:2px;">- DAN FARRELLY, BUFFER ARCHITECT</span>
+  </div>
+</div>
+
+<section class="section2">
+<div class="fullcol">
+<!-- <h2>Dan Farrelly uses a carpentry analogy to explain the problem his company, <a href="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.</h2> -->
+<h2>Dan Farrelly 用木工类比来解释他的公司<a href="https://buffer.com"> Buffer </a>，随着过去几年的发展，公司开始有这个问题。</h2>
+
+<!-- "If you’re building a table by yourself, it’s fine," the company’s architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you’re sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes. -->
+“如果你自己做一张桌子，这很好！”公司的架构师说。“如果你请另一个人一起来做这个桌子，也许这个人可以在你抛光桌面时开始对腿进行抛光。但是，当你把第三个或第四个人带进来时，有人也许应该在另外一张桌子上工作。”需要处理越来越多不同的桌子，使 Buffer 走上了 Kubernetes 实现微服务和容器化的道路。
+<br><br>
+<!-- Since around 2012, Buffer had already been using <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <a href="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <a href="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company.  -->
+自2012年左右以来，Buffer 开始使用<a href="https://aws.amazon.com/elasticbeanstalk/"> Elastic Beanstalk </a>,这是<a href="https://aws.amazon.com">亚马逊网络服务</a>提供的网络基础设施编排服务。“我们部署了一个单一的<a href="http://php.net/manual/en/intro-whatis.php">PHP</a>应用程序,它是在五六个环境中相同的应用程序，”Farrelly 说。“我们在很大程度上是一家产品驱动型的公司。”
+<!-- It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn’t spend too much time on it. If things were getting a little bit slow, we’d maybe use a faster server or just scale up one instance, and it would be good enough. We’d move on." -->
+这一切都是为了尽快给应用推出新功能并进行交付，如果能够正常运行，我们就不会花太多时间在上面。如果产品变得有点慢，我们可能会使用更快的服务器或只是增加一个实例，这些就已经足够了。然后继续前进。
+<br><br>
+<!-- But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer’s then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company’s team was already successfully using <a href="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn’t see real user traffic. They wanted to go further with Docker, and the next step was looking at options for&nbsp;orchestration. -->
+但事情在2016年就到了头。随着应用提交修改的数量不断增加，Farrelly 和 Buffer 当时的首席技术官 Sunil Sadasivan 决定,是重新思考和构建其基础架构的时候了。“这是一个典型的单一庞大编码基数问题，”Farrelly说。公司的一些团队已经在开发环境中成功使用<a href="https://www.docker.com">Docker</a>，但在生产环境中，运行在 Docker 上的唯一应用程序是一个看不到真实用户流量的营销网站。他们希望在使用 Docker 上更进一步,下一步是寻找业务流程的选项。
+</div>
+</section>
+
+<div class="banner3">
+  <div class="banner3text">
+<!-- And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it&nbsp;[Kubernetes]." -->
+Kubernetes 所做的所有事情都很好地适应了 Buffer 的需求。Farrelly 说：“我们希望拥有一种流动基础架构，开发人员可以创建一个应用程序，并在必要时部署并进行水平扩展。”“我们很快就使用一些脚本来设置几个测试集群，在容器中构建了一些小的概念性验证应用程序，并在一小时内部署了这些内容。我们在生产中运行容器方面经验很少。令人惊奇的是，我们能很快地用 Kubernetes 来处理。”
+  </div>
+</div>
+
+<section class="section3">
+<div class="fullcol">
+    <!-- First they considered <a href="https://mesosphere.com">Mesosphere</a>, <a href="https://dcos.io">DC/OS</a> and <a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. -->
+首先，他们考虑了<a href="https://mesosphere.com">Mesosphere</a>、<a href="https://dcos.io">DC/OS</a>和<a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a>(他们的数据系统团队已经将其用于某些数据管道作业)。虽然他们对这些产品印象深刻，但他们最终还是与 Kubernetes 合作。
+ <!-- "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn’t need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes’ controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well." -->
+Farrelly 说：“我们的应用仍在 AWS 上运行，但是我们的团队通过 Kubernetes 无需手动配置即可创建服务并按需创建负载均衡器，这是使用 Kubernetes 的最佳入门体验。”“我们不需要考虑如何配置这个或那个,特别是相较于以前的 Elastic Beanstalk 环境，它为我们提供了一个自动配置的负载均衡器。我真的很喜欢 Kubernetes 对命令行的控制，只需要对端口进行配置，这样更加灵活。Kubernetes 是为做它所做的事情而设计的,所以它做得非常好。”
+<br><br>
+    <!-- And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]." -->
+Kubernetes 所做的所有事情都很好地适应了 Buffer 的需求。Farrelly 说：“我们希望拥有一种流动基础架构，开发人员可以创建一个应用程序，并在必要时部署并进行水平扩展。”“我们很快就使用一些脚本来设置几个测试集群，在容器中构建了一些小的概念性验证应用程序，并在一小时内部署了这些内容。我们在生产中运行容器方面经验很少。令人惊奇的是,我们能很快地用 Kubernetes 来处理。”
+<br><br>
+    <!-- Above all, it provided a powerful solution for one of the company’s most distinguishing characteristics: their remote team that’s spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It’s been really cool to see people moving much faster." -->
+最重要的是，它为公司最显著的特征之一提供了强大的解决方案：他们的远程团队分布在十几个不同的时区。Farrelly 说：“对我们的基础设施有深入了解的人生活在不同于我们相对集中的时区，而我们的大部分产品工程师都住在其他地方。”“因此，我们确实希望有人能够尽早掌握这套系统并利用好它，而不必担心部署工程师正在睡觉。否则，人们会为了一些东西必须得等待12到24小时左右。看到人们前进得更快，这真的很酷。”
+    <br><br>
+    <!-- With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies&nbsp;might." -->
+Farrelly 说，Buffer 拥有相对较小的工程团队，只有 25 人，只有少数人从事基础设施工作，大多数前端开发人员都需要“一些强大的配置能力，以便部署任何他们想要的内容。”以前，“只有几个人知道如何用旧的方式设置一切。有了这个系统，审查文档变得很容易，并且能很快地看到效果。它降低了我们获取在开发环境中所需要一切的门槛。因为我们团队的人数不足以来构建所有这些工具或像其他大公司那样管理基础架构。”
+</div>
+</section>
+
+<div class="banner4">
+  <div class="banner4text">
+    <!-- "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the&nbsp;door." -->
+Farrelly 说：“在我们以往的工作方式中，反馈循环流程要长得多，而且很微妙，因为如果你部署了某些东西，就存在破坏其他东西的风险。”“我们通过围绕 Kubernetes 构建的部署类型，能够及时检测 Bug 并修复它们，并使其部署得超快。这一秒正在修复漏洞，不一会就上线运行了。”
+  </div>
+</div>
+
+<section class="section4">
+<div class="fullcol">
+    <!-- To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <a href="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <a href="https://slack.com">Slack</a> command, ‘/deploy,’ and it goes out instantly. They don’t need to wait on these slow turnaround times. They don’t even know where it’s running; it doesn’t matter." -->
+为了帮助解决这一问题，Buffer 开发人员编写了一个部署机器人，该机器人包装了 Kubernetes 部署过程，并且每个团队都可以使用。”“以前,我们的数据分析师会更新<a href="https://www.python.org"> Python </a>分析脚本，并且必须等待该团队的主管单击该按钮并部署它，”Farrelly 解释道。“现在，我们的数据分析师可以进行更改，输入<a href="https://slack.com"> Slack </a>命令，‘/deploy’,它会立即进行部署。他们不需要等待这些缓慢的周转时间，他们甚至不知道它在哪里运行。这些都不重要了。
+    <br><br>
+    <!-- One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly. -->
+团队使用 Kubernetes 从头开始构建的第一个应用程序是一种新的图像大小调整服务。作为一种社交媒体管理工具，它允许营销团队通过发帖进行协作，并通过多个社交媒体配置文件和网络发送更新，Buffer 必须能够根据需要调整照片的大小，以满足不同的社交网络。Farrelly 说：“我们一直有这些拼凑在一起的解决方案。”
+    <br><br>
+    <!-- To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door." -->
+为了创建这项新服务，一位高级产品工程师被指派学习 Docker 和 Kubernetes，然后构建服务、测试、部署和监视服务，他能够相对快速地完成该服务。Farrelly说：“在我们以往的工作方式中，反馈循环流程要长得多，而且很微妙，因为如果你部署了某些东西，就存在破坏其他东西的风险。”“我们通过围绕 Kubernetes 构建的部署类型，能够及时检测 Bug 并修复它们，并使其部署得超快。这一秒正在修复漏洞,不一会就上线运行了。”
+    <br><br>
+    <!-- Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it." -->
+此外，与旧系统不同，他们只需一个命令就可以水平缩放内容。“当我们推出它,”Farrelly说，“我们可以预测，只需点击一个按钮。这使我们能够处理用户对系统的需求,并轻松扩展以处理它。”
+    <br><br>
+    <!-- Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing&nbsp;risk." -->
+他们以前不能做的另外一件事是金丝雀部署。Farrelly说，这种新功能“使我们在部署重大变革方面更加自信。”“以前，虽然进行很多测试但仍表现不错，但它也存在很多‘手指交叉’。这是每天运行 800000 次的东西，这是我们业务的核心。如果它不工作，我们的业务也无法运行。在 Kubernetes 世界中，我可以执行金丝雀部署以测试 1%，如果它不工作，我可以很快将其关闭。这使我们在快速部署和推出新更改的同时降低风险的能力得到了提高。”
+
+</div>
+</section>
+
+<div class="banner5">
+  <div class="banner5text">
+    <!-- "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this&nbsp;way." -->
+Farrelly 说：“如果你想在生产中运行容器，拥有像谷歌内部使用的那种效果，那么 Kubernetes 就是一个很好的方法。”“我们是一个相对较小的团，实际上运行 Kubernetes，我们之前从来没来做过这样的事情。因此，它比你想象的更容易上手，这正是我想要告诉正在尝试使用它的人们的一件很重要的事。挑几个应用,把它们准备好,在机器上运行几个月,看看它能处理的怎么样。通过这种方式你可以学到很多东西。”
+  </div>
+</div>
+
+<section class="section5">
+<div class="fullcol">
+    <!-- By October 2016, 54 percent of Buffer’s traffic was going through their Kubernetes cluster. "There’s a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes." -->
+到 2016 年 10 月，Buffer 54% 的流量都通过其 Kubernetes 集群。Farrelly 说：“我们很多传统功能仍然运行正常，这些部分可能会转移到 Kubernetes 或永远留在我们的旧设置中。”但该公司当时承诺，“所有新的开发，所有新功能,将在Kubernetes上运行。”
+    <br><br>
+    <!-- The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they’ve pulled out of their old infrastructure, plus the new services they’re developing in Kubernetes, on another cluster. "I want to bring all the benefits that we’ve seen on our early services to everyone on the team," says Farrelly. -->
+2017年计划是将所有旧应用程序迁移到新的 Kubernetes 集群，并运行他们从旧基础架构中撤出的所有内容，以及他们正在另一个 Kubernetes 集群上开发的新服务。Farrelly 说：“我想为团队中的每个人带来我们早期服务的所有好处。”
+    <br><br>
+    <h2>
+<!-- For Buffer’s engineers, it’s an exciting process. "Every time we’re deploying a new service, we need to figure out: OK, what’s the architecture? How do these services communicate? What’s the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It’s enabling us to experiment as we’re learning how to design a service-oriented architecture. Before, we just wouldn’t have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it." -->
+对于 Buffer 的工程师来说，这是一个令人兴奋的过程。“每次部署新服务时，我们都需要弄清楚:好的，体系结构是什么？这些服务如何沟通？构建此服务的最佳方式是什么？”Farrelly说。“然后，我们使用 Kubernetes 的特性将所有部分聚合到一起。在学习如何设计面向服务的体系结构时，它使我们能够进行试验。以前，我们只是不能做到这一点。这实际上给了我们一个空白的白板，所以我们可以做任何我们想要的。”
+    </h2>
+    <!-- Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It’s cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We’re very deep in Amazon but it’s nice to know we could move away if we need to." -->
+部分空白是 Kubernetes 提供的灵活性，如果某一天 Buffer 可能想要或需要改变他的云服务。“这是与云无关的，所以也许有一天我们可以切换到谷歌或其他地方，”Farrelly 说。“我们非常依赖亚马逊的基础服务，但很高兴知道，如果我们需要的话，我们可以搬走。”
+    <br><br>
+    <!-- At this point, the team at Buffer can’t imagine running their infrastructure any other way—and they’re happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this&nbsp;way." -->
+此时，Buffer 团队无法想象以任何其他方式运行其基础结构，他们很乐意传播这一信息。Farrelly 说：“如果你想在生产中运行容器，拥有像谷歌内部使用的那种效果，那么 Kubernetes 就是一个很好的方法。”“我们是一个相对较小的团队，实际上运行 Kubernetes，我们之前从来没来做过这样的事情。因此，它比你想象的更容易上手，这正是我想要告诉正在尝试使用它的人们的一件很重要的事。挑几个应用，把它们准备好，在机器上运行几个月，看看它能处理的怎么样。通过这种方式你可以学到很多东西。”
+  <br><br>
+</div>
+</section>
@@ -0,0 +1,4 @@
+---
+title: CCP Games
+content_url: https://cloud.google.com/customers/ccp-games/
+---
@@ -0,0 +1,4 @@
+---
+title: Goldman Sachs
+content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/
+---
@@ -0,0 +1,433 @@
+---
+title: 华为案例分析
+
+case_study_styles: true
+cid: caseStudies
+css: /css/style_huawei.css
+---
+
+<!--
+---
+title: Huawei Case Study
+
+case_study_styles: true
+cid: caseStudies
+css: /css/style_huawei.css
+---
+-->
+
+<div class="banner1">
+  <h1> 案例分析：<img src="/images/huawei_logo.png" class="header_logo"><br> <div class="subhead">以用户和供应商身份拥抱云原生</div></h1>
+  <!--
+  <h1> CASE STUDY:<img src="/images/huawei_logo.png" class="header_logo"><br> <div class="subhead">Embracing Cloud Native as a User – and a Vendor</div></h1>
+  -->
+</div>
+
+<div class="details">
+    公司 &nbsp;<b>华为</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;地点 &nbsp;<b>中国深圳</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;产业 &nbsp;<b>通信设备</b>
+    <!--
+    Company &nbsp;<b>Huawei</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Shenzhen, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Telecommunications Equipment</b>
+    -->
+</div>
+
+<hr>
+
+<section class="section1">
+
+<div class="cols">
+  <div class="col1">
+    <h2>挑战</h2>
+    <!--
+    <h2>Challenge</h2>
+    -->
+      华为是世界上最大的电信设备制造商，拥有超过 18 万名员工。
+      <!--
+      A multinational company that’s the largest telecommunications equipment manufacturer in the world, 
+      Huawei has more than 180,000 employees. 
+      -->
+
+      为了支持华为在全球的快速业务发展，<a href="http://www.huawei.com/">华为</a>内部 IT 部门有 8 个数据中心，
+      这些数据中心在 100K+ VMs 上运行了 800 多个应用程序，服务于这 18 万用户。
+      <!--
+      In order to support its fast business development around the globe, 
+      <a href="http://www.huawei.com/">Huawei</a> has eight data centers for its internal I.T. department,
+      which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. 
+      -->
+
+      随着新应用程序的快速增长，基于 VM 的应用程序的管理和部署的成本和效率都成为业务敏捷性的关键挑战。
+      <!--
+      With the rapid increase of new applications, the cost and efficiency of management and 
+      deployment of VM-based apps all became critical challenges for business agility.
+      -->
+
+      该公司首席软件架构师、开源社区总监侯培新表示：
+      “这是一个超大的分布式系统，因此我们发现，以更一致的方式管理所有任务始终是一个挑战。
+      我们希望进入一种更敏捷、更得体的实践”。
+      <!--
+      "It’s very much a distributed system so we found that managing all of the tasks 
+      in a more consistent way is always a challenge," says Peixin Hou, 
+      the company’s Chief Software Architect and Community Director for Open Source. 
+      "We wanted to move into a more agile and decent practice."  
+      -->
+
+  </div>
+
+<div class="col2">
+  <h2>解决方案</h2>
+  <!--
+  <h2>Solution</h2>
+  -->
+      在决定使用容器技术后，华为开始将内部 IT 部门的应用程序迁移到<a href="http://kubernetes.io/"> Kubernetes </a>上运行。
+      到目前为止，大约 30% 的应用程序已经转移为云原生程序。
+      <!--
+      After deciding to use container technology, Huawei began moving the internal I.T. department’s applications 
+      to run on <a href="http://kubernetes.io/">Kubernetes</a>.
+      So far, about 30 percent of these applications have been transferred to cloud native.  
+      -->
+<br>
+<br>
+<h2>影响</h2>
+<!--
+<h2>Impact</h2>  
+-->
+      “到 2016 年底，华为的内部 IT 部门使用基于 Kubernetes 的平台即服务（PaaS）解决方案管理了 4000 多个节点和数万个容器。
+      全局部署周期从一周缩短到几分钟，应用程序交付效率提高了 10 倍”。
+      <!--
+       "By the end of 2016, Huawei’s internal I.T. department managed more than 4,000 nodes with tens of thousands containers 
+       using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou.
+       "The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold."
+      -->
+
+      对于底线，侯培新表示，“我们还看到运营开支大幅削减，在某些情况下可削减 20% 到 30%，我们认为这对我们的业务非常有帮助”。
+      <!--
+      For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent, 
+      which we think is very helpful for our business."
+      -->
+      
+      这里给出一些华为内部结果资料、外部需求，也是公司的技术包装产品<a href="http://developer.huawei.com/ict/en/site-paas"> FusionStage™ </a>，
+      它被作为一套 PaaS 解决方案提供给其客户。
+      <!--
+      Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies 
+      into <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a>, the PaaS solution it offers its customers. 
+      -->
+</div>
+
+</div>
+
+</section>
+
+<div class="banner2">
+  <div class="banner2text">
+    “如果你是一个供应商，为了说服你的客户，你应该自己使用它。
+    幸运的是，因为华为有很多员工，我们可以利用这种技术来展示我们所能构建的云的规模。”
+    <!--
+    "If you’re a vendor, in order to convince your customer, you should use it yourself. 
+    Luckily because Huawei has a lot of employees, 
+    we can demonstrate the scale of cloud we can build using this technology."
+    -->
+
+    <br style="height:25px">
+    <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;">
+        <br>- 侯培新，首席软件架构师、开源社区总监
+        <!--
+        <br>- Peixin Hou, chief software architect and community director for open source
+        -->
+    </span>  
+  </div>
+</div>
+
+<section class="section2">
+
+<div class="fullcol">
+    华为的 Kubernetes 之旅始于一位开发者。
+    <!--
+    Huawei’s Kubernetes journey began with one developer. 
+    -->
+
+    两年前，这家网络和电信巨头雇佣的一名工程师对<a href="http://kubernetes.io/"> Kubernetes </a>
+    这一跨主机集群的管理应用程序容器的技术产生了兴趣，并开始为其开源社区作出贡献。
+    <!--
+    Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested 
+    in <a href="http://kubernetes.io/">Kubernetes</a>, 
+    the technology for managing application containers across clusters of hosts, 
+    and started contributing to its open source community.
+    -->
+
+    随着技术和社区的发展，他不断地将这门技术告诉他的经理们。<br><br>
+    <!--
+    As the technology developed and the community grew, he kept telling his managers about it.<br><br>  
+    -->
+
+    与此同时，华为也在为其内部的企业 IT 部门寻找更好的编排系统，该系统应该支持每一个业务的流程处理。
+    <!--
+    And as fate would have it, at the same time, 
+    Huawei was looking for a better orchestration system for its internal enterprise I.T. department, 
+    which supports every business flow processing. 
+    -->
+
+    华为首席软件架构师、开源社区总监侯培新表示，
+    “我们在全球拥有逾 18 万名员工，内部流程复杂，所以这个部门可能每周都需要开发一些新的应用程序。
+    <!--
+    "We have more than 180,000 employees worldwide, and a complicated internal procedure, 
+    so probably every week this department needs to develop some new applications," says Peixin Hou, 
+    Huawei’s Chief Software Architect and Community Director for Open Source. 
+    -->
+
+    我们的 IT 部门经常需要启动数万个容器，任务要跨越全球数千个节点。
+    这是一个超大的分布式的系统，所以我们发现以更一致的方式管理所有的任务总是一个挑战”。<br><br>  
+    <!--
+    "Very often our I.T. departments need to launch tens of thousands of containers, 
+    with tasks running across thousands of nodes across the world. 
+    It’s very much a distributed system, so we found that managing all of the tasks 
+    in a more consistent way is always a challenge."<br><br>
+    -->
+
+    过去，华为曾使用虚拟机来封装应用程序，但是，“每次我们启动虚拟机时”，侯培新说，
+    “无论是因为它是一项新服务，还是因为它是一项由于节点功能异常而被关闭的服务，都需要花费大量时间”。
+    <!--
+    In the past, Huawei had used virtual machines to encapsulate applications, 
+    but "every time when we start a VM," Hou says, 
+    "whether because it’s a new service or because it was a service that was shut down 
+    because of some abnormal node functioning, it takes a lot of time." 
+    -->
+
+    华为转向了容器化，所以是时候尝试 Kubernetes 了。
+    采纳了这位工程师的建议花费了一年的时间，这个过程“不是一蹴而就的”，侯说，
+    <!--
+    Huawei turned to containerization, so the timing was right to try Kubernetes. 
+    It took a year to adopt that engineer’s suggestion – the process "is not overnight," says Hou – 
+    -->
+
+    但一旦投入使用，“Kubernetes 基本上解决了我们的大部分问题。
+    以前，部署时间大约需要一周，现在只需几分钟。
+    <!--
+    but once in use, he says, "Kubernetes basically solved most of our problems. 
+    Before, the time of deployment took about a week, now it only takes minutes. 
+    -->
+
+    开发人员非常高兴。使用 Kubernetes 的那个部门也十分高兴”。<br><br>  
+    <!--
+    The developers are happy. That department is also quite happy."<br><br>
+    -->
+
+    侯培新看到了使用这项技术给公司带来的巨大好处，
+    “Kubernetes 为基于云的应用程序带来了敏捷性、扩展能力和 DevOps 实践”，他说，
+    <!--
+    Hou sees great benefits to the company that come with using this technology: 
+    "Kubernetes brings agility, scale-out capability, 
+    and DevOps practice to the cloud-based applications," he says.
+    -->
+    
+    “它为我们提供了自定义调度体系结构的能力，这使得容器任务之间的关联性成为可能，从而提高了效率。
+    它支持多种容器格式，同时广泛支持各种容器网络解决方案和容器存储方案”。
+    <!--
+    "It provides us with the ability to customize the scheduling architecture, 
+    which makes possible the affinity between container tasks that gives greater efficiency. 
+    It supports multiple container formats. It has extensive support for various container 
+    networking solutions and container storage."
+    -->
+</div>
+</section>
+
+<div class="banner3">
+  <div class="banner3text">
+    “Kubernetes 基本上解决了我们的大部分问题。
+    以前，部署时间大约需要一周，现在只需几分钟。
+    开发人员很高兴。使用 Kubernetes 的部门也很高兴。”
+    <!--
+    "Kubernetes basically solved most of our problems. 
+    Before, the time of deployment took about a week, now it only takes minutes. 
+    The developers are happy. That department is also quite happy."  
+    -->
+  </div>
+</div>
+
+<section class="section3">
+<div class="fullcol">
+      最重要的是，这对底线有影响。侯培新说，
+      “我们还看到，在某些情况下，运营开支会大幅削减 20% 到 30%，这对我们的业务非常有帮助”。<br><br>
+      <!--
+      And not least of all, there’s an impact on the bottom line. 
+      Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent, 
+      which is very helpful for our business."<br><br>
+      -->
+
+    华为对这些初步结果感到满意，并看到客户对云原生技术的需求，因此加大了 Kubernetes 的投入。
+    2016 年春，公司不仅成为用户，而且成为了供应商。<br><br>
+    <!--
+    Pleased with those initial results, and seeing a demand for cloud native technologies from its customers, 
+    Huawei doubled down on Kubernetes. 
+    In the spring of 2016, the company became not only a user but also a vendor.<br><br>  
+    -->
+
+    “我们构建了 Kubernetes 技术解决方案”，侯培新说，
+    指的是华为的<a href="http://developer.huawei.com/ict/en/site-paas"> FusionStage™ </a> PaaS 输出。
+    <!--
+    "We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei’s 
+    <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a> PaaS offering. 
+    -->
+
+    “我们的客户，从非常大的电信运营商到银行，都喜欢云原生的想法。他们喜欢 Kubernetes 的技术。
+    但是他们需要花费大量的时间来分解他们的应用程序，将它们转换为微服务体系结构。
+    作为解决方案提供者，我们帮助他们。
+    <!--
+    "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. 
+    They like Kubernetes technology. But they need to spend a lot of time to decompose their applications 
+    to turn them into microservice architecture, and as a solution provider, we help them. 
+    -->
+
+    我们已经开始与一些中国银行合作，我们看到中国移动（China Mobile）和德国电信（Deutsche Telekom）等客户对我们很感兴趣”。<br><br>
+    <!--
+    We’ve started to work with some Chinese banks, and we see a lot of interest from our customers 
+    like <a href="http://www.chinamobileltd.com/">China Mobile</a> and 
+    <a href="https://www.telekom.com/en">Deutsche Telekom</a>."<br><br>
+    -->
+
+    “如果你是一个用户，你就仅仅是个用户”，侯培新补充道，“但如果你是一个供应商，为了说服你的客户，你应该自己使用它。
+    <!--
+    "If you’re just a user, you’re just a user," adds Hou. 
+    "But if you’re a vendor, in order to even convince your customers, you should use it yourself. 
+    -->
+
+    幸运的是，因为华为有很多员工，我们可以利用这种技术来展示我们所能构建的云的规模，向客户提供智慧服务”。
+    <!--
+    Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology. 
+    We provide customer wisdom."
+    -->
+
+    尽管华为拥有自己的私有云，但其许多客户使用华为的解决方案运行跨云应用程序。
+    这是一个很大的卖点，大多数公共云提供商现在都支持 Kubernetes。
+    侯培新说，“这使得跨云转换比其他解决方案更容易”。<br><br>
+    <!--
+    While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei’s solutions. 
+    It’s a big selling point that most of the public cloud providers now support Kubernetes. 
+    "This makes the cross-cloud transition much easier than with other solutions," says Hou.<br><br>
+    -->
+</div>
+</section>
+
+<div class="banner4">
+  <div class="banner4text">
+    “我们的客户，从非常大的电信运营商到银行，都喜欢云原生的想法。他们喜欢 Kubernetes 的技术。
+    但是他们需要花很多时间来分解他们的应用程序，把它们变成微服务体系结构，作为一个解决方案提供商，我们帮助他们。”
+    <!--
+    "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. 
+    They like Kubernetes technology. But they need to spend a lot of time to decompose their applications 
+    to turn them into microservice architecture, and as a solution provider, we help them."
+    -->
+  </div>
+</div>
+
+<section class="section4">
+<div class="fullcol">
+
+    在华为内部，一旦他的团队完成内部业务流程部门向 Kubernetes 的转型，侯培新希望说服更多部门转向云原生开发和实践。
+    <!--
+    Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes, 
+    Hou is looking to convince more departments to move over to the cloud native development cycle and practice. 
+    -->
+
+    “我们有很多软件开发人员，所以我们将为他们提供我们的平台作为服务解决方案，我们自己的产品”，
+    他说，“我们希望在他们的迭代周期中看到显著的成本削减”。<br><br>
+    <!--
+    "We have a lot of software developers, 
+    so we will provide them with our platform as a service solution, our own product," he says. 
+    "We would like to see significant cuts in their iteration cycle."<br><br>
+    -->
+
+    在见证了华为最开始的向 Kubernetes 的转型之后，侯培新为其他考虑该技术的公司提供了建议，
+    “当你开始设计应用程序的架构时，首先考虑云原生，然后再考虑微服务架构”，他说，“我想你会从中受益”。<br><br>
+    <!--
+    Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology: 
+    "When you start to design the architecture of your application, think about cloud native, 
+    think about microservice architecture from the beginning," he says. 
+    "I think you will benefit from that."<br><br>
+    -->
+
+    但是如果您已经有了遗留应用程序，“首先从这些应用程序中一些对微服务友好的部分开始，
+    这些部分相对容易分解成更简单的部分，并且相对轻量级”，侯培新说，
+    <!--
+    But if you already have legacy applications, "start from some microservice-friendly part of those applications first, 
+    parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says. 
+    -->
+
+    “不要从一开始就认为我想在几天内将整个架构或所有东西都迁移到微服务中。
+    不要把它当作目标。你应该循序渐进地做这件事。
+    我想说的是，对于遗留应用程序，并不是每个部分都适合微服务架构”。<br><br>
+    <!--
+    "Don’t think from day one that within how many days I want to move the whole architecture, 
+    or move everything into microservices. Don’t put that as a kind of target. 
+    You should do it in a gradual manner. And I would say for legacy applications, 
+    not every piece would be suitable for microservice architecture. No need to force it."<br><br>  
+    -->
+
+  毕竟，尽管侯培新对华为的 Kubernetes 充满热情，但他估计，
+  “未来 10 年，或许 80% 的工作负载可以分布式地在云原生环境中运行，但仍然有 20% 不是，但是没关系。
+  如果我们能够让 80% 的工作负载真正是云原生的、敏捷的，那么最终会有一个更好的世界”。
+  <!--
+  After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years, 
+  maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. 
+  There’s still 20 percent that’s not, but it’s fine. 
+  If we can make 80 percent of our workload really be cloud native, to have agility, 
+  it’s a much better world at the end of the day."
+  -->
+</div>
+</section>
+
+<div class="banner5">
+  <div class="banner5text">
+    “未来 10 年，可能 80% 的工作负载可以分布式地在云原生环境中运行，但仍然有 20% 不是，不过没关系。
+    如果我们能够让 80% 的工作负载真正是云原生的、敏捷的，那么最终会有一个更好的世界。”
+    <!--
+    "In the next 10 years, maybe 80 percent of the workload can be distributed, 
+    can be run on the cloud native environments. 
+    There’s still 20 percent that’s not, but it’s fine. 
+    If we can make 80 percent of our workload really be cloud native, to have agility, 
+    it’s a much better world at the end of the day."
+    -->
+  </div>
+</div>
+<section class="section5">
+<div class="fullcol">
+  在不久的将来，侯培新期待着围绕着 Kubernetes 开发的新功能，尤其是华为正在开发的那些功能。
+  <!--
+  In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes, 
+  not least of all the ones that Huawei is contributing to. 
+  -->
+
+  华为的工程师已经在为联邦功能(将多个 Kubernetes 集群放在一个框架中进行无缝管理)、调度、容器网络和存储，以及刚刚发布的一项名为
+  <a href="http://containerops.org/"的> Container Ops </a>的技术工作，这是一个 DevOps 管道引擎。
+  <!--
+  Huawei engineers have worked on the federation feature 
+  (which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling, 
+  container networking and storage, and a just-announced technology called 
+  <a href="http://containerops.org/">Container Ops</a>, which is a DevOps pipeline engine.
+  -->
+
+  “这将把每个 DevOps 作业放到一个容器中”，他解释说，“这种容器机制使用 Kubernetes 运行，也用于测试 Kubernetes。
+  有了这种机制，我们可以比以前更容易地创建、共享和管理容器化 DevOps 作业”。<br><br>
+  <!--
+  "This will put every DevOps job into a container," he explains. 
+  "And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes. 
+  With that mechanism, we can make the containerized DevOps jobs be created, 
+  shared and managed much more easily than before."<br><br>
+  -->
+
+  尽管如此，侯培新认为这项技术只是实现其全部潜力的一半。
+  首先，也是最重要的，他想要扩大它可以协调的规模，
+  这对于华为这样的超大规模公司以及它的一些客户来说非常重要。<br><br>
+  <!--
+  Still, Hou sees this technology as only halfway to its full potential. 
+  First and foremost, he’d like to expand the scale it can orchestrate, 
+  which is important for supersized companies like Huawei –  as well as some of its customers.<br><br>
+  -->
+
+  侯培新自豪地指出，在华为第一位工程师成为 Kubernetes 的贡献者和传道者两年后，华为现在是这个社区的最大贡献者。
+  他说，“我们发现，你对社区的贡献越大，你得到的回报也就越多”。
+  <!--
+  Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes, 
+  Huawei is now a top contributor to the community. "We’ve learned that the more you contribute to the community," 
+  he says, "the more you get back."
+  -->
+</div>
+</section>
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>
@@ -0,0 +1,93 @@
+---
+title: 案例研究：IBM
+
+case_study_styles: true
+cid: caseStudies
+css: /css/style_ibm.css
+---
+
+<!-- <div class="banner1" style="background-image: url('/images/CaseStudy_ibm_banner1.jpg')">
+  <h1> CASE STUDY:<img src="/images/ibm_logo.png" class="header_logo" style="width:10%"><br> <div class="subhead">Building an Image Trust Service on Kubernetes with Notary and TUF</div></h1>
+
+</div> -->
+
+<div class="banner1">
+  <h1> 案例研究：<img src="/images/ibm_logo.png" width="18%" style="margin-bottom:-5px;margin-left:10px;"><br> <div class="subhead">在 Kubernetes 上使用 Notary 和 TUF 建立镜像信任服务</div></h1>
+
+</div>
+
+<div class="details">
+    公司 &nbsp;<b>IBM</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;位置 &nbsp;<b>阿蒙克， 纽约</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;行业 &nbsp;<b>云计算</b>
+</div>
+
+<hr>
+<section class="section1">
+<div class="cols">
+  <div class="col1">
+    <h2>挑战</h2>
+        <!-- <a href="https://www.ibm.com/cloud/">IBM Cloud</a> offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed <a href="https://kubernetes.io">Kubernetes</a> and containers, to <a href="https://www.cloudfoundry.org">Cloud Foundry</a> platform as a service (PaaS). These runtimes are combined with the power of the company’s enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM’s Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service. -->
+<a href="https://www.ibm.com/cloud/">IBM Cloud</a> 提供公共、私有和混合云功能，包括基于 OpenWhisk 的服务 （FaaS）、托管于 <a href="https://kubernetes.io">Kubernetes</a> 和容器，以及 <a href="https://www.cloudfoundry.org">Cloud Foundry</a> 服务 （PaaS） 的各种运行时。这些运行时与公司企业技术（如 MQ 和 DB2、其现代人工智能 （AI） Watson 和数据分析服务）的强大功能相结合。IBM Cloud 用户可以使用其目录中 170 多个不同云原生服务的功能，包括 IBM 的气象公司 API 和数据服务等功能。在 2017 年后期，IBM 云容器托管团队希望构建镜像信任服务。<br><br>
+ <h2>解决方案</h2>
+      <!-- The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the <a href="https://www.cncf.io">Cloud Native Computing Foundation (CNCF)</a> open source project <a href="https://github.com/theupdateframework/notary">Notary</a>, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM’s trust story, since it makes it possible for users to consume the company’s Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM’s cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they're loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification. -->
+2018 年 2 月，这项新服务在 IBM 云中公开发布。IBM 云容器托管团队的软件开发者 Michael Hough 说，名为 Portieris 的镜像信任服务完全基于 <a href="https://www.cncf.io">Cloud Native Computing Foundation (CNCF)</a> 的开源项目 <a href="https://github.com/theupdateframework/notary">Notary</a>。Portieris 是 Kubernetes 的准入控制器，用于强制执行适当的信任等级。用户可以为每个 Kubernetes 命名空间或在集群级别创建镜像安全策略，并为不同的镜像强制实施不同级别的信任。Portieris 是 IBM 信任内容的关键部分，因为它使用户能够从 IKS 集群中使用公司的 Notary。产品是 Notary 服务器在 IBM 的云中运行，然后 Portieris 在 IKS 集群内运行。这使用户能够让 IKS 集群验证他们加载容器的镜像是否包含他们期望的内容，而 Portieris 是允许 IKS 集群应用该验证的原因。
+
+  </div>
+<div class="col2">
+<h2>影响</h2>
+     <!-- IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose." -->
+IBM 打算提供基于 Kubernetes 的容器服务和镜像托管服务，目的是为其企业客户提供完全安全的端到端平台。Hough 说：“镜像签名是该产品的关键部分之一，我们的容器托管团队将 Notary 视为在当前 Docker 和容器生态系统中实现该功能的实际方式。”该公司以前没有提供镜像签名，Notary 是它用来实现该功能的工具。“我们有一个多租户 Docker 托管服务，具有私有镜像托管功能，” Hough 说。“ Docker 托管使用哈希值来确保镜像内容正确，并且数据在传输和静态时都进行了加密。但它没有提供任何保证谁推镜像。我们使用 Notary 来允许用户在其专用注册表命名空间中签名镜像（如果他们愿意的话）。”
+</div>
+
+</div>
+</section>
+<div class="banner2">
+  <div class="banner2text">
+   <!-- "We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Michael Hough, a software developer with the IBM Container Registry team</span> -->
+   “我们将 CNCF 视为云原生开源的安全避难所，为成员项目（无论是原始供应商还是项目）提供稳定性、使用寿命和预期维护。”<br><br><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;">- Michael Hough, IBM 容器托管团队软件开发人员</span>
+  </div>
+</div>
+<section class="section2">
+<div class="fullcol">
+  <!-- <h2>Docker had already created the Notary project as an implementation of <a href="https://github.com/theupdateframework/specification" style="text-decoration:underline">The Update Framework (TUF)</a>, and this implementation of TUF provided the capabilities for Docker Content Trust.</h2> "After contribution to CNCF of both TUF and Notary, we perceived that it was becoming the de facto standard for image signing in the container ecosystem", says Michael Hough, a software developer with the IBM Cloud Container Registry team. -->
+  <h2>Docker 已经创建了 Notary 项目作为 <a href="https://github.com/theupdateframework/specification" style="text-decoration:underline">The Update Framework (TUF)</a> 的实现，TUF 的此实现为 Docker 内容信任提供了功能。</h2> IBM 云容器托管团队的软件开发者 Michael Hough 说：“在 TUF 和 Notary 对 CNCF 做出了贡献后，我们发现它正在成为容器生态系统中镜像签名的实际标准。”<br><br>
+<!-- The key reason for selecting Notary was that it was already compatible with the existing authentication stack IBM’s container registry was using. So was the design of TUF, which does not require the registry team to have to enter the business of key management. Both of these were "attractive design decisions that confirmed our choice of Notary," he says. -->
+选择 Notary 的关键原因是它已经与 IBM 的容器托管正在使用的现有身份验证技术兼容。TUF 的设计也是如此，它不要求托管团队必须涉足密钥管理业务。他说，这两项都是“有吸引力的设计决定，证实了我们对 Notary 的选择是正确的。”<br><br>
+<!-- The introduction of Notary to implement image signing capability in IBM Cloud encourages increased security across IBM's cloud platform, "where we expect it will include both the signing of official IBM images as well as expected use by security-conscious enterprise customers," Hough says. "When combined with security policy implementations, we expect an increased use of deployment policies in CI/CD pipelines that allow for fine-grained control of service deployment based on image signers." -->
+在 IBM Cloud 中引入 Notary 功能以实现镜像签名，可提高 IBM 云平台的安全性，“我们预计这将包括签署 IBM 官方镜像以及预期的有安全需求的企业客户，” Hough 说。与安全策略实现结合使用时，我们预计 CI/CD 管道中会更多地使用部署策略，以便根据镜像签名者对服务部署进行精细控制。
+<!-- The availability of image signing "is a huge benefit to security-conscious customers who require this level of image provenance and security," Hough says. "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment." -->
+Hough 说，镜像签名的可用性“对于需要这种级别镜像来源和安全性的客户来说，是一个巨大的好处。”“借助我们的 IBM 云上的 Kubernetes 以及我们提供的许可控制器，它允许 IBM 服务以及 IBM 公共云的客户使用安全策略来控制服务部署。”
+</div>
+</section>
+<div class="banner3">
+  <div class="banner3text">
+    <!-- "Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span> -->
+    镜像签名是我们 Kubernetes 容器服务的关键部分之一，我们的容器托管团队将 Notary 视为在当前 Docker 和容器生态系统中实现该功能的实际方式。<br><br><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;">- Michael Hough, IBM 容器托管团队软件开发人员</span>
+
+  </div>
+</div>
+<section class="section3">
+<div class="fullcol">
+    <!-- Now that the Notary-implemented service is generally available in IBM’s public cloud as a component of its existing IBM Cloud Container Registry, it is deployed as a highly available service across five IBM Cloud regions. This high-availability deployment has three instances across two zones in each of the five regions, load balanced with failover support. "We have also deployed it with end-to-end TLS support through to our back-end IBM Cloudant persistence storage service," Hough says. -->
+现在，Notary 通常作为现有 IBM 云容器托管的一个组件在 IBM 的公共云中提供服务，因此它被部署为五个 IBM 云区域中的高可用服务。此高可用性部署在五个区域中的每个区域中各有三个实例，实现负载均衡与故障转移。Hough 说：“我们还将其部署到后端 IBM Cloudant 持久性存储服务，并随端到端 TLS 支持一起部署。”<br><br>
+    <!-- The IBM team has created and open sourced a Kubernetes admission controller called Portieris, which uses Notary signing information combined with customer-defined security policies to control image deployment into their cluster. "We are hoping to drive adoption of Portieris through its use of our Notary offering," Hough says. -->
+IBM 团队创建并开源了名为 Portieris 的 Kubernetes 准入控制器，该控制器使用 Notary 签名信息与客户定义的安全策略相结合，以控制将镜像部署到集群中。“我们希望通过使用我们的 Notary 服务来推动 Portieris 的使用，” Hough 说。<br><br>
+    <!-- IBM has been a key player in the creation and support of open source foundations, including CNCF. Todd Moore, IBM's vice president of Open Technology, is the current CNCF governing board chair and a number of IBMers are active across many of the CNCF member projects. -->
+IBM 在创建和支持开源基础（包括 CNCF）方面一直占据主导地位。IBM 开放技术副总裁 Todd Moore 是现任 CNCF 董事会主席，许多 IBM 员工活跃于 CNCF 成员项目中。
+</div>
+</section>
+<div class="banner4">
+  <div class="banner4text">
+   <!-- "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span> -->
+   “有新项目应对这些挑战，包括在 CNCF 内。我们一定会饶有兴趣地关注这些进步。我们发现 Notary 社区是一个积极友好的社区，对变化持开放态度，例如我们为持久存储添加的 CouchDB 后端。”<br><br> <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;">- Michael Hough, IBM 容器托管团队软件开发人员</span>
+  </div>
+</div>
+<section class="section4">
+  <div class="fullcol">
+<!-- The company has used other CNCF projects <a href="https://containerd.io">containerd</a>, <a href="https://www.envoyproxy.io">Envoy</a>, <a href="https://prometheus.io">Prometheus</a>, <a href="https://grpc.io">gRPC</a>, and <a href="https://github.com/containernetworking">CNI</a>, and is looking into <a href="https://github.com/spiffe">SPIFFE</a> and <a href="https://github.com/spiffe/spire">SPIRE</a> as well for potential future use. -->
+该公司已经使用的 CNCF 项目有 <a href="https://containerd.io">containerd</a>，<a href="https://www.envoyproxy.io">Envoy</a>，<a href="https://prometheus.io">Prometheus</a>，<a href="https://grpc.io">gRPC</a>，<a href="https://github.com/containernetworking">CNI</a>，而且正在探索 <a href="https://github.com/spiffe">SPIFFE</a> 和 <a href="https://github.com/spiffe/spire">SPIRE</a> 在未来的潜在可用性。<br><br>
+<!-- What advice does Hough have for other companies that are looking to deploy Notary or a cloud native infrastructure? -->
+对于希望部署 Notary 或云原生基础架构的其他公司，Hough 有何建议？<br><br>
+<!-- "While this is true for many areas of cloud native infrastructure software, we found that a high-availability, multi-region deployment of Notary requires a solid implementation to handle certificate management and rotation," he says. "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage." -->
+“虽然对于云原生基础结构软件的许多领域也是如此，但我们发现，高可用性、多区域的 Notary 部署需要扎实的实现来处理证书管理和轮换，”他说。“有新项目应对这些挑战，包括在 CNCF 内。我们一定会饶有兴趣地关注这些进步。我们发现 Notary 社区是一个积极友好的社区，对变化持开放态度，例如我们为持久存储添加的 CouchDB 后端。”
+  </div>
+</section>
@@ -0,0 +1,4 @@
+---
+title: LivePerson
+content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson
+---
--- a/Show More
+++ b/Show More
				`@@ -0,0 +1 @@`
				<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>