Merge pull request #23333 from savitharaghunathan/config_update_1_15

Update release-1.15 branch config.toml for release v1.19
Updated url for 1.18 in config.toml
2020-08-26 14:53:48 -05:00 · 2020-08-23 15:27:17 -04:00 · 2020-08-22 11:21:20 -04:00 · 2020-04-03 08:53:47 -07:00 · 2020-03-27 11:53:53 -04:00 · 2020-03-26 20:32:23 -07:00
200 changed files with 7075 additions and 318 deletions
@@ -1,5 +1,5 @@
 DOCKER       = docker
-HUGO_VERSION = 0.53
+HUGO_VERSION = 0.57.2
 DOCKER_IMAGE = kubernetes-hugo
 DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
 NODE_BIN     = node_modules/.bin
@@ -66,13 +66,13 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.15"
+latest = "v1.19"

-fullversion = "v1.15.0"
+fullversion = "v1.15.12"
 version = "v1.15"
-githubbranch = "master"
-docsbranch = "master"
-deprecated = false
+githubbranch = "v1.15.12"
+docsbranch = "release-1.15"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
 githubWebsiteRepo = "github.com/kubernetes/website"
@@ -83,13 +83,6 @@ announcement = false
 # announcement_message is only displayed when announcement = true; update with your specific message
 announcement_message = "The Kubernetes Documentation team would like your feedback!  Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."

-[[params.versions]]
-fullversion = "v1.15.0"
-version = "v1.15"
-githubbranch = "v1.15.0"
-docsbranch = "release-1.15"
-url = "https://kubernetes.io"
-
 [params.pushAssets]
 css = [
  "callouts",
@@ -102,32 +95,40 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.14.3"
-version = "v1.14"
-githubbranch = "v1.14.3"
-docsbranch = "release-1.14"
-url = "https://v1-14.docs.kubernetes.io"
+fullversion = "v1.19.0"
+version = "v1.19"
+githubbranch = "v1.19.0"
+docsbranch = "master"
+url = "https://kubernetes.io"

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

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

 [[params.versions]]
-fullversion = "v1.11.10"
-version = "v1.11"
-githubbranch = "v1.11.10"
-docsbranch = "release-1.11"
-url = "https://v1-11.docs.kubernetes.io"
+fullversion = "v1.16.14"
+version = "v1.16"
+githubbranch = "v1.16.14"
+docsbranch = "release-1.16"
+url = "https://v1-16.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.15.12"
+version = "v1.15"
+githubbranch = "v1.15.12"
+docsbranch = "release-1.15"
+url = "https://v1-15.docs.kubernetes.io"
+

 # Language definitions.

@@ -806,15 +806,11 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
        # A list of additional security groups to be added to the ELB
 ```

-#### Network Load Balancer support on AWS [alpha] {#aws-nlb-support}
+#### Network Load Balancer support on AWS {#aws-nlb-support}

-{{< warning >}}
-This is an alpha feature and is not yet recommended for production clusters.
-{{< /warning >}}
+{{< feature-state for_k8s_version="v1.15" state="beta" >}}

-Starting from Kubernetes v1.9.0, you can use AWS Network Load Balancer (NLB) with Services. To
-use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type`
-with the value set to `nlb`.
+To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type` with the value set to `nlb`.

 ```yaml
    metadata:
@@ -24,7 +24,7 @@ To set feature gates for a component, such as kubelet, use the `--feature-gates`
 --feature-gates="...,DynamicKubeletConfig=true"
 ```

-The following table is a summary of the feature gates that you can set on
+The following tables are a summary of the feature gates that you can set on
 different Kubernetes components.

 - The "Since" column contains the Kubernetes release when a feature is introduced
@@ -32,22 +32,18 @@ different Kubernetes components.
 - The "Until" column, if not empty, contains the last Kubernetes release in which
  you can still use a feature gate.

+{{< table caption="Feature gates for features in Alpha or Beta states" >}}
+
 | Feature | Default | Stage | Since | Until |
 |---------|---------|-------|-------|-------|
-| `Accelerators` | `false` | Alpha | 1.6 | 1.10 |
-| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 |
-| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 |
-| `AdvancedAuditing` | `true` | GA | 1.12 | - |
-| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 |
-| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
-| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
 | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
 | `APIListChunking` | `true` | Beta | 1.9 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
 | `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 |
 | `AttachVolumeLimit` | `true` | Beta | 1.12 | |
-| `BlockVolume` | `false` | Alpha | 1.9 | |
+| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
+| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
 | `BlockVolume` | `true` | Beta | 1.13 | - |
 | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
 | `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
@@ -67,17 +63,11 @@ different Kubernetes components.
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
 | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
 | `CSINodeInfo` | `true` | Beta | 1.14 | |
-| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
-| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
-| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
-| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
-| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
-| `CustomPodDNS` | `true` | GA | 1.14 | - |
 | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | |
 | `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
 | `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | |
-| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 |
+| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.10 |
 | `CustomResourceSubresources` | `true` | Beta | 1.11 | - |
 | `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 |
 | `CustomResourceValidation` | `true` | Beta | 1.9 | |
@@ -86,83 +76,54 @@ different Kubernetes components.
 | `DebugContainers` | `false` | Alpha | 1.10 | |
 | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | Beta | 1.10 | |
+| `DryRun` | `false` | Alpha | 1.12 | 1.12 |
 | `DryRun` | `true` | Beta | 1.13 | |
 | `DynamicAuditing` | `false` | Alpha | 1.13 | |
 | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
 | `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
-| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
-| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | |
 | `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | |
 | `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 |
 | `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | |
 | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
-| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
-| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
-| `HugePages` | `false` | Alpha | 1.8 | 1.9 |
-| `HugePages` | `true` | Beta| 1.10 | 1.13 |
-| `HugePages` | `true` | GA | 1.14 | |
 | `HyperVContainer` | `false` | Alpha | 1.10 | |
-| `Initializers` | `false` | Alpha | 1.7 | 1.13 |
-| `Initializers` | - | Deprecated | 1.14 | |
-| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
-| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
-| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
-| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
 | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | Beta | 1.15 | |
-| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
 | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
-| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
-| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | |
+| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
+| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
 | `MountContainers` | `false` | Alpha | 1.9 | |
-| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
-| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
-| `MountPropagation` | `true` | GA | 1.12 | |
-| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
 | `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
 | `NodeLease` | `true` | Beta | 1.14 | |
 | `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
-| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
-| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
-| `PersistentLocalVolumes` | `true` | GA | 1.14 | |
-| `PodPriority` | `false` | Alpha | 1.8 | 1.10 |
-| `PodPriority` | `true` | Beta | 1.11 | 1.13 |
-| `PodPriority` | `true` | GA | 1.14 | |
-| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
-| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
-| `PodReadinessGates` | `true` | GA | 1.14 | - |
-| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | |
+| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 |
 | `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
-| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
+| `QOSReserved` | `false` | Alpha | 1.11 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | |
-| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
 | `RequestManagement` | `false` | Alpha | 1.15 | |
+| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
 | `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
 | `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
 | `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
 | `RunAsGroup` | `true` | Beta | 1.14 | |
+| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | Beta | 1.14 | |
+| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
+| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
 | `SCTPSupport` | `false` | Alpha | 1.12 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | |
 | `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
-| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
-| `StorageObjectInUseProtection` | `true` | GA | 1.11 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
-| `StreamingProxyRedirects` | `true` | Beta | 1.5 | |
-| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
-| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
-| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
-| `SupportIPVSProxyMode` | `true` | GA | 1.11 | |
+| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
+| `StreamingProxyRedirects` | `true` | Beta | 1.6 | |
 | `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
 | `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
 | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
@@ -178,9 +139,6 @@ different Kubernetes components.
 | `TokenRequestProjection` | `true` | Beta | 1.12 | |
 | `TTLAfterFinished` | `false` | Alpha | 1.12 | |
 | `VolumePVCDataSource` | `false` | Alpha | 1.15 | |
-| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
-| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
-| `VolumeScheduling` | `true` | GA | 1.13 | |
 | `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
 | `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | |
 | `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - |
@@ -188,6 +146,76 @@ different Kubernetes components.
 | `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
 | `WatchBookmark` | `false` | Alpha | 1.15 | |
 | `WindowsGMSA` | `false` | Alpha | 1.14 | |
+| `WinDSR` | `false` | Alpha | 1.14 | |
+| `WinOverlay` | `false` | Alpha | 1.14 | |
+{{< /table >}}
+
+The following table contains feature gates for graduated or deprecated features.
+
+{{< table caption="Feature Gates for Graduated or Deprecated Features" >}}
+
+| Feature | Default | Stage | Since | Until |
+|---------|---------|-------|-------|-------|
+| `Accelerators` | `false` | Alpha | 1.6 | 1.10 |
+| `Accelerators` | - | Deprecated | 1.11 | - |
+| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 |
+| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 |
+| `AdvancedAuditing` | `true` | GA | 1.12 | - |
+| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 |
+| `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
+| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
+| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
+| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
+| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
+| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
+| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
+| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
+| `CustomPodDNS` | `true` | GA | 1.14 | - |
+| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
+| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
+| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
+| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
+| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 |
+| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
+| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
+| `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - |
+| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
+| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
+| `HugePages` | `false` | Alpha | 1.8 | 1.9 |
+| `HugePages` | `true` | Beta| 1.10 | 1.13 |
+| `HugePages` | `true` | GA | 1.14 | - |
+| `Initializers` | `false` | Alpha | 1.7 | 1.13 |
+| `Initializers` | - | Deprecated | 1.14 | - |
+| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
+| `KubeletConfigFile` | - | Deprecated | 1.10 | - |
+| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
+| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
+| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
+| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
+| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
+| `MountPropagation` | `true` | GA | 1.12 | - |
+| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
+| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
+| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
+| `PodPriority` | `false` | Alpha | 1.8 | 1.10 |
+| `PodPriority` | `true` | Beta | 1.11 | 1.13 |
+| `PodPriority` | `true` | GA | 1.14 | - |
+| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
+| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
+| `PodReadinessGates` | `true` | GA | 1.14 | - |
+| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
+| `PVCProtection` | - | Deprecated | 1.10 | - |
+| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
+| `StorageObjectInUseProtection` | `true` | GA | 1.11 | |
+| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
+| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
+| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
+| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
+| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
+| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
+| `VolumeScheduling` | `true` | GA | 1.13 | - |
+| `VolumeSubpath` | `true` | GA | 1.13 | - |
+{{< /table >}}

 ## Using a Feature

@@ -242,6 +270,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes
  that can be attached to a node.
   See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits) for more details.
+- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for balanced resource allocation
+  while scheduling. A node which has closer CPU, memory utilization, and volume count is favored by the scheduler
+  while making decisions.
 - `BlockVolume`: Enable the definition and consumption of raw block devices in Pods.
   See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
   for more details.
@@ -281,7 +312,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
  troubleshoot a running Pod.
 - `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
  based resource provisioning on nodes.
- `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests.
+- `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests
+  so that validation, merging, and mutation can be tested without committing.
 - `DynamicAuditing`: Enable [dynamic auditing](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)
 - `DynamicKubeletConfig`: Enable the dynamic configuration of kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/).
 - `DynamicProvisioningScheduling`: Extend the default scheduler to be aware of volume topology and handle PV provisioning.
@@ -291,6 +323,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ExpandInUsePersistentVolumes`: Enable expanding in-use PVCs. See [Resizing an in-use PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim).
 - `ExpandPersistentVolumes`: Enable the expanding of persistent volumes. See [Expanding Persistent Volumes Claims](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims).
 - `ExperimentalCriticalPodAnnotation`: Enable annotating specific pods as *critical* so that their [scheduling is guaranteed](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
+  This feature is deprecated by Pod Priority and Preemption as of v1.13.
 - `ExperimentalHostUserNamespaceDefaultingGate`: Enabling the defaulting user
   namespace to host. This is for containers that are using other host namespaces,
   host mounts, or containers that are privileged or using specific non-namespaced
@@ -324,6 +357,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
  being deleted when it is still used by any Pod.
  More details can be found [here](/docs/tasks/administer-cluster/storage-object-in-use-protection/).
+- `QOSReserved`: Allows resource reservations at the QoS level preventing pods at lower QoS levels from
+  bursting into resources requested at higher QoS levels (memory only for now).
 - `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that
  assigns a lowest possible score of 1 to a node that satisfies at least one of
  the input Pod's cpu and memory limits. The intent is to break ties between
@@ -369,5 +404,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `VolumeSubpathEnvExpansion`: Enable `subPathExpr` field for expanding environment variables into a `subPath`.
 - `WatchBookmark`: Enable support for watch bookmark events.
 - `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes.
+- `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
+- `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.

 {{% /capture %}}
@@ -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

 ### Control-plane 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,10 +0,0 @@
-#include <tunables/global>
-
-profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
-  #include <abstractions/base>
-
-  file,
-
-  # Deny all file writes.
-  deny /** w,
-}
@@ -3,6 +3,7 @@ title: "운영 수준의 컨테이너 오케스트레이션"
 abstract: "자동화된 컨테이너 배포, 스케일링과 관리"
 cid: home
 ---
+{{< announcement >}}

 {{< deprecationwarning >}}

@@ -223,13 +223,14 @@ rules:

 다음은 클라우드 제공사업자들이 구현한 CCM들이다.

-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
 * [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
+* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)

 ## 클러스터 관리

@@ -148,7 +148,7 @@ _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할

 ### LIST와 WATCH 필터링

-LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
+LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).

  * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
  * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
@@ -181,11 +181,11 @@ kubectl get pods -l 'environment,environment notin (frontend)'

 [`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.

-#### 서비스와 리플리케이션 컨트롤러
+#### 서비스와 레플리케이션 컨트롤러

-`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
+`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.

-서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
+서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.

 ```json
 "selector": {
@@ -27,16 +27,16 @@ weight: 30

 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.

-다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근  제어 정책을 갖게 된다.
+다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근  제어 정책을 갖게 된다.
 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.

 같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
 복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
-구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다.
+구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.

 ## 네임스페이스 다루기

-네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에
+네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
 기술되어 있다.

 ### 네임스페이스 조회
@@ -94,7 +94,7 @@ kubectl config view | grep namespace:

 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
-그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
+그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
 네임스페이스에도 속하지 않는다.

 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,
@@ -227,7 +227,7 @@ _디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/p
    다음에 이러한 파드를 업데이트 하려면 디플로이먼트의 파드 템플릿만 다시 업데이트 하면 된다.

    디플로이먼트는 업데이트되는 동안 일정한 수의 파드만 중단되도록 보장한다. 기본적으로
-    적어도 의도한 파드 수의 25% 이상이 동작하도록 보장한다(최대 25% 이상 불가).
+    적어도 의도한 파드 수의 75% 이상이 동작하도록 보장한다(최대 25% 이상 불가).

    또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
    기본적으로, 의도한 파드의 수 기준 최대 25%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
@@ -20,7 +20,7 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
 컨테이너 이전의 세상에서 같은 물리적 또는 가상의 머신에서 실행되는 것은
 같은 논리적 호스트에서 실행되고 있는 것을 의미한다.

-쿠버네티스는는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
+쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
 도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다.

 파드의 공유 컨텍스트는 Linux 네임 스페이스, 컨트롤 그룹(cgroup) 및
@@ -189,7 +189,7 @@ API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를
 Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.

 마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다.
-사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
+사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
 `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`

 마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다.
@@ -5,7 +5,6 @@ date: 2019-05-12
 full_link:
 short_description: >
  컨테이너화된 다양한 애플리케이션들이 실행되는 레이어.
-
 aka:
 tags:
 - fundamental
@@ -2,13 +2,17 @@
 title: 스태틱 파드(Static Pod)
 id: static-pod
 date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/static-pod/
+full_link: /docs/tasks/configure-pod-container/static-pod/
 short_description: >
  특정 노드의 Kubelet 데몬이 직접 관리하는 파드

-aka:
+aka: 
 tags:
 - fundamental
 ---
- API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이
- 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}.
+
+특정 노드의 Kubelet 데몬이
+ 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}로,
+ <!--more-->
+ 
+API 서버가 관찰하지 않는다.
@@ -9,20 +9,15 @@ short_description: >
 aka: 
 tags:
 - fundamental
- core-object
- workload
 ---
-  워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다.
+  워크로드는 쿠버네티스에서 구동되는 애플리케이션이다.

 <!--more--> 

-쿠버네티스는 
-애플리케이션의 현재 상태에 따라 워크로드의 디플로이먼트와 업데이트를 수행한다.
-워크로드는 데몬셋, 디플로이먼트, 잡, 파드, 레플리카셋, 레플리케이션컨트롤러, 스테이트풀셋과 같은 오브젝트를 포함한다.
+데몬셋, 디플로이먼트, 잡, 레플리카셋, 그리고 스테이트풀셋 오브젝트를 포함해서
+서로 다른 워크로드의 유형이나 부분을 대표하는 다양한 핵심 오브젝트.

-예를 들어, 웹 요소와 데이터베이스 요소가 있는 워크로드는 
-데이터베이스를 {{< glossary_tooltip text="파드" term_id="pod" >}}의 한 
-{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, 
-웹서버를 많은 웹 앱 {{< glossary_tooltip text="파드" term_id="pod" >}}로 구성된 
-{{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다.
+예를 들어, 웹 서버와 데이터베이스가 있는 워크로드는
+데이터베이스를 한 {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, 
+웹서버를 {{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다.

@@ -78,7 +78,7 @@ card:
 | [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;
-| [Gardener](https://gardener.cloud/)       |              |&#x2714;  |         | &#x2714;   |          |
+| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; (via OpenStack) | &#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) | |
@@ -105,5 +105,6 @@ card:
 | [Tencent Cloud](https://intl.cloud.tencent.com/)  | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) |   &#x2714;   |   &#x2714; |    |      |   &#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)
+| [Z.A.R.V.I.S.](https://zarvis.ai/) | &#x2714; | | | | | |

 {{% /capture %}}
@@ -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를 이용하여 프로파일을 설치할 것이나 다른 방법은
@@ -1,10 +0,0 @@
-#include <tunables/global>
-
-profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
-  #include <abstractions/base>
-
-  file,
-
-  # 모든 파일에 저장을 금지한다.
-  deny /** w,
-}
@@ -28,7 +28,7 @@ weight: 40

 <!-- To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. -->

-要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的*预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl`  来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。
+要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl`  来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。

 <!-- Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:  -->

@@ -39,7 +39,7 @@ weight: 40
  * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
  * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. -->

-*  **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)和[kube-scheduler](/docs/admin/kube-scheduler/)。
+*  **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
 * 集群中的每个非 master 节点都运行两个进程：
  * **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
  * **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
@@ -50,7 +50,7 @@ weight: 40

 <!-- Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details.  -->

-Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。
+Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。

 <!-- The basic Kubernetes objects include: -->

@@ -77,7 +77,7 @@ Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容

 <!-- The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. -->

-关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程，管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任一的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。
+关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。

 <!-- For example, when you use the Kubernetes API to create a Deployment object, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. -->

@@ -93,7 +93,7 @@ Kubernetes master 节点负责维护集群的目标状态。当你要与 Kuberne

 <!-- > The "master" refers to a collection of processes managing the cluster state.  Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. -->

-> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的性能及冗余。
+> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。

 <!-- ### Kubernetes Nodes -->

@@ -108,7 +108,7 @@ Kubernetes master 节点负责维护集群的目标状态。当你要与 Kuberne
 #### 对象元数据


-* [注释](/docs/concepts/overview/working-with-objects/annotations/)
+* [注解](/docs/concepts/overview/working-with-objects/annotations/)

 {{% /capture %}}

@@ -0,0 +1,4 @@
+---
+title: "Kubernetes 架构"
+weight: 30
+---
@@ -1,175 +1,395 @@
-title: 云控制器管理器的基本概念
+---
+title: 云控制器管理器的基础概念
+content_template: templates/concept
+weight: 30
+---

-## 云控制器管理器
+<!--
+---
+title: Concepts Underlying the Cloud Controller Manager
+content_template: templates/concept
+weight: 30
+---
+-->

-云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器，API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动，这种情况下，CCM运行在Kubernetes系统之上。

-云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。
+{{% capture overview %}}
+
+<!--
+The cloud controller manager (CCM) concept (not to be confused with the binary) was originally created to allow cloud specific vendor code and the Kubernetes core to evolve independent of one another. The cloud controller manager runs alongside other master components such as the Kubernetes controller manager, the API server, and scheduler. It can also be started as a Kubernetes addon, in which case it runs on top of Kubernetes.
+-->
+
+云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。
+
+<!--
+The cloud controller manager's design is based on a plugin mechanism that allows new cloud providers to integrate with Kubernetes easily by using plugins. There are plans in place for on-boarding new cloud providers on Kubernetes and for migrating cloud providers from the old model to the new CCM model.
+-->
+
+云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。
+
+<!--
+This document discusses the concepts behind the cloud controller manager and gives details about its associated functions.
+-->

 本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。

-下面这张图描述了没有云控制器管理器的Kubernetes集群架构：
+<!--
+Here's the architecture of a Kubernetes cluster without the cloud controller manager: 
+-->
+
+这是没有云控制器管理器的 Kubernetes 集群的架构：
+
+<!--
+![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
+-->
+
+![没有云控制器管理器的 Kubernetes 架构](/images/docs/pre-ccm-arch.png)
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+<!--
+## Design
+-->

-![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png)

 ## 设计

-在上图中，Kubernetes和云服务供应商通过几个不同的组件进行了集成，分别是：
+<!--
+In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
+-->
+
+在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：
+
+<!--
+* Kubelet
+* Kubernetes controller manager
+* Kubernetes API server
+-->

 * Kubelet
 * Kubernetes 控制管理器
-* Kubernetes API服务器
+* Kubernetes API 服务器

-而CCM整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示：
+<!--
+The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this:
+-->

-![有云控制器管理器的 K8s 集群架构](/images/docs/post-ccm-arch.png)
+CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：

-## CCM的组件
+<!-- 
+![CCM Kube Arch](/images/docs/post-ccm-arch.png) 
+-->

-CCM突破了Kubernetes控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎：
+![含有云控制器管理器的 Kubernetes 架构](/images/docs/post-ccm-arch.png)
+
+<!--
+## Components of the CCM
+-->
+## CCM 的组成部分
+
+<!--
+The CCM breaks away some of the functionality of Kubernetes controller manager (KCM) and runs it as a separate process. Specifically, it breaks away those controllers in the KCM that are cloud dependent. The KCM has the following cloud dependent controller loops:
+ -->
+
+CCM 打破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个单独的进程运行。具体来说，它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器：
+
+<!--
+ * Node controller
+ * Volume controller
+ * Route controller
+ * Service controller
+-->

 * 节点控制器
 * 卷控制器
 * 路由控制器
 * 服务控制器
+<!--
+In version 1.9, the CCM runs the following controllers from the preceding list:
+ -->

-在1.8版本中，当前运行中的CCM从上面的列表中运行以下控制器：
+在 1.9 版本中，CCM 运行前述列表中的以下控制器：
+
+<!--
+* Node controller
+* Route controller
+* Service controller
+-->

 * 节点控制器
 * 路由控制器
 * 服务控制器

-另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域（Zone）和区（Region）标签进行设置。
+{{< note >}}
+<!--
+Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
+-->

-**注意**：卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到CCM之中。
+注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。

-原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。
+{{< /note >}}

-考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至CSI准备就绪。
+<!--
+The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
+-->

-云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。
+使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。

-## CCM功能
+<!--
+Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
+-->

-CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。
+考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。
+
+<!--
+## Functions of the CCM
+-->
+
+## CCM 的功能
+
+<!--
+The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
+-->
+
+CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。
+
+<!--
+### 1. Kubernetes controller manager
+-->

 ### 1. Kubernetes 控制器管理器

-CCM的大部分功能都来自KCM。 如上一节所述，CCM运行以下控制引擎：
+<!--
+The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
+-->
+
+CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。
+
+<!--
+* Node controller
+* Route controller
+* Service controller
+-->

 * 节点控制器
 * 路由控制器
 * 服务控制器
-* PersistentVolumeLabels控制器
+
+<!--
+#### Node controller
+-->

 #### 节点控制器

-节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能：
+<!--
+The Node controller is responsible for initializing a node by obtaining information about the nodes running in the cluster from the cloud provider. The node controller performs the following functions:
+-->

-1.使用云特定域（Zone）/区（Region）标签初始化节点。
+节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点，节点控制器执行以下功能：

-1.使用特定于云的实例详细信息初始化节点，例如类型和大小。
+<!--
+1. Initialize a node with cloud specific zone/region labels.
+2. Initialize a node with cloud specific instance details, for example, type and size.
+3. Obtain the node's network addresses and hostname.
+4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
+If the node has been deleted from the cloud, delete the Kubernetes Node object.
+-->

-1.获取节点的网络地址和主机名。
+1. 使用特定于云的域（zone）/区（region）标签初始化节点；
+2. 使用特定于云的实例详细信息初始化节点，例如，类型和大小；
+3. 获取节点的网络地址和主机名；
+4. 如果节点无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，请删除 Kubernetes 节点对象。

-1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除Kubernetes节点对象。
+<!--
+#### Route controller
+-->

 #### 路由控制器

-路由控制器负责为云配置正确的路由，以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。
+<!--
+The Route controller is responsible for configuring routes in the cloud appropriately so that containers on different nodes in the Kubernetes cluster can communicate with each other. The route controller is only applicable for Google Compute Engine clusters.
+-->
+
+Route 控制器负责适当地配置云中的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。
+
+<!--
+#### Service Controller
+-->

 #### 服务控制器

-服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如ELB或Google LB）以反映Kubernetes中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。
+<!--
+The Service controller is responsible for listening to service create, update, and delete events. Based on the current state of the services in Kubernetes, it configures cloud load balancers (such as ELB or Google LB) to reflect the state of the services in Kubernetes. Additionally, it ensures that service backends for cloud load balancers are up to date.
+-->

-#### PersistentVolumeLabels 控制器
+服务控制器负责监听服务的创建、更新和删除事件。根据 Kubernetes 中各个服务的当前状态，它配置云负载均衡器（如 ELB 或 Google LB）以反映 Kubernetes 中的服务状态。此外，它还确保云负载均衡器的服务后端是最新的。

-PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。
-
-这些标签对于pod的调度工作是非常重要的，因为这些卷只能在它们所在的域（Zone）/区（Region）内工作，因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。
-
-PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说，在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器（它是一个许可控制器）中的PV标签逻辑移动到CCM。 它不在KCM上运行。
+<!--
+### 2. Kubelet
+-->

 ### 2. Kubelet

-Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前，是由kubelet采用包含云特定信息的方式对节点进行初始化，如IP地址、区（Region）/域（Zone）标签和实例类型信息；引入CCM之后，这部分的初始化操作就从kubelet转移到了CCM中。
+<!--
+The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
+-->

-在引入CCM后的新的模型中，kubelet采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到CCM使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。
+节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。

-### 3. Kubernetes API服务器
+<!--
+In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
+-->

-PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM，如前面部分所述。
+在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。
+
+<!--
+## Plugin mechanism
+-->

 ## 插件机制

-云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。
+<!--
+The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
+-->

-上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。
+云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说，它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。

-有关开发插件的更多信息，请参阅
-[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。
+<!--
+The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
+-->
+
+上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。
+
+<!--
+For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
+ -->
+
+有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
+
+<!--
+## Authorization
+-->

 ## 授权

-本节分解了CCM对各种API对象的访问，以执行其操作。
+<!--
+This section breaks down the access required on various API objects by the CCM to perform its operations.
+-->
+
+本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。
+
+<!--
+### Node Controller
+-->

 ### 节点控制器

-节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。
+<!--
+The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
+-->
+
+Node 控制器仅适用于 Node 对象，它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。
+
+<!--
+v1/Node:

-v1/Node: 
 - Get
 - List
 - Create
 - Update
 - Patch
 - Watch
+- Delete
+-->
+
+v1/Node:
+
+- Get
+- List
+- Create
+- Update
+- Patch
+- Watch
+- Delete
+
+<!--
+### Route controller
+-->

 ### 路由控制器

-路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。
+<!--
+The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
+-->
+
+路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。
+
+v1/Node:

-v1/Node: 
 - Get

+<!--
+### Service controller
+-->
+
 ### 服务控制器

-服务控制器侦听服务对象创建、更新和删除事件，然后对这些服务的端点进行恰当的配置。
+<!--
+The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
+-->

-要访问服务，它需要罗列和监控权限。要更新服务，它需要修补和更新权限。
+服务控制器侦听 Service 对象创建、更新和删除事件，然后适当地为这些服务配置端点。

-要为服务设置端点，需要访问创建、列表、获取、监视和更新。
+<!--
+To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
+-->
+
+要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。
+
+<!--
+To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
+-->
+
+要为服务设置端点，需要访问 create、list、get、watch 和 update。

 v1/Service:
+
 - List
 - Get
 - Watch
 - Patch
 - Update

-### PersistentVolumeLabels 控制器
-
-PersistentVolumeLabels控制器监听PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。
-
-v1/PersistentVolume:
- Get
- List
- Watch
- Update
+<!--
+### Others
+-->

 ### 其它

-CCM核心的实现需要创建事件的权限，为了确保安全操作，需要创建ServiceAccounts的权限。
+<!--
+The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
+-->
+
+CCM 核心的实现需要访问权限以创建事件，并且为了确保安全操作，它需要访问权限以创建服务账户。

 v1/Event:
+
 - Create
 - Patch
 - Update

 v1/ServiceAccount:
+
 - Create

-针对CCM的RBAC ClusterRole如下所示：
+<!--
+The RBAC ClusterRole for the CCM looks like this:
+-->
+
+针对 CCM 的 RBAC ClusterRole 看起来像这样：

 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -233,17 +453,49 @@ rules:
  - update
 ```

+<!--
+## Vendor Implementations
+-->
+
 ## 供应商实施

-以下云服务供应商为自己的云部署了CCM。
+<!--
+The following cloud providers have implemented CCMs:
+-->

-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+以下云服务提供商已实现了 CCM：
+
+<!--
 * [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [Linode](https://github.com/linode/linode-cloud-controller-manager)
+* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+-->
+
+* [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
+* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [Linode](https://github.com/linode/linode-cloud-controller-manager)
+* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+
+<!--
+## Cluster Administration
+-->

 ## 群集管理

-[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。
+<!--
+Complete instructions for configuring and running the CCM are provided
+[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). -->
+
+[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
+
+{{% /capture %}}
+
@@ -0,0 +1,370 @@
+---
+title: 日志架构
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+
+<!--
+Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
+-->
+应用程序日志和系统日志可以帮助您了解群集内部发生了什么。它们对于调试问题和监视集群活动也是特别有用的。大多数的现代化的应用程序都有某种日志记录机制; 同样地，大多数容器引擎设计的时候就考虑到了支持某种日志记录机制。对于容器化的应用程序来说，最简单而又最受欢迎的日志记录方法是写到标准输出和标准错误流中。
+
+<!--
+However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
+-->
+然而，容器引擎或运行时提供的原生功能通常不满足完整的日志记录解决方案。例如，通常如果容器崩溃，pod被驱逐，或节点死亡，您仍然希望能够访问应用程序的日志。因此，日志记录应具有独立于节点、pod或容器的存储和生命周期。这个概念称为_集群级日志记录_。集群级日志记录需要单独的后端来存储，分析和查询日志。Kubernetes自身不提供日志数据的存储解决方案，但您可以将许多现有的日志记录解决方案集成到Kubernetes集群中。
+
+{{% /capture %}}
+
+{{% capture body %}}
+<!--
+Cluster-level logging architectures are described in assumption that
+a logging backend is present inside or outside of your cluster. If you're
+not interested in having cluster-level logging, you might still find
+the description of how logs are stored and handled on the node to be useful.
+-->
+集群级日志记录架构假设你在集群内部或外部存在记录日志的后端。即使您对集群级别的日志记录不感兴趣，了解在节点上是如何存储和处理日志也是非常有用的。
+
+<!-- ## Basic logging in Kubernetes -->
+## Kubernetes中的基本日志记录
+
+<!--
+In this section, you can see an example of basic logging in Kubernetes that
+outputs data to the standard output stream. This demonstration uses
+a [pod specification](/examples/debug/counter-pod.yaml) with
+a container that writes some text to standard output once per second.
+-->
+在本节中，您可以看到在Kubernetes中日志记录的基本示例，该示例将数据输出到标准输出。此演示使用的[pod规范](/examples/debug/counter-pod.yaml)中，容器每秒将一些文本写入到标准输出。
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+<!-- To run this pod, use the following command: -->
+要运行此pod，请使用以下命令：
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+<!-- The output is: -->
+输出是：
+```
+pod/counter created
+```
+<!-- To fetch the logs, use the `kubectl logs` command, as follows: -->
+要获取日志，请按照如下使用 `kubectl logs` 命令
+```shell
+kubectl logs counter
+```
+输出是：
+
+```
+0: Mon Jan  1 00:00:00 UTC 2001
+1: Mon Jan  1 00:00:01 UTC 2001
+2: Mon Jan  1 00:00:02 UTC 2001
+...
+```
+<!-- You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details. -->
+如果容器已崩溃，您可以使用`kubectl logs --previous`从先前实例化的的容器中获取日志。如果您的pod有多个容器，则应通过在命令中附加容器名称来指定要访问的容器的日志。有关详细信息，请参阅[kubectl logs文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。
+
+
+<!-- ## Logging at the node level -->
+## 节点级别的日志记录
+
+![节点级别的日志记录](/images/docs/user-guide/logging/logging-node-level.png)
+<!--
+Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
+-->
+容器化的应用程序写入到`stdout`和`stderr`的一切都会被容器运行时处理和重定向。例如，Docker容器引擎将这两个流重定向到Kubernetes中配置为以json格式写入到文件的[日志驱动程序](https://docs.docker.com/engine/admin/logging/overview)。
+
+{{< note >}}
+<!-- The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher. -->
+注意： Docker json日志记录驱动程序将每行视为单独的消息。使用Docker日志记录驱动程序时，不直接支持多行消息。您需要在日志代理级别或更高级别处理多行消息。
+{{< /note >}}
+
+<!--
+By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
+-->
+默认情况下，如果一个容器重新启动，则kubelet会使用其日志保留一个已终止的容器。如果从节点中逐出pod，则所有相应的容器也会被逐出，以及它们的日志。
+
+<!--
+An important consideration in node-level logging is implementing log rotation,
+so that logs don't consume all available storage on the node. Kubernetes
+currently is not responsible for rotating logs, but rather a deployment tool
+should set up a solution to address that.
+For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
+there is a [`logrotate`](https://linux.die.net/man/8/logrotate)
+tool configured to run each hour. You can also set up a container runtime to
+rotate application's logs automatically, e.g. by using Docker's `log-opt`.
+In the `kube-up.sh` script, the latter approach is used for COS image on GCP,
+and the former approach is used in any other environment. In both cases, by
+default rotation is configured to take place when log file exceeds 10MB.
+-->
+节点级日志记录中的一个需要重要考虑的问题是实现日志轮换，以便日志不会占用节点上的所有可用存储。Kubernetes目前不负责轮换日志，因此部署工具应该设置解决方案来解决这个问题。例如，在`kube-up.sh`脚本部署的Kubernetes集群中，有一个[logrotate](https://linux.die.net/man/8/logrotate) 工具配置为每小时运行一次。您还可以设置容器运行时以自动轮换应用程序的日志，例如使用Docker 的`log-opt`。在`kube-up.sh`脚本中，后一种方法用于GCP上的COS映像，前一种方法用于任何其他环境。在这两种情况下，默认情况下，轮换配置为在日志文件超过10MB时发生。
+
+<!--
+As an example, you can find detailed information about how `kube-up.sh` sets
+up logging for COS image on GCP in the corresponding [script][cosConfigureHelper].
+-->
+例如，您可以在`kube-up.sh`在相应的脚本中找到有关如何在GCP上设置COS映像日志记录的详细信息。
+
+<!--
+When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
+the basic logging example, the kubelet on the node handles the request and
+reads directly from the log file, returning the contents in the response.
+-->
+当您在基本日志记录示例中运行[`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) ，节点上的kubelet会处理请求并直接从日志文件中读取，并返回响应中的内容。
+
+{{< note >}}
+<!--
+Currently, if some external system has performed the rotation,
+only the contents of the latest log file will be available through
+`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
+the rotation and there are two files, one 10MB in size and one empty,
+`kubectl logs` will return an empty response.
+-->
+目前, 如果一些外部系统执行了日志轮转, 通过`kubectl logs`只能从最新的日志文件查看到日志。 也就是说如果文件超过了10mb，`logrotate`会执行日志轮转， 如果有两个文件，一个是10MB，一个是空的，那么`kubectl logs` 会返回空的响应。
+{{< /note >}}
+[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
+
+<!-- ### System component logs -->
+### 系统组件日志
+
+<!-- There are two types of system components: those that run in a container and those
+that do not run in a container. For example: -->
+系统组件有两种类型：在容器中运行的和不在容器中运行的。例如：
+
+<!-- * The Kubernetes scheduler and kube-proxy run in a container. -->
+* 在容器中运行的 kube-scheduler 和kube-proxy。
+<!-- * The kubelet and container runtime, for example Docker, do not run in containers. -->
+* 不在容器中运行的 kubelet 和容器运行时（例如Docker）。
+
+<!--
+On machines with systemd, the kubelet and container runtime write to journald. If
+systemd is not present, they write to `.log` files in the `/var/log` directory.
+System components inside containers always write to the `/var/log` directory,
+bypassing the default logging mechanism. They use the [klog][klog]
+logging library. You can find the conventions for logging severity for those
+components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
+-->
+在具有systemd的机器上，kubelet和容器运行时写入日志到journald。如果systemd不存在，它们将写入`/var/log`目录中的`.log`文件中。容器内的系统组件始终写入`/var/log`目录，绕过默认的日志记录机制。他们使用[klog][klog]日志库。您可以在[日志记录的开发文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)中找到关于这些组件的日志级别的约定。
+
+<!--
+Similarly to the container logs, system component logs in the `/var/log`
+directory should be rotated. In Kubernetes clusters brought up by
+the `kube-up.sh` script, those logs are configured to be rotated by
+the `logrotate` tool daily or once the size exceeds 100MB.
+-->
+与容器日志类似，/var/log 应该旋转目录中的系统组件日志。在`kube-up.sh`脚本提供的Kubernetes集群中，这些日志配置为每天或一旦大小超过100MB由工具`logrotate`轮换。
+
+[klog]: https://github.com/kubernetes/klog
+
+<!-- ## Cluster-level logging architectures -->
+## 集群级日志记录架构
+
+<!-- While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: -->
+虽然Kubernetes没有为集群级日志记录提供原生的解决方案，但您可以考虑几种常见的方法。以下是一些选项：
+
+<!-- * Use a node-level logging agent that runs on every node. -->
+* 使用在每个节点上运行的节点级日志记录代理。
+<!-- * Include a dedicated sidecar container for logging in an application pod. -->
+* 在Pod中使用专用于记录日志的边车容器。
+<!-- * Push logs directly to a backend from within an application. -->
+* 将日志直接从应用程序中推送到日志记录后端。
+
+<!-- ### Using a node logging agent -->
+### 使用节点日志记录代理
+
+![使用节点日志记录代理](/images/docs/user-guide/logging/logging-with-node-agent.png)
+
+<!-- You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node. -->
+您可以通过在每个节点上使用 _节点级的日志记录代理_ 来实现群集级日志记录。日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。
+
+<!-- Because the logging agent must run on every node, it's common to implement it as either a DaemonSet replica, a manifest pod, or a dedicated native process on the node. However the latter two approaches are deprecated and highly discouraged. -->
+由于日志记录代理必须在每个节点上运行，它可以用DaemonSet副本，Pod 或 本机进程来实现它的。然而，后两种方法被弃用并且非常不别推荐。
+
+<!-- Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_. -->
+对于Kubernetes集群，使用节点级日志记录代理是最常见和鼓励的方法，因为它每个节点只创建一个代理，并且不需要对节点上运行的应用程序进行任何更改。然而，节点级日志记录 _仅适用于应用程序的标准输出和标准错误_。
+
+<!-- Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node. -->
+虽然Kubernetes中没有指定日志代理，但是两个可选的日志代理与Kubernetes版本一起打包：用于Google Cloud Platform的[Stackdriver Logging](/docs/user-guide/logging/stackdriver)和[Elasticsearch](/docs/user-guide/logging/elasticsearch)。您可以在专用文档中找到更多信息和说明。两者都使用了自定义的配置的[fluentd](http://www.fluentd.org/)作为节点上的代理。
+
+<!-- ### Using a sidecar container with the logging agent -->
+### 使用带有日志记录代理的边车容器
+
+<!-- You can use a sidecar container in one of the following ways: -->
+您可以通过以下方式使用边车容器：
+
+<!-- * The sidecar container streams application logs to its own `stdout`. -->
+* sidecar容器将应用程序日志流式传输到自己的`stdout`。
+<!-- * The sidecar container runs a logging agent, which is configured to pick up logs from an application container. -->
+* sidecar容器运行日志记录代理程序，该代理程序配置为从应用程序容器中获取日志。
+
+<!-- #### Streaming sidecar container -->
+#### Streaming到sidecar容器
+
+![Sidecar container with a streaming container](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
+
+<!--
+By having your sidecar containers stream to their own `stdout` and `stderr`
+streams, you can take advantage of the kubelet and the logging agent that
+already run on each node. The sidecar containers read logs from a file, a socket,
+or the journald. Each individual sidecar container prints log to its own `stdout`
+or `stderr` stream.
+-->
+通过让您的sidecar容器streaming到他们自己的 `stdout`和`stderr`，您可以利用已经在每个节点上运行的kubelet和日志记录代理。
+sidecar容器从文件，套接字或日志中读取日志。每个单独的sidecar容器将日志打印到其自己`stdout` 或 `stderr`。
+
+<!--
+This approach allows you to separate several log streams from different
+parts of your application, some of which can lack support
+for writing to `stdout` or `stderr`. The logic behind redirecting logs
+is minimal, so it's hardly a significant overhead. Additionally, because
+`stdout` and `stderr` are handled by the kubelet, you can use built-in tools
+like `kubectl logs`.
+-->
+这种方法允许您将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入`stdout`或`stderr`的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。另外，因为 `stdout`、`stderr`由kubelet处理，你可以使用内置的工具`kubectl logs`。
+
+<!--
+Consider the following example. A pod runs a single container, and the container
+writes to two different log files, using two different formats. Here's a
+configuration file for the Pod:
+-->
+请考虑以下示例。单个容器的Pod，其中容器使用两种不同的格式写入两个不同的日志文件。这是Pod的配置文件：
+
+{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+
+<!--
+It would be a mess to have log entries of different formats in the same log
+stream, even if you managed to redirect both components to the `stdout` stream of
+the container. Instead, you could introduce two sidecar containers. Each sidecar
+container could tail a particular log file from a shared volume and then redirect
+the logs to its own `stdout` stream.
+-->
+即使您设法将两个组件重定向到容器的`stdout`流，在同一个日志流中包含不同格式的日志条目也是一团糟。相反，你可以引入两个边车容器。每个sidecar容器都可以从共享卷中拖出特定的日志文件，然后将日志重定向到自己的`stdout`流。
+
+<!-- Here's a configuration file for a pod that has two sidecar containers: -->
+这是一个包含两个sidecar容器的pod的配置文件：
+
+{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
+
+<!-- Now when you run this pod, you can access each log stream separately by
+running the following commands: -->
+现在，当您运行此pod时，可以通过运行以下命令分别访问每个日志流：
+
+```shell
+kubectl logs counter count-log-1
+```
+```
+0: Mon Jan  1 00:00:00 UTC 2001
+1: Mon Jan  1 00:00:01 UTC 2001
+2: Mon Jan  1 00:00:02 UTC 2001
+...
+```
+
+```shell
+kubectl logs counter count-log-2
+```
+```
+Mon Jan  1 00:00:00 UTC 2001 INFO 0
+Mon Jan  1 00:00:01 UTC 2001 INFO 1
+Mon Jan  1 00:00:02 UTC 2001 INFO 2
+...
+```
+
+<!--
+The node-level agent installed in your cluster picks up those log streams automatically without any further configuration. If you like, you can configure the agent to parse log lines depending on the source container.
+-->
+集群中安装的节点级代理会自动获取这些日志流，而无需进一步配置。如果你愿意，可以将代理配置为根据源容器解析日志行。
+
+<!--
+Note, that despite low CPU and memory usage (order of couple of millicores
+for cpu and order of several megabytes for memory), writing logs to a file and
+then streaming them to `stdout` can double disk usage. If you have
+an application that writes to a single file, it's generally better to set
+`/dev/stdout` as destination rather than implementing the streaming sidecar
+container approach.
+-->
+请注意，尽管CPU和内存使用率较低（cpu为几毫微秒，内存为几兆字节），但将日志写入文件然后将其流式传输到`stdout`可以使磁盘使用量增加一倍。如果您有一个写入单个文件的应用程序，通常最好将其设置 `/dev/stdout`为目标而不是 流式边车容器方式。
+
+<!--
+Sidecar containers can also be used to rotate log files that cannot be
+rotated by the application itself. An example
+of this approach is a small container running logrotate periodically.
+However, it's recommended to use `stdout` and `stderr` directly and leave rotation
+and retention policies to the kubelet.
+-->
+Sidecar容器还可用于旋转应用程序本身无法旋转的日志文件。这种方法的一个例子是定期运行logrotate的小容器。但是，建议直接使用`stdout`和`stderr`，并将轮换和保留策略保留给kubelet。
+
+<!-- #### Sidecar container with a logging agent -->
+#### 带有日志记录代理的sidecar容器
+
+![带有日志记录代理的sidecar容器](/images/docs/user-guide/logging/logging-with-sidecar-agent.png)
+
+<!--
+If the node-level logging agent is not flexible enough for your situation, you
+can create a sidecar container with a separate logging agent that you have
+configured specifically to run with your application.
+-->
+如果节点级日志记录代理程序对于你的场景来说不够灵活，您可以创建一个带有单独日志记录代理程序的sidecar容器，将代理程序专门配置为与您的应用程序一起运行。
+
+{{< note >}}
+<!--
+Using a logging agent in a sidecar container can lead
+to significant resource consumption. Moreover, you won't be able to access
+those logs using `kubectl logs` command, because they are not controlled
+by the kubelet.
+-->
+使用带有日志记录代理的sidecar容器可能会有资源损耗。 而且你不能通过`kubectl logs`访问到这些日志，因为他们不受kubelet控制
+{{< /note >}}
+
+<!--
+As an example, you could use [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
+which uses fluentd as a logging agent. Here are two configuration files that
+you can use to implement this approach. The first file contains
+a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
+-->
+举个例子，你可以使用[Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，它使用fluentd作为日志记录代理。以下是两个可用于实现此方法的配置文件。第一个文件包含配置fluentd的[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
+
+{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+
+{{< note >}}
+<!--
+The configuration of fluentd is beyond the scope of this article. For
+information about configuring fluentd, see the
+[official fluentd documentation](http://docs.fluentd.org/).
+-->
+配置fluentd超出了本文的范围。要知道更多的关于如何配置fluentd，请参考[fluentd 官方文档](http://docs.fluentd.org/).
+{{< /note >}}
+
+<!--
+The second file describes a pod that has a sidecar container running fluentd.
+The pod mounts a volume where fluentd can pick up its configuration data.
+-->
+第二个文件描述了一个运行了fluentd的sidecar容器的pod。该pod映射了一个卷，fluentd可以从中获取其配置数据。
+
+{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+
+<!-- After some time you can find log messages in the Stackdriver interface. -->
+一段时间后，您可以在Stackdriver界面中找到日志消息。
+
+<!--
+Remember, that this is just an example and you can actually replace fluentd
+with any logging agent, reading from any source inside an application
+container.
+-->
+
+请记住，这只是一个示例，您实际上可以用任何日志代理替换fluentd，从应用程序容器内的任何源读取日志。
+
+<!-- ### Exposing logs directly from the application -->
+### 直接从应用程序暴露日志
+
+![直接从应用程序暴露日志](/images/docs/user-guide/logging/logging-from-application.png)
+
+<!-- You can implement cluster-level logging by exposing or pushing logs directly from
+every application; however, the implementation for such a logging mechanism
+is outside the scope of Kubernetes.
+-->
+您可以通过直接从每个应用程序公开或推送日志来实现集群级日志记录; 但是，这种日志记录机制的实现超出了Kubernetes的范围。
+
+{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: "容器"
+weight: 50
+---
@@ -0,0 +1,229 @@
+---
+reviewers:
+- mikedanese
+- thockin
+title: 容器生命周期钩子
+content_template: templates/concept
+weight: 30
+---
+
+<!--
+reviewers:
+- mikedanese
+- thockin
+title: Container Lifecycle Hooks
+content_template: templates/concept
+weight: 30
+-->
+
+{{% capture overview %}}
+
+<!--
+This page describes how kubelet managed Containers can use the Container lifecycle hook framework
+to run code triggered by events during their management lifecycle.
+-->
+这个页面描述了 kubelet 管理的容器如何使用容器生命周期钩子框架来运行在其管理生命周期中由事件触发的代码。
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+<!--
+## Overview
+-->
+
+## 概述
+
+<!--
+Analogous to many programming language frameworks that have component lifecycle hooks, such as Angular,
+Kubernetes provides Containers with lifecycle hooks.
+The hooks enable Containers to be aware of events in their management lifecycle
+and run code implemented in a handler when the corresponding lifecycle hook is executed.
+-->
+类似于许多具有生命周期钩子组件的编程语言框架，例如Angular，Kubernetes为容器提供了生命周期钩子。
+钩子使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期钩子时运行在处理程序中实现的代码。
+
+<!--
+## Container hooks
+-->
+
+## 容器钩子
+
+<!--
+There are two hooks that are exposed to Containers:
+-->
+有两个钩子暴露在容器中:
+
+`PostStart`
+
+<!--
+This hook executes immediately after a container is created.
+However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
+No parameters are passed to the handler.
+-->
+这个钩子在创建容器之后立即执行。
+但是，不能保证钩子会在容器入口点之前执行。
+没有参数传递给处理程序。
+
+`PreStop`
+
+<!--
+This hook is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention and others. A call to the preStop hook fails if the container is already in terminated or completed state.
+It is blocking, meaning it is synchronous,
+so it must complete before the call to delete the container can be sent.
+No parameters are passed to the handler.
+-->
+
+在容器终止之前是否立即调用此钩子，取决于 API 的请求或者管理事件，类似活动探针故障、资源抢占、资源竞争等等。 如果容器已经完全处于终止或者完成状态，则对 preStop 钩子的调用将失败。
+它是阻塞的，同时也是同步的，因此它必须在删除容器的调用之前完成。
+没有参数传递给处理程序。
+
+<!--
+A more detailed description of the termination behavior can be found in
+[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+-->
+有关终止行为的更详细描述，请参见[终止 Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)。
+
+<!--
+### Hook handler implementations
+-->
+
+### 钩子处理程序的实现
+
+<!--
+Containers can access a hook by implementing and registering a handler for that hook.
+There are two types of hook handlers that can be implemented for Containers:
+-->
+容器可以通过实现和注册该钩子的处理程序来访问该钩子。
+针对容器，有两种类型的钩子处理程序可供实现：
+
+<!--
+* Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container.
+Resources consumed by the command are counted against the Container.
+* HTTP - Executes an HTTP request against a specific endpoint on the Container.
+-->
+
+* Exec - 执行一个特定的命令，例如 `pre-stop.sh`，在容器的 cgroups 和名称空间中。
+命令所消耗的资源根据容器进行计算。
+* HTTP - 对容器上的特定端点执行 HTTP 请求。
+
+<!--
+### Hook handler execution
+-->
+
+### 钩子处理程序执行
+
+<!--
+When a Container lifecycle management hook is called,
+the Kubernetes management system executes the handler in the Container registered for that hook. 
+-->
+当调用容器生命周期管理钩子时，Kubernetes 管理系统在为该钩子注册的容器中执行处理程序。
+
+<!--
+Hook handler calls are synchronous within the context of the Pod containing the Container.
+This means that for a `PostStart` hook,
+the Container ENTRYPOINT and hook fire asynchronously.
+However, if the hook takes too long to run or hangs,
+the Container cannot reach a `running` state.
+-->
+钩子处理程序调用在包含容器的 Pod 上下文中是同步的。
+这意味着对于 `PostStart` 钩子，容器入口点和钩子异步触发。
+但是，如果钩子运行或挂起的时间太长，则容器无法达到 `running` 状态。
+
+<!--
+The behavior is similar for a `PreStop` hook.
+If the hook hangs during execution,
+the Pod phase stays in a `Terminating` state and is killed after `terminationGracePeriodSeconds` of pod ends.
+If a `PostStart` or `PreStop` hook fails,
+it kills the Container.
+-->
+行为与 `PreStop` 钩子的行为类似。
+如果钩子在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。
+如果 `PostStart` 或 `PreStop` 钩子失败，它会杀死容器。
+
+<!--
+Users should make their hook handlers as lightweight as possible.
+There are cases, however, when long running commands make sense,
+such as when saving state prior to stopping a Container.
+-->
+用户应该使他们的钩子处理程序尽可能的轻量级。
+但也需要考虑长时间运行的命令也很有用的情况，比如在停止容器之前保存状态。
+
+<!--
+### Hook delivery guarantees
+-->
+
+### 钩子寄送保证
+
+<!--
+Hook delivery is intended to be *at least once*,
+which means that a hook may be called multiple times for any given event,
+such as for `PostStart` or `PreStop`.
+It is up to the hook implementation to handle this correctly.
+-->
+钩子的寄送应该是*至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，钩子可以被调用多次。
+如何正确处理，是钩子实现所要考虑的问题。
+
+<!--
+Generally, only single deliveries are made.
+If, for example, an HTTP hook receiver is down and is unable to take traffic,
+there is no attempt to resend.
+In some rare cases, however, double delivery may occur.
+For instance, if a kubelet restarts in the middle of sending a hook,
+the hook might be resent after the kubelet comes back up.
+-->
+通常情况下，只会进行单次寄送。
+例如，如果 HTTP 钩子接收器宕机，无法接收流量，则不会尝试重新发送。
+然而，偶尔也会发生重复寄送的可能。
+例如，如果 kubelet 在发送钩子的过程中重新启动，钩子可能会在 kubelet 恢复后重新发送。
+
+<!--
+### Debugging Hook handlers
+-->
+
+### 调试钩子处理程序
+
+<!--
+The logs for a Hook handler are not exposed in Pod events.
+If a handler fails for some reason, it broadcasts an event.
+For `PostStart`, this is the `FailedPostStartHook` event,
+and for `PreStop`, this is the `FailedPreStopHook` event.
+You can see these events by running `kubectl describe pod <pod_name>`.
+Here is some example output of events from running this command:
+-->
+钩子处理程序的日志不会在 Pod 事件中公开。
+如果处理程序由于某种原因失败，它将播放一个事件。
+对于 `PostStart`，这是 `FailedPostStartHook` 事件，对于 `PreStop`，这是 `FailedPreStopHook` 事件。
+您可以通过运行 `kubectl describe pod <pod_name>` 命令来查看这些事件。
+下面是运行这个命令的一些事件输出示例:
+
+```
+Events:
+  FirstSeen    LastSeen    Count    From                            SubobjectPath        Type        Reason        Message
+  ---------    --------    -----    ----                            -------------        --------    ------        -------
+  1m        1m        1    {default-scheduler }                                Normal        Scheduled    Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Pulling        pulling image "test:1.0"
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Created        Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Pulled        Successfully pulled image "test:1.0"
+  1m        1m        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Started        Started container with docker id 5c6a256a2567
+  38s        38s        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Killing        Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
+  37s        37s        1    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Normal        Killing        Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
+  38s        37s        2    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                Warning        FailedSync    Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
+  1m         22s         2     {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Warning        FailedPostStartHook
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+<!--
+* Learn more about the [Container environment](/docs/concepts/containers/container-environment-variables/).
+* Get hands-on experience
+  [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
+-->
+
+* 了解更多关于[容器环境](/docs/concepts/containers/container-environment-variables/)。
+* 获取实践经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
+
+{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: 扩展 Kubernetes
+weight: 40
+---
@@ -0,0 +1,4 @@
+---
+title: 扩展 Kubernetes API
+weight: 20
+---
@@ -0,0 +1,73 @@
+<!--
+---
+title: Extending the Kubernetes API with the aggregation layer
+reviewers:
+- lavalamp
+- cheftako
+- chenopis
+content_template: templates/concept
+weight: 10
+---
+-->
+
+---
+title: 通过聚合层扩展 Kubernetes API
+reviewers:
+- lavalamp
+- cheftako
+- chenopis
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+<!--
+The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. 
+-->
+
+聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+<!--
+## Overview
+
+The aggregation layer enables installing additional Kubernetes-style APIs in your cluster. These can either be pre-built, existing 3rd party solutions, such as [service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md), or user-created APIs like [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md), which can get you started.
+-->
+
+## 概述
+
+聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。
+
+<!--
+In 1.7 the aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, users must add an APIService object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. /apis/myextension.mycompany.io/v1/…) to the registered APIService. 
+-->
+
+1.7 版本中，聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来申领 Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）代理到已注册的 APIService。
+
+<!--
+Ordinarily, the APIService will be implemented by an *extension-apiserver* in a pod running in the cluster. This extension-apiserver will normally need to be paired with one or more controllers if active management of the added resources is needed. As a result, the apiserver-builder will actually provide a skeleton for both. As another example, when the service-catalog is installed, it provides both the extension-apiserver and controller for the services it provides.
+-->
+
+正常情况下，APIService 会实现为运行于集群中某 Pod 内的 extension-apiserver。如果需要对增加的资源进行动态管理，extension-apiserver 经常需要和一个或多个控制器一起使用。因此，apiserver-builder 同时提供用来管理新资源的 API 框架和控制器框架。另外一个例子，当安装了 service-catalog 时，它会为自己提供的服务提供 extension-apiserver 和控制器。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+<!--
+* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
+* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
+* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
+-->
+
+* 阅读[配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 文档，了解如何在自己的环境中启用聚合器（aggregator）。
+* 然后[安装扩展的 api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 来开始使用聚合层。
+* 也可以学习怎样 [使用客户资源定义扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。
+
+{{% /capture %}}
+
+
@@ -0,0 +1,4 @@
+---
+title: 计算、存储和网络扩展
+weight: 30
+---
@@ -0,0 +1,273 @@
+---
+title: 网络插件
+content_template: templates/concept
+weight: 10
+---
+<!--
+title: Network Plugins
+content_template: templates/concept
+weight: 10
+-->
+
+
+{{% capture overview %}}
+
+{{< feature-state state="alpha" >}}
+<!--
+{{< warning >}}Alpha features change rapidly. {{< /warning >}}
+-->
+{{< warning >}}Alpha 特性迅速变化。{{< /warning >}}
+
+<!--
+Network plugins in Kubernetes come in a few flavors:
+
+* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
+* Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
+-->
+Kubernetes中的网络插件有几种类型：
+
+* CNI 插件： 遵守 appc/CNI 规约，为互操作性设计。
+* Kubenet 插件：使用 `bridge` 和 `host-local` CNI 插件实现了基本的 `cbr0`。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+<!--
+## Installation
+
+The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it found, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
+
+* `cni-bin-dir`: Kubelet probes this directory for plugins on startup
+* `network-plugin`: The network plugin to use from `cni-bin-dir`.  It must match the name reported by a plugin probed from the plugin directory.  For CNI plugins, this is simply "cni".
+-->
+## 安装
+
+kubelet 有一个单独的默认网络插件，以及一个对整个集群通用的默认网络。
+它在启动时探测插件，记住找到的内容，并在 pod 生命周期的适当时间执行所选插件（这仅适用于 Docker，因为 rkt 管理自己的 CNI 插件）。
+在使用插件时，需要记住两个 Kubelet 命令行参数：
+
+* `cni-bin-dir`： Kubelet 在启动时探测这个目录中的插件
+* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。它必须与从插件目录探测到的插件报告的名称匹配。对于 CNI 插件，其值为 "cni"。
+
+<!--
+## Network Plugin Requirements
+
+Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy.  The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.  For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.  If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy.
+
+By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy.
+-->
+## 网络插件要求
+
+除了提供[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)来配置和清理 pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。
+iptables 代理显然依赖于 iptables，插件可能需要确保 iptables 能够监控容器的网络通信。
+例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables` 系统参数设置为`1`，以确保 iptables 代理正常工作。
+如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制），它应该确保为代理对容器通信执行正确的路由。
+
+默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件，该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置（如带网桥的 Docker ）与 iptables 代理正常工作。
+
+<!--
+### CNI
+
+The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option.  Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network.  The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`).
+
+If there are multiple CNI configuration files in the directory, the first one in lexicographic order of file name is used.
+
+In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0
+-->
+### CNI
+
+通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项来选择 CNI 插件。
+Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用该文件中的 CNI 配置来设置每个 pod 的网络。
+CNI 配置文件必须与 [CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)匹配，并且配置引用的任何所需的 CNI 插件都必须存在于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）。
+
+如果这个目录中有多个 CNI 配置文件，则使用按文件名的字典顺序排列的第一个配置文件。
+
+除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 插件，最低版本是0.2.0。
+
+<!--
+#### Support hostPort
+
+The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
+plugin offered by the CNI plugin team or use your own plugin with portMapping functionality.
+
+If you want to enable `hostPort` support, you must specify `portMappings capability` in your `cni-conf-dir`.
+For example:
+-->
+#### 支持 hostPort
+
+CNI 网络插件支持 `hostPort`。 您可以使用官方 [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
+插件，它由 CNI 插件团队提供，或者使用您自己的带有 portMapping 功能的插件。
+
+如果你想要启动 `hostPort` 支持，则必须在 `cni-conf-dir` 指定 `portMappings capability`。
+例如：
+
+```json
+{
+  "name": "k8s-pod-network",
+  "cniVersion": "0.3.0",
+  "plugins": [
+    {
+      "type": "calico",
+      "log_level": "info",
+      "datastore_type": "kubernetes",
+      "nodename": "127.0.0.1",
+      "ipam": {
+        "type": "host-local",
+        "subnet": "usePodCidr"
+      },
+      "policy": {
+        "type": "k8s"
+      },
+      "kubernetes": {
+        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
+      }
+    },
+    {
+      "type": "portmap",
+      "capabilities": {"portMappings": true}
+    }
+  ]
+}
+```
+
+<!--
+#### Support traffic shaping
+
+The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
+plugin offered by the CNI plugin team or use your own plugin with bandwidth control functionality.
+
+If you want to enable traffic shaping support, you must add a `bandwidth` plugin to your CNI configuration file
+(default `/etc/cni/net.d`).
+-->
+#### 支持流量整形
+
+CNI 网络插件还支持 pod 入口和出口流量整形。
+您可以使用 CNI 插件团队提供的 [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 插件，
+也可以使用您自己的具有带宽控制功能的插件。
+
+如果您想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件
+（默认是 `/etc/cni/net.d`）。
+
+```json
+{
+  "name": "k8s-pod-network",
+  "cniVersion": "0.3.0",
+  "plugins": [
+    {
+      "type": "calico",
+      "log_level": "info",
+      "datastore_type": "kubernetes",
+      "nodename": "127.0.0.1",
+      "ipam": {
+        "type": "host-local",
+        "subnet": "usePodCidr"
+      },
+      "policy": {
+        "type": "k8s"
+      },
+      "kubernetes": {
+        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
+      }
+    },
+    {
+      "type": "bandwidth",
+      "capabilities": {"bandwidth": true}
+    }
+  ]
+}
+```
+<!--
+Now you can add the `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth` annotations to your pod.
+For example:
+-->
+现在，您可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth` 注解添加到 pod 中。
+例如：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  annotations:
+    kubernetes.io/ingress-bandwidth: 1M
+    kubernetes.io/egress-bandwidth: 1M
+...
+```
+
+<!--
+### kubenet
+
+Kubenet is a very basic, simple network plugin, on Linux only.  It does not, of itself, implement more advanced features like cross-node networking or network policy.  It is typically used together with a cloud provider that sets up routing rules for communication between nodes, or in single-node environments.
+
+Kubenet creates a Linux bridge named `cbr0` and creates a veth pair for each pod with the host end of each pair connected to `cbr0`.  The pod end of the pair is assigned an IP address allocated from a range assigned to the node either through configuration or by the controller-manager.  `cbr0` is assigned an MTU matching the smallest MTU of an enabled normal interface on the host.
+
+The plugin requires a few things:
+
+* The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `cni-bin-dir` to supply additional search path. The first found match will take effect.
+* Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin
+* Kubelet should also be run with the `--non-masquerade-cidr=<clusterCidr>` argument to ensure traffic to IPs outside this range will use IP masquerade.
+* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=<cidr>` controller-manager command-line options.
+-->
+### kubenet
+
+Kubenet 是一个非常基本的、简单的网络插件，仅适用于 Linux。
+它本身并不实现更高级的功能，如跨节点网络或网络策略。
+它通常与云驱动一起使用，云驱动为节点间或单节点环境中的通信设置路由规则。
+
+Kubenet 创建名为 `cbr0` 的网桥，并为每个 pod 创建了一个 veth 对，每个 pod 的主机端都连接到 `cbr0`。
+这个 veth 对的 pod 端会被分配一个 IP 地址，该 IP 地址隶属于节点所被分配的 IP 地址范围内。节点的 IP 地址范围则通过配置或控制器管理器来设置。
+`cbr0` 被分配一个 MTU，该 MTU 匹配主机上已启用的正常接口的最小 MTU。
+
+使用此插件还需要一些其他条件：
+
+* 需要标准的 CNI `bridge`、`lo` 以及 `host-local` 插件，最低版本是0.2.0。Kubenet 首先在 `/opt/cni/bin` 中搜索它们。 指定 `cni-bin-dir` 以提供其它的搜索路径。首次找到的匹配将生效。
+* Kubelet 必须和 `--network-plugin=kubenet` 参数一起运行，才能启用该插件。
+* Kubelet 还应该和 `--non-masquerade-cidr=<clusterCidr>` 参数一起运行，以确保超出此范围的 IP 流量将使用 IP 伪装。
+* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=<cidr>` 来设置。
+
+<!--
+### Customizing the MTU (with kubenet)
+
+The MTU should always be configured correctly to get the best networking performance.  Network plugins will usually try
+to infer a sensible MTU, but sometimes the logic will not result in an optimal MTU.  For example, if the
+Docker bridge or another interface has a small MTU, kubenet will currently select that MTU.  Or if you are
+using IPSEC encapsulation, the MTU must be reduced, and this calculation is out-of-scope for
+most network plugins.
+
+Where needed, you can specify the MTU explicitly with the `network-plugin-mtu` kubelet option.  For example,
+on AWS the `eth0` MTU is typically 9001, so you might specify `--network-plugin-mtu=9001`.  If you're using IPSEC you
+might reduce it to allow for encapsulation overhead e.g. `--network-plugin-mtu=8873`.
+
+This option is provided to the network-plugin; currently **only kubenet supports `network-plugin-mtu`**.
+-->
+### 自定义 MTU（使用 kubenet）
+
+要获得最佳的网络性能，必须确保 MTU 的取值配置正确。
+网络插件通常会尝试推断出一个合理的 MTU，但有时候这个逻辑不会产生一个最优的 MTU。
+例如，如果 Docker 网桥或其他接口有一个小的 MTU, kubenet 当前将选择该 MTU。
+或者如果您正在使用 IPSEC 封装，则必须减少 MTU，并且这种计算超出了大多数网络插件的能力范围。
+
+如果需要，您可以使用 `network-plugin-mtu` kubelet 选项显式的指定 MTU。
+例如：在 AWS 上 `eth0` MTU 通常是 9001，因此您可以指定 `--network-plugin-mtu=9001`。
+如果您正在使用 IPSEC ，您可以减少它以允许封装开销，例如 `--network-plugin-mtu=8873`。
+
+此选项会传递给网络插件； 当前 **仅 kubenet 支持 `network-plugin-mtu`**。
+
+<!--
+## Usage Summary
+
+* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`).
+* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
+* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
+-->
+## 使用总结
+
+* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于 `--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。
+* `--network-plugin=kubenet` 用来表明我们要使用 `kubenet` 网络插件，CNI `bridge` 和 `host-local` 插件位于 `/opt/cni/bin` 或 `cni-bin-dir` 中。
+* `--network-plugin-mtu=9001` 指定了我们使用的 MTU，当前仅被 `kubenet` 网络插件使用。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+{{% /capture %}}
@@ -1,4 +1,4 @@
 ---
-title: "概述"
+title: 概述
 weight: 20
 ---
@@ -1,103 +1,265 @@
 ---
-title: Kubernetes API
+title: The Kubernetes API
+content_template: templates/concept
 weight: 30
+card:
+  name: concepts
+  weight: 30
 ---

-# Kubernetes API 概述
+{{% capture overview %}}

+<!--
+Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+
+API endpoints, resource types and samples are described in [API Reference](/docs/reference).
+
+Remote access to the API is discussed in the [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/).
+
+The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [kubectl](/docs/reference/kubectl/overview/) command-line tool can be used to create, update, delete, and get API objects.
+
+Kubernetes also stores its serialized state (currently in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) in terms of the API resources.
+
+Kubernetes itself is decomposed into multiple components, which interact through its API.
+-->
 [API协议文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)描述了主系统和API概念。

-[API参考文档](https://kubernetes.io/docs/reference)描述了API整体规范。
+[API参考文档](/docs/reference)描述了API整体规范。

-[访问文档](https://kubernetes.io/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。
+[访问文档](/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。

-Kubernetes API是系统描述性配置的基础。 [Kubectl](https://kubernetes.io/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。
+Kubernetes API是系统描述性配置的基础。 [Kubectl](/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。

 Kubernetes 通过API资源存储自己序列化状态(现在存储在[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/))。

 Kubernetes 被分成多个组件，各部分通过API相互交互。

+{{% /capture %}}
+
+
+{{% capture body %}}
+
+<!--
+## API changes
+
+In our experience, any system that is successful needs to grow and change as new use cases emerge or existing ones change. Therefore, we expect the Kubernetes API to continuously change and grow. However, we intend to not break compatibility with existing clients, for an extended period of time. In general, new API resources and new resource fields can be expected to be added frequently. Elimination of resources or fields will require following the [API deprecation policy](/docs/reference/using-api/deprecation-policy/).
+
+What constitutes a compatible change and how to change the API are detailed by the [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md).
+-->
 ## API 变更

 根据经验，任何成功的系统都需要随着新的用例出现或现有用例发生变化的情况下，进行相应的进化与调整。因此，我们希望Kubernetes API也可以保持持续的进化和调整。同时，在较长一段时间内，我们也希望与现有客户端版本保持良好的向下兼容性。一般情况下，增加新的API资源和资源字段不会导致向下兼容性问题发生；但如果是需要删除一个已有的资源或者字段，那么必须通过[API废弃流程](/docs/reference/deprecation-policy/)来进行。

-参考[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md)，了解兼容性变更的要素以及如何变更API的流程。
+参考[API变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)，了解兼容性变更的要素以及如何变更API的流程。

-## API Swagger 定义
+<!--
+## OpenAPI and Swagger definitions

-Kubernetes使用 [Swagger v1.2](http://swagger.io/) 与 [OpenAPI](https://www.openapis.org/) 记录API所有细节。Kubernetes apiserver (即 “master”)提供了一个API接口用于获取 Swagger 1.2 Kubernetes API 规范 ，默认在路径 **`/swaggerapi`** 下。你也可以为API服务器可以设置 **`-enable-swagger-ui=true`** 来启用API界面，之后使用浏览器访问 **`/swagger-ui`**，浏览API文档。
+Complete API details are documented using [OpenAPI](https://www.openapis.org/).

+Starting with Kubernetes 1.10, the Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
+The requested format is specified by setting HTTP headers:
+-->

-Kubernetes从1.4版本开始，也支持通过 [**`/swagger.json`**](https://git.k8s.io/kubernetes/api/openapi-spec/swagger.json) 来访问 OpenAPI 形式给出的API文档。在我们将 Swagger v1.2 切换到 OpenAPI (aka Swagger v2.0) 期间，一部分工具(如 kubectl 与 swagger-ui )会继续使用 1.2 版本规范。Kubernetes 1.5 版本中的 OpenAPI 规范是 Beta 版本。
+## OpenAPI 和 API Swagger 定义
+
+完整的 API 细节被记录在 [OpenAPI](https://www.openapis.org/).
+
+随着 Kubernetes 1.10 版本的正式启用，Kubernetes API 服务通过 `/openapi/v2` 接口提供 OpenAPI 规范。
+通过设置 HTTP 标头的规定了请求的结构。
+
+Header | Possible Values
+------ | ---------------
+Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (the default content-type is `application/json` for `*/*` or not passing this header)
+Accept-Encoding | `gzip` (not passing this header is acceptable)
+
+<!--
+Prior to 1.14, format-separated endpoints (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)
+serve the OpenAPI spec in different formats. These endpoints are deprecated, and are removed in Kubernetes 1.14.
+
+**Examples of getting OpenAPI spec**:
+
+Before 1.10 | Starting with Kubernetes 1.10
+-->
+
+在1.14版本之前，区分结构的接口通过(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)
+提供不同格式的 OpenAPI 规范。但是这些接口已经被废弃，并且已经在 Kubernetes 1.14 中被删除。
+
+**获取 OpenAPI 规范的例子**:
+
+1.10 之前 | 从 1.10 开始
+----------- | -----------------------------
+GET /swagger.json | GET /openapi/v2 **Accept**: application/json
+GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
+GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
+
+<!--
+Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
+
+Prior to 1.14, the Kubernetes apiserver also exposes an API that can be used to retrieve
+the [Swagger v1.2](http://swagger.io/) Kubernetes API spec at `/swaggerapi`.
+This endpoint is deprecated, and will be removed in Kubernetes 1.14.
+-->

 Kubernetes实现了另一种基于Protobuf的序列化格式，该格式主要用于集群内通信，并在[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)中进行了说明，每个模式的IDL文件位于定义API对象的Go软件包中。
+在 1.14 版本之前， Kubernetes apiserver 也提供 API 服务用于返回
+[Swagger v1.2](http://swagger.io/) Kubernetes API 规范通过 `/swaggerapi` 接口.
+但是这个接口已经被废弃，并且在 Kubernetes 1.14 中已经被移除。
+
+<!--
+## API versioning
+
+To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
+multiple API versions, each at a different API path, such as `/api/v1` or
+`/apis/extensions/v1beta1`.
+-->

 ## API 版本

-为了使删除字段或者重构资源表示更加容易，Kubernetes 支持多个API版本。每一个版本都在不同API路径下，例如 **`/api/v1`** 或者 **`/apis/extensions/v1beta1`**。
+为了使删除字段或者重构资源表示更加容易，Kubernetes 支持
+多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者 
+`/apis/extensions/v1beta1`。
+
+<!--
+We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
+
+Note that API versioning and Software versioning are only indirectly related.  The [API and release
+versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and
+software versioning.
+-->

 我们选择在API级别进行版本化，而不是在资源或字段级别进行版本化，以确保API提供清晰，一致的系统资源和行为视图，并控制对已废止的API和/或实验性API的访问。 JSON和Protobuf序列化模式遵循架构更改的相同准则 - 下面的所有描述都同时适用于这两种格式。

-请注意，API版本控制和软件版本控制只有间接相关性。 [API和发行版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)描述了API版本与软件版本之间的关系。
+请注意，API版本控制和软件版本控制只有间接相关性。
+ [API和发行版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) 描述了API版本与软件版本之间的关系。

-不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下：
+<!--
+Different API versions imply different levels of stability and support.  The criteria for each level are described
+in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).  They are summarized here:
+-->

-* Alpha 测试版本：
+不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下：

-  * 版本名称包含了 **`alpha`** (例如：**`v1alpha1`**)。
+<!--
+- Alpha level:
+  - The version names contain `alpha` (e.g. `v1alpha1`).
+  - May be buggy.  Enabling the feature may expose bugs.  Disabled by default.
+  - Support for feature may be dropped at any time without notice.
+  - The API may change in incompatible ways in a later software release without notice.
+  - Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
+- Beta level:
+  - The version names contain `beta` (e.g. `v2beta3`).
+  - Code is well tested.  Enabling the feature is considered safe.  Enabled by default.
+  - Support for the overall feature will not be dropped, though details may change.
+  - The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release.  When this happens,
+    we will provide instructions for migrating to the next version.  This may require deleting, editing, and re-creating
+    API objects.  The editing process may require some thought.   This may require downtime for applications that rely on the feature.
+  - Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases.  If you have
+    multiple clusters which can be upgraded independently, you may be able to relax this restriction.
+  - **Please do try our beta features and give feedback on them!  Once they exit beta, it may not be practical for us to make more changes.**
+- Stable level:
+  - The version name is `vX` where `X` is an integer.
+  - Stable versions of features will appear in released software for many subsequent versions.
+-->
+- Alpha 测试版本：
+  - 版本名称包含了 **`alpha`** (例如：**`v1alpha1`**)。
+  - 可能是有缺陷的。启用该功能可能会带来隐含的问题，默认情况是关闭的。
+  - 支持的功能可能在没有通知的情况下随时删除。
+  - API的更改可能会带来兼容性问题，但是在后续的软件发布中不会有任何通知。
+  - 由于bugs风险的增加和缺乏长期的支持，推荐在短暂的集群测试中使用。
+- Beta 测试版本：
+  - 版本名称包含了 **`beta`** (例如: **`v2beta3`**)。
+  - 代码已经测试过。启用该功能被认为是安全的，功能默认已启用。
+  - 所有已支持的功能不会被删除，细节可能会发生变化。
+  - 对象的模式和/或语义可能会在后续的beta测试版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供迁移到下一个版本的说明。 这可能需要删除、编辑和重新创建API对象。执行编辑操作时需要谨慎行事，这可能需要停用依赖该功能的应用程序。
+  - 建议仅用于非业务关键型用途，因为后续版本中可能存在不兼容的更改。 如果您有多个可以独立升级的集群，则可以放宽此限制。
+  - **请尝试我们的 beta 版本功能并且给出反馈！一旦他们退出 beta 测试版，我们可能不会做出更多的改变。**
+- 稳定版本：
+  - 版本名称是 **`vX`**，其中 **`X`** 是整数。
+  - 功能的稳定版本将出现在许多后续版本的发行软件中。

-  * 可能是有缺陷的。启用该功能可能会带来隐含的问题，默认情况是关闭的。
+<!--
+## API groups

-  * 支持的功能可能在没有通知的情况下随时删除。
-
-  * API的更改可能会带来兼容性问题，但是在后续的软件发布中不会有任何通知。
-
-  * 由于bugs风险的增加和缺乏长期的支持，推荐在短暂的集群测试中使用。
-
-* Beta 测试版本：
-
-  * 版本名称包含了 **`beta`** (例如: **`v2beta3`**)。
-
-  * 代码已经测试过。启用该功能被认为是安全的，功能默认已启用。
-
-  * 所有已支持的功能不会被删除，细节可能会发生变化。
-
-  * 对象的模式和/或语义可能会在后续的beta测试版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供迁移到下一个版本的说明。 这可能需要删除、编辑和重新创建API对象。执行编辑操作时需要谨慎行事，这可能需要停用依赖该功能的应用程序。
-
-  * 建议仅用于非业务关键型用途，因为后续版本中可能存在不兼容的更改。 如果您有多个可以独立升级的集群，则可以放宽此限制。
-
-  * **请尝试我们的 beta 版本功能并且给出反馈！一旦他们退出 beta 测试版，我们可能不会做出更多的改变。**
-
-* 稳定版本：
-
-  * 版本名称是 **`vX`**，其中 **`X`** 是整数。
-
-  * 功能的稳定版本将出现在许多后续版本的发行软件中。
+To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
+The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
+-->

 ## API 组

-为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 API组在REST路径和序列化对象的 **`apiVersion`** 字段中指定。
+为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 
+API组在REST路径和序列化对象的 **`apiVersion`** 字段中指定。
+
+<!--
+Currently there are several API groups in use:
+
+1. The *core* group, often referred to as the *legacy group*, is at the REST path `/api/v1` and uses `apiVersion: v1`.
+
+1. The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
+   (e.g. `apiVersion: batch/v1`).  Full list of supported API groups can be seen in [Kubernetes API reference](/docs/reference/).
+-->

 目前有几个API组正在使用中：

-1. 核心组（通常被称为遗留组）位于REST路径 **`/api/v1`** 并使用 **`apiVersion：v1`**。
+1. 核心组（通常被称为遗留组）位于REST路径 `/api/v1` 并使用 `apiVersion：v1`。

-1. 指定的组位于REST路径 **`/apis/$GROUP_NAME/$VERSION`**，并使用 **`apiVersion：$GROUP_NAME/$VERSION`**（例如 **`apiVersion：batch/v1`**）。 在[Kubernetes API参考](https://kubernetes.io/docs/reference/)中可以看到支持的API组的完整列表。
+1. 指定的组位于REST路径 `/apis/$GROUP_NAME/$VERSION`，并使用 `apiVersion：$GROUP_NAME/$VERSION`
+  （例如 `apiVersion：batch/v1`）。 在[Kubernetes API参考](/docs/reference/)中可以看到支持的API组的完整列表。

-社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)：
+<!--
+There are two supported paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/):

-1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)适用于具有非常基本的CRUD需求的用户。
+1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+   is for users with very basic CRUD needs.
+1. Users needing the full set of Kubernetes API semantics can implement their own apiserver
+   and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
+   to make it seamless for clients.
+-->

-1. 即将推出：需要全套Kubernetes API语义的用户可以实现自己的apiserver，并使用[聚合器](https://git.k8s.io/community/contributors/design-proposals/api-machinery/aggregated-api-servers.md)为客户提供无缝的服务。
+社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](/docs/concepts/api-extension/custom-resources/)：
+
+1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+   适用于具有非常基本的CRUD需求的用户。
+
+1. 需要全套Kubernetes API语义的用户可以实现自己的apiserver，
+   并使用[聚合器](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
+   为客户提供无缝的服务。
+
+<!--
+## Enabling API groups
+
+Certain resources and API groups are enabled by default.  They can be enabled or disabled by setting `--runtime-config`
+on apiserver. `--runtime-config` accepts comma separated values. For ex: to disable batch/v1, set
+`--runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`.
+The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
+
+IMPORTANT: Enabling or disabling groups or resources requires restarting apiserver and controller-manager
+to pick up the `--runtime-config` changes.
+-->

 ## 启用 API 组

-某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 **`--runtime-config`** 来启用或禁用它们。 **`--runtime-config`** 接受逗号分隔的值。 例如：要禁用batch/v1，请设置**`--runtime-config=batch/v1=false`**，以启用batch/v2alpha1，请设置**`--runtime-config=batch/v2alpha1`**。 该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。
+某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 `--runtime-config` 来启用或禁用它们。 
+`--runtime-config` 接受逗号分隔的值。 
+例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。 
+该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。

-重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 **`--runtime-config`** 更改生效。
+重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。
+
+<!--
+## Enabling resources in the groups
+
+DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs and ReplicaSets are enabled by default.
+Other extensions resources can be enabled by setting `--runtime-config` on
+apiserver. `--runtime-config` accepts comma separated values. For example: to disable deployments and ingress, set
+`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`
+-->

 ## 启用组中资源

-DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs和ReplicaSets是默认启用的。 其他扩展资源可以通过在apiserver上设置 **`--runtime-config`** 来启用。**`--runtime-config`** 接受逗号分隔的值。
+DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。 
+其他扩展资源可以通过在apiserver上设置 `--runtime-config` 来启用。
+`--runtime-config` 接受逗号分隔的值。 例如：要禁用 Deployment 和 Ingress，
+请设置 `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`

-例如：要禁用 Deployment 和 Ingress，请设置 **`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`**
+{{% /capture %}}
@@ -0,0 +1,164 @@
+---
+title: 注解
+content_template: templates/concept
+weight: 50
+---
+
+<!--
+---
+title: Annotations
+content_template: templates/concept
+weight: 50
+---
+-->
+
+{{% capture overview %}}
+
+你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。
+<!--
+You can use Kubernetes annotations to attach arbitrary non-identifying metadata
+to objects. Clients such as tools and libraries can retrieve this metadata.
+-->
+{{% /capture %}}
+
+{{% capture body %}}
+## 为对象附加元数据
+<!--
+## Attaching metadata to objects
+-->
+
+您可以使用标签或注解将元数据附加到 Kubernetes 对象。
+标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。
+注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。
+
+<!--
+You can use either labels or annotations to attach metadata to Kubernetes
+objects. Labels can be used to select objects and to find
+collections of objects that satisfy certain conditions. In contrast, annotations
+are not used to identify and select objects. The metadata
+in an annotation can be small or large, structured or unstructured, and can
+include characters not permitted by labels.
+-->
+
+
+注解和标签一样，是键/值对:
+<!--
+Annotations, like labels, are key/value maps:
+-->
+
+```json
+"metadata": {
+  "annotations": {
+    "key1" : "value1",
+    "key2" : "value2"
+  }
+}
+```
+
+以下是一些例子，用来说明哪些信息可以使用注解来记录:
+<!--
+Here are some examples of information that could be recorded in annotations:
+-->
+
+* 由声明性配置所管理的字段。
+  将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
+
+<!--
+* Fields managed by a declarative configuration layer. Attaching these fields
+  as annotations distinguishes them from default values set by clients or
+  servers, and from auto-generated fields and fields set by
+  auto-sizing or auto-scaling systems.
+-->
+
+* 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。
+
+<!--
+* Build, release, or image information like timestamps, release IDs, git branch,
+  PR numbers, image hashes, and registry address.
+-->
+
+* 指向日志记录、监控、分析或审计仓库的指针。
+
+<!--
+* Pointers to logging, monitoring, analytics, or audit repositories.
+-->
+
+* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
+
+<!--
+* Client library or tool information that can be used for debugging purposes:
+  for example, name, version, and build information.
+-->
+
+* 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。
+
+<!--
+* User or tool/system provenance information, such as URLs of related objects
+  from other ecosystem components.
+-->
+
+* 推出的轻量级工具的元数据信息：例如，配置或检查点。
+
+<!--
+* Lightweight rollout tool metadata: for example, config or checkpoints.
+-->
+
+* 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。
+
+<!--
+* Phone or pager numbers of persons responsible, or directory entries that
+  specify where that information can be found, such as a team web site.
+-->
+
+
+从用户到最终运行的指令，以修改行为或使用非标准功能。
+<!--
+* Directives from the end-user to the implementations to modify behavior or
+  engage non-standard features.
+-->
+
+您可以将这类信息存储在外部数据库或目录中而不使用注解，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。
+<!--
+Instead of using annotations, you could store this type of information in an
+external database or directory, but that would make it much harder to produce
+shared client libraries and tools for deployment, management, introspection,
+and the like.
+-->
+
+<!--
+## Syntax and character set
+
+_Annotations_ are key/value pairs. Valid annotation keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
+
+If the prefix is omitted, the annotation Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add annotations to end-user objects must specify a prefix.
+-->
+
+## 语法和字符集
+_注解_ 存储的形式是键/值对。有效的注解键分为两部分：可选的前缀和名称，以斜杠（`/`）分隔。 名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 前缀是可选的。 如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，总计不超过253个字符，后跟斜杠（`/`）。
+如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` 或其他第三方组件），必须为终端用户添加注释前缀。
+
+```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/)。
+<!--
+Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
+-->
+{{% /capture %}}
@@ -0,0 +1,259 @@
+---
+title: 推荐使用的标签
+content_template: templates/concept
+---
+<!--
+---
+title: Recommended Labels
+content_template: templates/concept
+---
+-->
+
+{{% capture overview %}}
+<!--
+You can visualize and manage Kubernetes objects with more tools than kubectl and
+the dashboard. A common set of labels allows tools to work interoperably, describing
+objects in a common manner that all tools can understand.
+-->
+除了 kubectl 和 dashboard 之外，您可以其他工具来可视化和管理 Kubernetes 对象。
+一组通用的标签可以让多个工具之间互操作，用所有工具都能理解的通用方式描述对象。
+
+<!--
+In addition to supporting tooling, the recommended labels describe applications
+in a way that can be queried.
+-->
+除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。
+
+{{% /capture %}}
+
+{{% capture body %}}
+<!--
+The metadata is organized around the concept of an _application_. Kubernetes is not
+a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application.
+Instead, applications are informal and described with metadata. The definition of
+what an application contains is loose.
+-->
+元数据围绕 _应用（application）_ 的概念进行组织。Kubernetes 不是
+平台即服务（PaaS），没有或强制执行正式的应用程序概念。
+相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。
+
+{{< note >}}
+<!--
+These are recommended labels. They make it easier to manage applications
+but aren't required for any core tooling.
+-->
+这些是推荐的标签。它们使管理应用程序变得更容易但不是任何核心工具所必需的。
+{{< /note >}}
+
+<!--
+Shared labels and annotations share a common prefix: `app.kubernetes.io`. Labels
+without a prefix are private to users. The shared prefix ensures that shared labels
+do not interfere with custom user labels.
+-->
+共享标签和注解都使用同一个前缀：`app.kubernetes.io`。没有前缀的标签是用户私有的。共享前缀可以确保共享标签不会干扰用户自定义的标签。
+
+<!--
+## Labels
+
+In order to take full advantage of using these labels, they should be applied
+on every resource object.
+-->
+## 标签
+为了充分利用这些标签，应该在每个资源对象上都使用它们。
+
+<!--
+| Key                                 | Description           | Example  | Type |
+| ----------------------------------- | --------------------- | -------- | ---- |
+| `app.kubernetes.io/name`            | The name of the application | `mysql` | string |
+| `app.kubernetes.io/instance`        | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
+| `app.kubernetes.io/version`         | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
+| `app.kubernetes.io/component`       | The component within the architecture | `database` | string |
+| `app.kubernetes.io/part-of`         | The name of a higher level application this one is part of | `wordpress` | string |
+| `app.kubernetes.io/managed-by`  | The tool being used to manage the operation of an application | `helm` | string |
+-->
+| 键                                 | 描述           | 示例  | 类型 |
+| ----------------------------------- | --------------------- | -------- | ---- |
+| `app.kubernetes.io/name`            | 应用程序的名称 | `mysql` | 字符串 |
+| `app.kubernetes.io/instance`        | 用于唯一确定应用实例的名称 | `wordpress-abcxzy` | 字符串 |
+| `app.kubernetes.io/version`         | 应用程序的当前版本（例如，语义版本，修订版哈希等） | `5.7.21` | 字符串 |
+| `app.kubernetes.io/component`       | 架构中的组件 | `database` | 字符串 |
+| `app.kubernetes.io/part-of`         | 此级别的更高级别应用程序的名称 | `wordpress` | 字符串 |
+| `app.kubernetes.io/managed-by`  | 用于管理应用程序的工具 | `helm` | 字符串 |
+<!--
+To illustrate these labels in action, consider the following StatefulSet object:
+-->
+为说明这些标签的实际使用情况，请看下面的 StatefulSet 对象：
+
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "5.7.21"
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/managed-by: helm
+```
+
+<!--
+## Applications And Instances Of Applications
+
+An application can be installed one or more times into a Kubernetes cluster and,
+in some cases, the same namespace. For example, wordpress can be installed more
+than once where different websites are different installations of wordpress.
+
+The name of an application and the instance name are recorded separately. For
+example, WordPress has a `app.kubernetes.io/name` of `wordpress` while it has
+an instance name, represented as `app.kubernetes.io/instance` with a value of
+`wordpress-abcxzy`. This enables the application and instance of the application
+to be identifiable. Every instance of an application must have a unique name.
+-->
+## 应用和应用实例
+
+应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 wordpress。
+
+应用的名称和实例的名称是分别记录的。例如，某 WordPress 实例的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称表现为 `app.kubernetes.io/instance` 的属性值 `wordpress-abcxzy`。这使应用程序和应用程序的实例成为可能是可识别的。应用程序的每个实例都必须具有唯一的名称。
+
+<!--
+## Examples
+-->
+## 示例
+
+<!--
+To illustrate different ways to use these labels the following examples have varying complexity.
+-->
+为了说明使用这些标签的不同方式，以下示例具有不同的复杂性。
+
+<!--
+### A Simple Stateless Service
+-->
+### 一个简单的无状态服务
+
+<!--
+Consider the case for a simple stateless service deployed using `Deployment` and `Service` objects. The following two snippets represent how the labels could be used in their simplest form.
+-->
+考虑使用 `Deployment` 和 `Service` 对象部署的简单无状态服务的情况。以下两个代码段表示如何以最简单的形式使用标签。
+
+<!--
+The `Deployment` is used to oversee the pods running the application itself.
+-->
+下面的 `Deployment` 用于监督运行应用本身的 pods。
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/name: myservice
+    app.kubernetes.io/instance: myservice-abcxzy
+...
+```
+
+<!--
+The `Service` is used to expose the application.
+-->
+下面的 `Service` 用于暴露应用。
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: myservice
+    app.kubernetes.io/instance: myservice-abcxzy
+...
+```
+
+<!--
+### Web Application With A Database
+-->
+### 带有一个数据库的 Web 应用程序
+
+<!--
+Consider a slightly more complicated application: a web application (WordPress)
+using a database (MySQL), installed using Helm. The following snippets illustrate
+the start of objects used to deploy this application.
+
+The start to the following `Deployment` is used for WordPress:
+-->
+考虑一个稍微复杂的应用：一个使用 Helm 安装的 Web 应用（WordPress），其中
+使用了数据库（MySQL）。以下代码片段说明用于部署此应用程序的对象的开始。
+
+以下 `Deployment` 的开头用于 WordPress：
+
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/name: wordpress
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "4.9.4"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: server
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+<!--
+The `Service` is used to expose WordPress:
+-->
+这个 `Service` 用于暴露 WordPress：
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: wordpress
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "4.9.4"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: server
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+<!--
+MySQL is exposed as a `StatefulSet` with metadata for both it and the larger application it belongs to:
+-->
+MySQL 作为一个 `StatefulSet` 暴露，包含它和它所属的较大应用程序的元数据：
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/version: "5.7.21"
+...
+```
+
+<!--
+The `Service` is used to expose MySQL as part of WordPress:
+-->
+`Service` 用于将 MySQL 作为 WordPress 的一部分暴露：
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/version: "5.7.21"
+...
+```
+
+<!--
+With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included.
+-->
+使用 MySQL `StatefulSet` 和 `Service`，您会注意到有关 MySQL 和 Wordpress 的信息，包括更广泛的应用程序。
+
+{{% /capture %}}
@@ -0,0 +1,106 @@
+---
+title: 字段选择器
+weight: 60
+---
+
+<!--
+---
+title: Field Selectors
+weight: 60
+---
+-->
+
+字段选择器允许您根据一个或多个资源字段的值[筛选 Kubernetes 资源](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
+下面是一些使用字段选择器查询的例子：
+<!--
+_Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries:
+-->
+
+* `metadata.name=my-service`
+* `metadata.namespace!=default`
+* `status.phase=Pending`
+
+下面这个 `kubectl` 命令将筛选出[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)字段值为 `Running` 的所有 Pod：
+<!--
+This `kubectl` command selects all Pods for which the value of the [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) field is `Running`:
+-->
+
+```shell
+$ kubectl get pods --field-selector status.phase=Running
+```
+
+{{< note >}}
+
+字段选择器本质上是资源*过滤器*。默认情况下，字段选择器/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。
+这使得以下的两个 `kubectl` 查询是等价的：
+<!--
+Field selectors are essentially resource *filters*. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the following `kubectl` queries equivalent:
+-->
+
+```shell
+$ kubectl get pods
+$ kubectl get pods --field-selector ""
+```
+{{< /note >}}
+
+## 支持的字段
+<!--
+## Supported fields
+-->
+
+不同的 Kubernetes 资源类型支持不同的字段选择器。
+所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。
+使用不被支持的字段选择器会产生错误，例如：
+<!--
+Supported field selectors vary by Kubernetes resource type. All resource types support the `metadata.name` and `metadata.namespace` fields. Using unsupported field selectors produces an error. For example:
+-->
+
+```shell
+$ kubectl get ingress --field-selector foo.bar=baz
+Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
+```
+
+## 支持的运算符
+<!--
+## Supported operators
+-->
+
+您可以使用 `=`、`==`和 `!=` 对字段选择器进行运算（`=` 和 `==` 的意义是相同的）。
+例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 名称空间的 Kubernetes Service：
+<!--
+You can use the `=`, `==`, and `!=` operators with field selectors (`=` and `==` mean the same thing). This `kubectl` command, for example, selects all Kubernetes Services that aren't in the `default` namespace:
+-->
+
+```shell
+$ kubectl get services --all-namespaces --field-selector metadata.namespace!=default
+```
+
+## 链式选择器
+<!--
+## Chained selectors
+-->
+
+同[标签](/docs/concepts/overview/working-with-objects/labels)和其他选择器一样，字段选择器可以通过使用逗号分隔的列表组成一个选择链。
+下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod：
+<!--
+As with [label](/docs/concepts/overview/working-with-objects/labels) and other selectors, field selectors can be chained together as a comma-separated list. This `kubectl` command selects all Pods for which the `status.phase` does not equal `Running` and the `spec.restartPolicy` field equals `Always`:
+-->
+
+```shell
+$ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
+```
+
+## 多种资源类型
+<!--
+## Multiple resource types
+-->
+
+您能够跨多种资源类型来使用字段选择器。
+下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service：
+<!--
+You use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace:
+-->
+
+```shell
+$ kubectl get statefulsets,services --field-selector metadata.namespace!=default
+```
@@ -5,18 +5,25 @@ redirect_from:
 - "/docs/concepts/abstractions/overview/"
 - "/docs/concepts/abstractions/overview.html"
 content_template: templates/concept
-weight: 10
 ---

 {{% capture overview %}}
-
+<!--
+This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
+-->
 本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 `.yaml` 格式的文件中表示。
 {{% /capture %}}

 {{% capture body %}}
+<!--
+## Understanding Kubernetes Objects

+*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:

-
+* What containerized applications are running (and on which nodes)
+* The resources available to those applications
+* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
+-->

 ## 理解 Kubernetes 对象

@@ -26,14 +33,21 @@ weight: 10
 * 可以被应用使用的资源
 * 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略

+<!--
+A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.

+To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/).
+-->

 Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。

-操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go)
-，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
+操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中使用 [客户端库](/docs/reference/using-api/client-libraries/) 直接调用 Kubernetes API。

+<!--
+### Object Spec and Status

+Every Kubernetes object includes two nested object fields that govern the object's configuration: the object *spec* and the object *status*. The *spec*, which you must provide, describes your desired state for the object--the characteristics that you want the object to have. The *status* describes the *actual state* of the object, and is supplied and updated by the Kubernetes system. At any given time, the Kubernetes Control Plane actively manages an object's actual state to match the desired state you supplied.
+-->

 ### 对象规约（Spec）与状态（Status）

@@ -41,16 +55,28 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete
 *spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。
 *status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。

-
+<!--
+For example, a Kubernetes Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system responds to the difference between spec and status by making a correction--in this case, starting a replacement instance.
+-->

 例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。
 当创建 Deployment 时，可能需要设置 Deployment 的规约，以指定该应用需要有 3 个副本在运行。
 Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用的 3 个实例 —— 更新状态以与规约相匹配。
 如果那些实例中有失败的（一种状态变更），Kubernetes 系统通过修正来响应规约和状态之间的不一致 —— 这种情况，会启动一个新的实例来替换。

+<!--
+For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+-->
+
 关于对象 spec、status 和 metadata 的更多信息，查看 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。

+<!--
+### Describing a Kubernetes Object

+When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
+
+Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
+-->

 ### 描述 Kubernetes 对象

@@ -61,22 +87,40 @@ Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用

 这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约：

-{{< code file="nginx-deployment.yaml" >}}
+{{< codenew file="application/deployment.yaml" >}}

-使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create) 命令，将 `.yaml` 文件作为参数。下面是一个示例：
+<!--
+One way to create a Deployment using a `.yaml` file like the one above is to use the
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
+in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
+-->
+
+使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令，
+将 `.yaml` 文件作为参数。下面是一个示例：

 ```shell
-$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
 ```
-
+<!--
+The output is similar to this:
+-->

 输出类似如下这样：

 ```shell
-deployment "nginx-deployment" created
+deployment.apps/nginx-deployment created
 ```

+<!--
+## Required Fields

+In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
+
+* `apiVersion` - Which version of the Kubernetes API you're using to create this object
+* `kind` - What kind of object you want to create
+* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
+-->

 ### 必需字段

@@ -86,13 +130,27 @@ deployment "nginx-deployment" created
 * `kind` - 想要创建的对象的类型
 * `metadata` - 帮助识别对象唯一性的数据，包括一个 `name` 字符串、UID 和可选的 `namespace`

+<!--
+You'll also need to provide the object `spec` field. The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes.
+For example, the `spec` format for a `Pod` can be found
+[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
+and the `spec` format for a `Deployment` can be found
+[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
+-->

-
-也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/api/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
-
+也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
+例如，可以从
+[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+查看 `Pod` 的 `spec` 格式，
+并且可以从
+[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)
+查看 `Deployment` 的 `spec` 格式。
 {{% /capture %}}

 {{% capture whatsnext %}}
+<!--
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
+-->

-* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。
+* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。
 {{% /capture %}}
@@ -0,0 +1,219 @@
+---
+title: 命名空间
+content_template: templates/concept
+weight: 30
+---
+<!--
+---
+reviewers:
+- derekwaynecarr
+- mikedanese
+- thockin
+title: Namespaces
+content_template: templates/concept
+weight: 30
+---
+-->
+
+{{% capture overview %}}
+
+Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。
+这些虚拟集群被称为命名空间。
+<!--
+Kubernetes supports multiple virtual clusters backed by the same physical cluster.
+These virtual clusters are called namespaces.
+-->
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 何时使用多个命名空间
+<!--
+## When to Use Multiple Namespaces
+-->
+
+命名空间适用于存在很多跨多个团队或项目的用户的场景。
+对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当您需要命名空间提供的特性时，请开始使用它们。
+<!--
+Namespaces are intended for use in environments with many users spread across multiple
+teams, or projects.  For clusters with a few to tens of users, you should not
+need to create or think about namespaces at all.  Start using namespaces when you
+need the features they provide.
+-->
+
+命名空间为名称提供了一个范围。
+资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes 
+资源只能属于一个命名空间。
+<!--
+Namespaces provide a scope for names. Names of resources need to be unique within a namespace,
+but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes
+resource can only be in one namespace.
+-->
+
+命名空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/docs/concepts/policy/resource-quotas/)）。
+<!--
+Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
+-->
+
+在 Kubernetes 未来版本中，相同命名空间中的对象默认将具有相同的访问控制策略。
+<!--
+In future versions of Kubernetes, objects in the same namespace will have the same
+access control policies by default.
+-->
+
+不需要使用多个命名空间来分隔轻微不同的资源，例如同一软件的不同版本：
+使用[标签](/docs/user-guide/labels)来区分同一命名空间中的不同资源。
+<!--
+It is not necessary to use multiple namespaces just to separate slightly different
+resources, such as different versions of the same software: use [labels](/docs/user-guide/labels) to distinguish
+resources within the same namespace.
+-->
+
+## 使用命名空间
+<!--
+## Working with Namespaces
+-->
+
+命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。
+<!--
+Creation and deletion of namespaces are described in the [Admin Guide documentation
+for namespaces](/docs/admin/namespaces).
+-->
+
+### 查看命名空间
+<!--
+### Viewing namespaces
+-->
+
+您可以使用以下命令列出集群中现存的命名空间：
+<!--
+You can list the current namespaces in a cluster using:
+-->
+
+```shell
+$ kubectl get namespace
+```
+```
+NAME          STATUS    AGE
+default       Active    1d
+kube-system   Active    1d
+kube-public   Active    1d
+```
+
+Kubernetes 会创建三个初始命名空间：
+<!--
+Kubernetes starts with three initial namespaces:
+
+   * `default` The default namespace for objects with no other namespace
+   * `kube-system` The namespace for objects created by the Kubernetes system
+   * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
+-->
+   
+   * `default` 没有指明使用其它命名空间的对象所使用的默认命名空间
+   * `kube-system` Kubernetes 系统创建对象所使用的命名空间
+   * `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。
+
+### 为请求设置命名空间
+<!--
+### Setting the namespace for a request
+-->
+
+要为当前的请求设定一个命名空间，请使用 `--namespace` 参数。
+<!--
+To set the namespace for a current request, use the `--namespace` flag.
+-->
+
+例如：
+<!--
+For example:
+-->
+
+```shell
+kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
+kubectl get pods --namespace=<insert-namespace-name-here>
+```
+
+### 设置命名空间首选项
+<!--
+### Setting the namespace preference
+-->
+
+您可以永久保存该上下文中所有后续 kubectl 命令使用的命名空间。
+<!--
+You can permanently save the namespace for all subsequent kubectl commands in that
+context.
+-->
+
+```shell
+kubectl config set-context --current --namespace=<insert-namespace-name-here>
+# Validate it
+kubectl config view | grep namespace:
+```
+
+## 命名空间和 DNS
+<!--
+## Namespaces and DNS
+-->
+
+当您创建一个[服务](/docs/user-guide/services)时，Kubernetes 会创建一个相应的[DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。
+<!--
+When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
+-->
+
+该条目的形式是 `<service-name>.<namespace-name>.svc.cluster.local`，
+这意味着如果容器只使用 `<service-name>`，它将被解析到本地命名空间的服务。
+这对于跨多个命名空间（如开发、分级和生产）使用相同的配置非常有用。
+如果您希望跨命名空间访问，则需要使用完全限定域名（FQDN）。
+<!--
+This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
+that if a container just uses `<service-name>`, it will resolve to the service which
+is local to a namespace.  This is useful for using the same configuration across
+multiple namespaces such as Development, Staging and Production.  If you want to reach
+across namespaces, you need to use the fully qualified domain name (FQDN).
+-->
+
+## 并非所有对象都在命名空间中
+<!--
+## Not All Objects are in a Namespace
+-->
+
+大多数 kubernetes 资源（例如 Pod、服务、副本控制器等）都位于某些命名空间中。
+但是命名空间资源本身并不在命名空间中。
+<!--
+Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
+in some namespaces.  However namespace resources are not themselves in a namespace.
+-->
+
+而且底层资源，例如[节点](/docs/admin/node)和持久化卷不属于任何命名空间。
+<!--
+And low-level resources, such as [nodes](/docs/admin/node) and
+persistentVolumes, are not in any namespace.
+-->
+
+查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中：
+<!--
+To see which Kubernetes resources are and aren't in a namespace:
+-->
+
+```shell
+# In a namespace
+kubectl api-resources --namespaced=true
+
+# Not in a namespace
+kubectl api-resources --namespaced=false
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!--
+* Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
+* Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
+-->
+
+* 了解相关内容 [创建一个新的命名空间](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
+* 了解相关内容 [删除一个命名空间](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
+{{% /capture %}}
+
@@ -0,0 +1,11 @@
+---
+title: "策略"
+weight: 160
+---
+
+<!--
+---
+title: "Policies"
+weight: 160
+---
+-->
@@ -0,0 +1,11 @@
+---
+title: "服务、负载均衡和联网"
+weight: 80
+---
+
+<!--
+---
+title: "Services, Load Balancing, and Networking"
+weight: 80
+---
+-->
@@ -0,0 +1,126 @@
+---
+title: Ingress 控制器
+content_template: templates/concept
+weight: 40
+---
+<!--
+title: Ingress Controllers
+content_template: templates/concept
+weight: 40
+-->
+
+{{% capture overview %}}
+
+<!--
+In order for the Ingress resource to work, the cluster must have an ingress controller running. 
+
+Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers 
+are not started automatically with a cluster. Use this page to choose the ingress controller implementation 
+that best fits your cluster.
+
+Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
+  [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
+-->
+
+为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
+
+与其他类型的控制器不同，它们是作为 `kube-controller-manager` 二进制文件的一部分运行的，而 Ingress 控制器不是随集群自动启动的。
+通过此页面可选择最适合您的集群的 ingress 控制器实现。
+
+Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和
+  [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+<!--
+## Additional controllers
+
+* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress 
+  controller with [community](https://www.getambassador.io/docs) or 
+  [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
+* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).  
+* [Contour](https://github.com/heptio/contour) is an [Envoy](https://www.envoyproxy.io) based ingress controller
+  provided and supported by Heptio.
+* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
+* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
+  for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
+* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).  
+* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
+* [Istio](https://istio.io/) based ingress controller
+  [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
+* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
+  [commercial](https://konghq.com/kong-enterprise/) support and maintenance for the
+  [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
+* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
+  [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
+* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
+  ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
+  support by [Containous](https://containo.us/services).
+-->
+
+## 其他控制器
+
+* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress 
+  控制器，有着来自 [Datawire](https://www.datawire.io/) [社区](https://www.getambassador.io/docs)或[商业](https://www.getambassador.io/pro/)的支持。
+* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护.  
+* [Contour](https://github.com/heptio/contour) 是一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它由 Heptio 提供和支持。
+* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。
+* F5 Networks 为 [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供[支持和维护](https://support.f5.com/csp/article/K86859508)。
+* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 
+* 基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器
+  [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress)，
+  [用于 Kubernetes 的 HAProxy Ingress 控制器](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)这篇博文提到它。
+  [HAProxy Technologies](https://www.haproxy.com/) 为 HAProxy 企业版和
+  ingress 控制器 [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) 提供支持和维护。
+* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。
+* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。
+* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。
+* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器
+  （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。
+
+<!--
+## Using multiple Ingress controllers
+
+You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) 
+within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
+[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 
+to indicate which ingress controller should be used if more than one exists within your cluster.
+
+If you do not define a class, your cloud provider may use a default ingress controller.
+
+Ideally, all ingress controllers should fulfill this specification, but the various ingress
+controllers operate slightly differently.
+-->
+## 使用多个 Ingress 控制器
+
+你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。
+创建 ingress 时，应该使用适当的
+[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress 
+以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。
+
+如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。
+
+理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。
+
+{{< note >}}
+<!--
+Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
+-->
+确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
+{{< /note >}}
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+<!--
+* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
+* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
+-->
+
+* 了解更多关于 [Ingress](/docs/concepts/services-networking/ingress/)。
+* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。
+{{% /capture %}}
@@ -0,0 +1,17 @@
+注意：这些测试是从 kubernetes 导入的代码实际上并不打算在存储库之外使用。
+这就导致了供应商依赖问题。因此，我们必须在 travis 配置这些行:
+<!--
+Note: These tests are importing code from kubernetes that isn't really
+meant to be used outside the repo. This causes vendoring problems. As
+a result, we have to work around those with these lines in the travis
+config:
+-->
+
+```
+- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery
+- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver
+- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go
+- cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/
+- rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/*
+- cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/
+```
@@ -0,0 +1,69 @@
+# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster.
+# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
+# Note that this Daemonset will not work straight out of the box for your cloud, this is
+# meant to be a guideline.
+
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: cloud-controller-manager
+  namespace: kube-system
+---
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: system:cloud-controller-manager
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: cluster-admin
+subjects:
+- kind: ServiceAccount
+  name: cloud-controller-manager
+  namespace: kube-system
+---
+apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  labels:
+    k8s-app: cloud-controller-manager
+  name: cloud-controller-manager
+  namespace: kube-system
+spec:
+  selector:
+    matchLabels:
+      k8s-app: cloud-controller-manager
+  template:
+    metadata:
+      labels:
+        k8s-app: cloud-controller-manager
+    spec:
+      serviceAccountName: cloud-controller-manager
+      containers:
+      - name: cloud-controller-manager
+        # for in-tree providers we use k8s.gcr.io/cloud-controller-manager
+        # this can be replaced with any other image for out-of-tree providers
+        image: k8s.gcr.io/cloud-controller-manager:v1.8.0
+        command:
+        - /usr/local/bin/cloud-controller-manager
+        - --cloud-provider=<YOUR_CLOUD_PROVIDER>   # Add your own cloud provider here!
+        - --leader-elect=true
+        - --use-service-account-credentials
+        # these flags will vary for every cloud provider
+        - --allocate-node-cidrs=true
+        - --configure-cloud-routes=true
+        - --cluster-cidr=172.17.0.0/16
+      tolerations:
+      # this is required so CCM can bootstrap itself
+      - key: node.cloudprovider.kubernetes.io/uninitialized
+        value: "true"
+        effect: NoSchedule
+      # this is to have the daemonset runnable on master nodes
+      # the taint may vary depending on your cluster setup
+      - key: node-role.kubernetes.io/master
+        effect: NoSchedule
+      # this is to restrict CCM to only run on master nodes
+      # the node selector may vary depending on your cluster setup
+      nodeSelector:
+        node-role.kubernetes.io/master: ""
@@ -0,0 +1,13 @@
+kind: InitializerConfiguration
+apiVersion: admissionregistration.k8s.io/v1alpha1
+metadata:
+  name: pvlabel.kubernetes.io
+initializers:
+  - name: pvlabel.kubernetes.io
+    rules:
+    - apiGroups:
+      - ""
+      apiVersions:
+      - "*"
+      resources:
+      - persistentvolumes
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: busybox
+  namespace: default
+spec:
+  containers:
+  - name: busybox
+    image: busybox:1.28
+    command:
+      - sleep
+      - "3600"
+    imagePullPolicy: IfNotPresent
+  restartPolicy: Always
@@ -0,0 +1,33 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: dns-autoscaler
+  namespace: kube-system
+  labels:
+    k8s-app: dns-autoscaler
+spec:
+  selector:
+    matchLabels:
+       k8s-app: dns-autoscaler
+  template:
+    metadata:
+      labels:
+        k8s-app: dns-autoscaler
+    spec:
+      containers:
+      - name: autoscaler
+        image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
+        resources:
+            requests:
+                cpu: "20m"
+                memory: "10Mi"
+        command:
+          - /cluster-proportional-autoscaler
+          - --namespace=kube-system
+          - --configmap=dns-autoscaler
+          - --target=<SCALE_TARGET>
+          # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
+          # If using small nodes, "nodesPerReplica" should dominate.
+          - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
+          - --logtostderr=true
+          - --v=2
@@ -0,0 +1,25 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: fluentd-config
+data:
+  fluentd.conf: |
+    <source>
+      type tail
+      format none
+      path /var/log/1.log
+      pos_file /var/log/1.log.pos
+      tag count.format1
+    </source>
+
+    <source>
+      type tail
+      format none
+      path /var/log/2.log
+      pos_file /var/log/2.log.pos
+      tag count.format2
+    </source>
+
+    <match **>
+      type google_cloud
+    </match>
@@ -0,0 +1,39 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: counter
+spec:
+  containers:
+  - name: count
+    image: busybox
+    args:
+    - /bin/sh
+    - -c
+    - >
+      i=0;
+      while true;
+      do
+        echo "$i: $(date)" >> /var/log/1.log;
+        echo "$(date) INFO $i" >> /var/log/2.log;
+        i=$((i+1));
+        sleep 1;
+      done
+    volumeMounts:
+    - name: varlog
+      mountPath: /var/log
+  - name: count-agent
+    image: k8s.gcr.io/fluentd-gcp:1.30
+    env:
+    - name: FLUENTD_ARGS
+      value: -c /etc/fluentd-config/fluentd.conf
+    volumeMounts:
+    - name: varlog
+      mountPath: /var/log
+    - name: config-volume
+      mountPath: /etc/fluentd-config
+  volumes:
+  - name: varlog
+    emptyDir: {}
+  - name: config-volume
+    configMap:
+      name: fluentd-config
@@ -0,0 +1,38 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: counter
+spec:
+  containers:
+  - name: count
+    image: busybox
+    args:
+    - /bin/sh
+    - -c
+    - >
+      i=0;
+      while true;
+      do
+        echo "$i: $(date)" >> /var/log/1.log;
+        echo "$(date) INFO $i" >> /var/log/2.log;
+        i=$((i+1));
+        sleep 1;
+      done
+    volumeMounts:
+    - name: varlog
+      mountPath: /var/log
+  - name: count-log-1
+    image: busybox
+    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
+    volumeMounts:
+    - name: varlog
+      mountPath: /var/log
+  - name: count-log-2
+    image: busybox
+    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
+    volumeMounts:
+    - name: varlog
+      mountPath: /var/log
+  volumes:
+  - name: varlog
+    emptyDir: {}
@@ -0,0 +1,26 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: counter
+spec:
+  containers:
+  - name: count
+    image: busybox
+    args:
+    - /bin/sh
+    - -c
+    - >
+      i=0;
+      while true;
+      do
+        echo "$i: $(date)" >> /var/log/1.log;
+        echo "$(date) INFO $i" >> /var/log/2.log;
+        i=$((i+1));
+        sleep 1;
+      done
+    volumeMounts:
+    - name: varlog
+      mountPath: /var/log
+  volumes:
+  - name: varlog
+    emptyDir: {}
@@ -0,0 +1,10 @@
+{
+  "kind": "Namespace",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "development",
+    "labels": {
+      "name": "development"
+    }
+  }
+}
@@ -0,0 +1,10 @@
+{
+  "kind": "Namespace",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "production",
+    "labels": {
+      "name": "production"
+    }
+  }
+}
@@ -0,0 +1,11 @@
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: pvc-quota-demo-2
+spec:
+  storageClassName: manual
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 4Gi
@@ -0,0 +1,11 @@
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: pvc-quota-demo
+spec:
+  storageClassName: manual
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 3Gi
@@ -0,0 +1,9 @@
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: object-quota-demo
+spec:
+  hard:
+    persistentvolumeclaims: "1"
+    services.loadbalancers: "2"
+    services.nodeports: "0"
@@ -0,0 +1,17 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: pod-quota-demo
+spec:
+  selector:
+    matchLabels:
+      purpose: quota-demo
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        purpose: quota-demo
+    spec:
+      containers:
+      - name: pod-quota-demo
+        image: nginx
@@ -0,0 +1,7 @@
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: pod-demo
+spec:
+  hard:
+    pods: "2"
@@ -0,0 +1,67 @@
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: my-scheduler
+  namespace: kube-system
+---
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: my-scheduler-as-kube-scheduler
+subjects:
+- kind: ServiceAccount
+  name: my-scheduler
+  namespace: kube-system
+roleRef:
+  kind: ClusterRole
+  name: kube-scheduler
+  apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    component: scheduler
+    tier: control-plane
+  name: my-scheduler
+  namespace: kube-system
+spec:
+  selector:
+    matchLabels:
+      component: scheduler
+      tier: control-plane
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        component: scheduler
+        tier: control-plane
+        version: second
+    spec:
+      serviceAccountName: my-scheduler
+      containers:
+      - command:
+        - /usr/local/bin/kube-scheduler
+        - --address=0.0.0.0
+        - --leader-elect=false
+        - --scheduler-name=my-scheduler
+        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
+        livenessProbe:
+          httpGet:
+            path: /healthz
+            port: 10251
+          initialDelaySeconds: 15
+        name: kube-second-scheduler
+        readinessProbe:
+          httpGet:
+            path: /healthz
+            port: 10251
+        resources:
+          requests:
+            cpu: '0.1'
+        securityContext:
+          privileged: false
+        volumeMounts: []
+      hostNetwork: false
+      hostPID: false
+      volumes: []
@@ -0,0 +1,10 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: no-annotation
+  labels:
+    name: multischeduler-example
+spec:
+  containers:
+  - name: pod-with-no-annotation-container
+    image: k8s.gcr.io/pause:2.0
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotation-default-scheduler
+  labels:
+    name: multischeduler-example
+spec:
+  schedulerName: default-scheduler
+  containers:
+  - name: pod-with-default-annotation-container
+    image: k8s.gcr.io/pause:2.0
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotation-second-scheduler
+  labels:
+    name: multischeduler-example
+spec:
+  schedulerName: my-scheduler
+  containers:
+  - name: pod-with-second-annotation-container
+    image: k8s.gcr.io/pause:2.0
@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: cassandra
+  name: cassandra
+spec:
+  clusterIP: None
+  ports:
+  - port: 9042
+  selector:
+    app: cassandra
@@ -0,0 +1,100 @@
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: cassandra
+  labels:
+    app: cassandra
+spec:
+  serviceName: cassandra
+  replicas: 3
+  selector:
+    matchLabels:
+      app: cassandra
+  template:
+    metadata:
+      labels:
+        app: cassandra
+    spec:
+      terminationGracePeriodSeconds: 1800
+      containers:
+      - name: cassandra
+        image: gcr.io/google-samples/cassandra:v13
+        imagePullPolicy: Always
+        ports:
+        - containerPort: 7000
+          name: intra-node
+        - containerPort: 7001
+          name: tls-intra-node
+        - containerPort: 7199
+          name: jmx
+        - containerPort: 9042
+          name: cql
+        resources:
+          limits:
+            cpu: "500m"
+            memory: 1Gi
+          requests:
+            cpu: "500m"
+            memory: 1Gi
+        securityContext:
+          capabilities:
+            add:
+              - IPC_LOCK
+        lifecycle:
+          preStop:
+            exec:
+              command: 
+              - /bin/sh
+              - -c
+              - nodetool drain
+        env:
+          - name: MAX_HEAP_SIZE
+            value: 512M
+          - name: HEAP_NEWSIZE
+            value: 100M
+          - name: CASSANDRA_SEEDS
+            value: "cassandra-0.cassandra.default.svc.cluster.local"
+          - name: CASSANDRA_CLUSTER_NAME
+            value: "K8Demo"
+          - name: CASSANDRA_DC
+            value: "DC1-K8Demo"
+          - name: CASSANDRA_RACK
+            value: "Rack1-K8Demo"
+          - name: POD_IP
+            valueFrom:
+              fieldRef:
+                fieldPath: status.podIP
+        readinessProbe:
+          exec:
+            command:
+            - /bin/bash
+            - -c
+            - /ready-probe.sh
+          initialDelaySeconds: 15
+          timeoutSeconds: 5
+        # These volume mounts are persistent. They are like inline claims,
+        # but not exactly because the names need to match exactly one of
+        # the stateful pod volumes.
+        volumeMounts:
+        - name: cassandra-data
+          mountPath: /cassandra_data
+  # These are converted to volume claims by the controller
+  # and mounted at the paths mentioned above.
+  # do not use these in production until ssd GCEPersistentDisk or other ssd pd
+  volumeClaimTemplates:
+  - metadata:
+      name: cassandra-data
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      storageClassName: fast
+      resources:
+        requests:
+          storage: 1Gi
+---
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: fast
+provisioner: k8s.io/minikube-hostpath
+parameters:
+  type: pd-ssd
@@ -0,0 +1,21 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: patch-demo
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: patch-demo-ctr
+        image: nginx
+      tolerations:
+      - effect: NoSchedule
+        key: dedicated
+        value: test-team
@@ -0,0 +1,19 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 4 # Update the replicas from 2 to 4
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.8
+        ports:
+        - containerPort: 80
@@ -0,0 +1,19 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8
+        ports:
+        - containerPort: 80
@@ -0,0 +1,19 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 2 # tells deployment to run 2 pods matching the template
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80
@@ -0,0 +1,38 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: frontend
+  labels:
+    app: guestbook
+spec:
+  selector:
+    matchLabels:
+      app: guestbook
+      tier: frontend
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: guestbook
+        tier: frontend
+    spec:
+      containers:
+      - name: php-redis
+        image: gcr.io/google-samples/gb-frontend:v4
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        env:
+        - name: GET_HOSTS_FROM
+          value: dns
+          # Using `GET_HOSTS_FROM=dns` requires your cluster to
+          # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
+          # service launched automatically. However, if the cluster you are using
+          # does not have a built-in DNS service, you can instead
+          # access an environment variable to find the master
+          # service's host. To do so, comment out the 'value: dns' line above, and
+          # uncomment the line below:
+          # value: env
+        ports:
+        - containerPort: 80
@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: frontend
+  labels:
+    app: guestbook
+    tier: frontend
+spec:
+  # comment or delete the following line if you want to use a LoadBalancer
+  type: NodePort 
+  # if your cluster supports it, uncomment the following to automatically create
+  # an external load-balanced IP for the frontend service.
+  # type: LoadBalancer
+  ports:
+  - port: 80
+  selector:
+    app: guestbook
+    tier: frontend
@@ -0,0 +1,29 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: redis-master
+  labels:
+    app: redis
+spec:
+  selector:
+    matchLabels:
+      app: redis
+      role: master
+      tier: backend
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: redis
+        role: master
+        tier: backend
+    spec:
+      containers:
+      - name: master
+        image: k8s.gcr.io/redis:e2e  # or just image: redis
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        ports:
+        - containerPort: 6379
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: redis-master
+  labels:
+    app: redis
+    role: master
+    tier: backend
+spec:
+  ports:
+  - port: 6379
+    targetPort: 6379
+  selector:
+    app: redis
+    role: master
+    tier: backend
@@ -0,0 +1,40 @@
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: redis-slave
+  labels:
+    app: redis
+spec:
+  selector:
+    matchLabels:
+      app: redis
+      role: slave
+      tier: backend
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: redis
+        role: slave
+        tier: backend
+    spec:
+      containers:
+      - name: slave
+        image: gcr.io/google_samples/gb-redisslave:v1
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        env:
+        - name: GET_HOSTS_FROM
+          value: dns
+          # Using `GET_HOSTS_FROM=dns` requires your cluster to
+          # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
+          # service launched automatically. However, if the cluster you are using
+          # does not have a built-in DNS service, you can instead
+          # access an environment variable to find the master
+          # service's host. To do so, comment out the 'value: dns' line above, and
+          # uncomment the line below:
+          # value: env
+        ports:
+        - containerPort: 6379
@@ -0,0 +1,15 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: redis-slave
+  labels:
+    app: redis
+    role: slave
+    tier: backend
+spec:
+  ports:
+  - port: 6379
+  selector:
+    app: redis
+    role: slave
+    tier: backend
@@ -0,0 +1,13 @@
+apiVersion: autoscaling/v1
+kind: HorizontalPodAutoscaler
+metadata:
+  name: php-apache
+  namespace: default
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: php-apache
+  minReplicas: 1
+  maxReplicas: 10
+  targetCPUUtilizationPercentage: 50
@@ -0,0 +1,18 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: process-item-$ITEM
+  labels:
+    jobgroup: jobexample
+spec:
+  template:
+    metadata:
+      name: jobexample
+      labels:
+        jobgroup: jobexample
+    spec:
+      containers:
+      - name: c
+        image: busybox
+        command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
+      restartPolicy: Never
@@ -0,0 +1,20 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: job-wq-1
+spec:
+  completions: 8
+  parallelism: 2
+  template:
+    metadata:
+      name: job-wq-1
+    spec:
+      containers:
+      - name: c
+        image: gcr.io/<project>/job-wq-1
+        env:
+        - name: BROKER_URL
+          value: amqp://guest:guest@rabbitmq-service:5672
+        - name: QUEUE
+          value: job1
+      restartPolicy: OnFailure
@@ -0,0 +1,10 @@
+# Specify BROKER_URL and QUEUE when running
+FROM ubuntu:14.04
+
+RUN apt-get update && \
+    apt-get install -y curl ca-certificates amqp-tools python \
+       --no-install-recommends \
+    && rm -rf /var/lib/apt/lists/*
+COPY ./worker.py /worker.py
+
+CMD  /usr/bin/amqp-consume --url=$BROKER_URL -q $QUEUE -c 1 /worker.py
@@ -0,0 +1,20 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: job-wq-1
+spec:
+  completions: 8
+  parallelism: 2
+  template:
+    metadata:
+      name: job-wq-1
+    spec:
+      containers:
+      - name: c
+        image: gcr.io/<project>/job-wq-1
+        env:
+        - name: BROKER_URL
+          value: amqp://guest:guest@rabbitmq-service:5672
+        - name: QUEUE
+          value: job1
+      restartPolicy: OnFailure
@@ -0,0 +1,7 @@
+#!/usr/bin/env python
+
+# Just prints standard out and sleeps for 10 seconds.
+import sys
+import time
+print("Processing " + sys.stdin.lines())
+time.sleep(10)
@@ -0,0 +1,6 @@
+FROM python
+RUN pip install redis
+COPY ./worker.py /worker.py
+COPY ./rediswq.py /rediswq.py
+
+CMD  python worker.py
@@ -0,0 +1,15 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: redis-master
+  labels:
+    app: redis
+spec:
+  containers:
+    - name: master
+      image: redis
+      env:
+        - name: MASTER
+          value: "true"
+      ports:
+        - containerPort: 6379
@@ -0,0 +1,10 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: redis
+spec:
+  ports:
+    - port: 6379
+      targetPort: 6379
+  selector:
+    app: redis
@@ -0,0 +1,130 @@
+#!/usr/bin/env python
+
+# Based on http://peter-hoffmann.com/2012/python-simple-queue-redis-queue.html 
+# and the suggestion in the redis documentation for RPOPLPUSH, at 
+# http://redis.io/commands/rpoplpush, which suggests how to implement a work-queue.
+
+ 
+import redis
+import uuid
+import hashlib
+
+class RedisWQ(object):
+    """Simple Finite Work Queue with Redis Backend
+
+    This work queue is finite: as long as no more work is added
+    after workers start, the workers can detect when the queue
+    is completely empty.
+
+    The items in the work queue are assumed to have unique values.
+
+    This object is not intended to be used by multiple threads
+    concurrently.
+    """
+    def __init__(self, name, **redis_kwargs):
+       """The default connection parameters are: host='localhost', port=6379, db=0
+
+       The work queue is identified by "name".  The library may create other
+       keys with "name" as a prefix. 
+       """
+       self._db = redis.StrictRedis(**redis_kwargs)
+       # The session ID will uniquely identify this "worker".
+       self._session = str(uuid.uuid4())
+       # Work queue is implemented as two queues: main, and processing.
+       # Work is initially in main, and moved to processing when a client picks it up.
+       self._main_q_key = name
+       self._processing_q_key = name + ":processing"
+       self._lease_key_prefix = name + ":leased_by_session:"
+
+    def sessionID(self):
+        """Return the ID for this session."""
+        return self._session
+
+    def _main_qsize(self):
+        """Return the size of the main queue."""
+        return self._db.llen(self._main_q_key)
+
+    def _processing_qsize(self):
+        """Return the size of the main queue."""
+        return self._db.llen(self._processing_q_key)
+
+    def empty(self):
+        """Return True if the queue is empty, including work being done, False otherwise.
+
+        False does not necessarily mean that there is work available to work on right now,
+        """
+        return self._main_qsize() == 0 and self._processing_qsize() == 0
+
+# TODO: implement this
+#    def check_expired_leases(self):
+#        """Return to the work queueReturn True if the queue is empty, False otherwise."""
+#        # Processing list should not be _too_ long since it is approximately as long
+#        # as the number of active and recently active workers.
+#        processing = self._db.lrange(self._processing_q_key, 0, -1)
+#        for item in processing:
+#          # If the lease key is not present for an item (it expired or was 
+#          # never created because the client crashed before creating it)
+#          # then move the item back to the main queue so others can work on it.
+#          if not self._lease_exists(item):
+#            TODO: transactionally move the key from processing queue to
+#            to main queue, while detecting if a new lease is created
+#            or if either queue is modified.
+
+    def _itemkey(self, item):
+        """Returns a string that uniquely identifies an item (bytes)."""
+        return hashlib.sha224(item).hexdigest()
+
+    def _lease_exists(self, item):
+        """True if a lease on 'item' exists."""
+        return self._db.exists(self._lease_key_prefix + self._itemkey(item))
+
+    def lease(self, lease_secs=60, block=True, timeout=None):
+        """Begin working on an item the work queue. 
+
+        Lease the item for lease_secs.  After that time, other
+        workers may consider this client to have crashed or stalled
+        and pick up the item instead.
+
+        If optional args block is true and timeout is None (the default), block
+        if necessary until an item is available."""
+        if block:
+            item = self._db.brpoplpush(self._main_q_key, self._processing_q_key, timeout=timeout)
+        else:
+            item = self._db.rpoplpush(self._main_q_key, self._processing_q_key)
+        if item:
+            # Record that we (this session id) are working on a key.  Expire that
+            # note after the lease timeout.
+            # Note: if we crash at this line of the program, then GC will see no lease
+            # for this item a later return it to the main queue.
+            itemkey = self._itemkey(item)
+            self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session)
+        return item
+
+    def complete(self, value):
+        """Complete working on the item with 'value'.
+
+        If the lease expired, the item may not have completed, and some
+        other worker may have picked it up.  There is no indication
+        of what happened.
+        """
+        self._db.lrem(self._processing_q_key, 0, value)
+        # If we crash here, then the GC code will try to move the value, but it will
+        # not be here, which is fine.  So this does not need to be a transaction.
+        itemkey = self._itemkey(value)
+        self._db.delete(self._lease_key_prefix + itemkey, self._session)
+
+# TODO: add functions to clean up all keys associated with "name" when
+# processing is complete.
+
+# TODO: add a function to add an item to the queue.  Atomically
+# check if the queue is empty and if so fail to add the item
+# since other workers might think work is done and be in the process
+# of exiting.
+
+# TODO(etune): move to my own github for hosting, e.g. github.com/erictune/rediswq-py and
+# make it so it can be pip installed by anyone (see
+# http://stackoverflow.com/questions/8247605/configuring-so-that-pip-install-can-work-from-github)
+
+# TODO(etune): finish code to GC expired leases, and call periodically
+#  e.g. each time lease times out.
+
@@ -0,0 +1,7 @@
+#!/usr/bin/env python
+
+# Just prints standard out and sleeps for 10 seconds.
+import sys
+import time
+print("Processing " + sys.stdin.lines())
+time.sleep(10)
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: mysql
+  labels:
+    app: mysql
+data:
+  master.cnf: |
+    # Apply this config only on the master.
+    [mysqld]
+    log-bin
+  slave.cnf: |
+    # Apply this config only on slaves.
+    [mysqld]
+    super-read-only
+
@@ -0,0 +1,43 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: mysql
+spec:
+  ports:
+  - port: 3306
+  selector:
+    app: mysql
+  clusterIP: None
+---
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: mysql
+spec:
+  selector:
+    matchLabels:
+      app: mysql
+  strategy:
+    type: Recreate
+  template:
+    metadata:
+      labels:
+        app: mysql
+    spec:
+      containers:
+      - image: mysql:5.6
+        name: mysql
+        env:
+          # Use secret in real usage
+        - name: MYSQL_ROOT_PASSWORD
+          value: password
+        ports:
+        - containerPort: 3306
+          name: mysql
+        volumeMounts:
+        - name: mysql-persistent-storage
+          mountPath: /var/lib/mysql
+      volumes:
+      - name: mysql-persistent-storage
+        persistentVolumeClaim:
+          claimName: mysql-pv-claim
@@ -0,0 +1,26 @@
+kind: PersistentVolume
+apiVersion: v1
+metadata:
+  name: mysql-pv-volume
+  labels:
+    type: local
+spec:
+  storageClassName: manual
+  capacity:
+    storage: 20Gi
+  accessModes:
+    - ReadWriteOnce
+  hostPath:
+    path: "/mnt/data"
+---
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: mysql-pv-claim
+spec:
+  storageClassName: manual
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 20Gi
@@ -0,0 +1,30 @@
+# Headless service for stable DNS entries of StatefulSet members.
+apiVersion: v1
+kind: Service
+metadata:
+  name: mysql
+  labels:
+    app: mysql
+spec:
+  ports:
+  - name: mysql
+    port: 3306
+  clusterIP: None
+  selector:
+    app: mysql
+---
+# Client service for connecting to any MySQL instance for reads.
+# For writes, you must instead connect to the master: mysql-0.mysql.
+apiVersion: v1
+kind: Service
+metadata:
+  name: mysql-read
+  labels:
+    app: mysql
+spec:
+  ports:
+  - name: mysql
+    port: 3306
+  selector:
+    app: mysql
+
@@ -0,0 +1,167 @@
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: mysql
+spec:
+  selector:
+    matchLabels:
+      app: mysql
+  serviceName: mysql
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: mysql
+    spec:
+      initContainers:
+      - name: init-mysql
+        image: mysql:5.7
+        command:
+        - bash
+        - "-c"
+        - |
+          set -ex
+          # Generate mysql server-id from pod ordinal index.
+          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
+          ordinal=${BASH_REMATCH[1]}
+          echo [mysqld] > /mnt/conf.d/server-id.cnf
+          # Add an offset to avoid reserved server-id=0 value.
+          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
+          # Copy appropriate conf.d files from config-map to emptyDir.
+          if [[ $ordinal -eq 0 ]]; then
+            cp /mnt/config-map/master.cnf /mnt/conf.d/
+          else
+            cp /mnt/config-map/slave.cnf /mnt/conf.d/
+          fi
+        volumeMounts:
+        - name: conf
+          mountPath: /mnt/conf.d
+        - name: config-map
+          mountPath: /mnt/config-map
+      - name: clone-mysql
+        image: gcr.io/google-samples/xtrabackup:1.0
+        command:
+        - bash
+        - "-c"
+        - |
+          set -ex
+          # Skip the clone if data already exists.
+          [[ -d /var/lib/mysql/mysql ]] && exit 0
+          # Skip the clone on master (ordinal index 0).
+          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
+          ordinal=${BASH_REMATCH[1]}
+          [[ $ordinal -eq 0 ]] && exit 0
+          # Clone data from previous peer.
+          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
+          # Prepare the backup.
+          xtrabackup --prepare --target-dir=/var/lib/mysql
+        volumeMounts:
+        - name: data
+          mountPath: /var/lib/mysql
+          subPath: mysql
+        - name: conf
+          mountPath: /etc/mysql/conf.d
+      containers:
+      - name: mysql
+        image: mysql:5.7
+        env:
+        - name: MYSQL_ALLOW_EMPTY_PASSWORD
+          value: "1"
+        ports:
+        - name: mysql
+          containerPort: 3306
+        volumeMounts:
+        - name: data
+          mountPath: /var/lib/mysql
+          subPath: mysql
+        - name: conf
+          mountPath: /etc/mysql/conf.d
+        resources:
+          requests:
+            cpu: 500m
+            memory: 1Gi
+        livenessProbe:
+          exec:
+            command: ["mysqladmin", "ping"]
+          initialDelaySeconds: 30
+          periodSeconds: 10
+          timeoutSeconds: 5
+        readinessProbe:
+          exec:
+            # Check we can execute queries over TCP (skip-networking is off).
+            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
+          initialDelaySeconds: 5
+          periodSeconds: 2
+          timeoutSeconds: 1
+      - name: xtrabackup
+        image: gcr.io/google-samples/xtrabackup:1.0
+        ports:
+        - name: xtrabackup
+          containerPort: 3307
+        command:
+        - bash
+        - "-c"
+        - |
+          set -ex
+          cd /var/lib/mysql
+
+          # Determine binlog position of cloned data, if any.
+          if [[ -f xtrabackup_slave_info ]]; then
+            # XtraBackup already generated a partial "CHANGE MASTER TO" query
+            # because we're cloning from an existing slave.
+            mv xtrabackup_slave_info change_master_to.sql.in
+            # Ignore xtrabackup_binlog_info in this case (it's useless).
+            rm -f xtrabackup_binlog_info
+          elif [[ -f xtrabackup_binlog_info ]]; then
+            # We're cloning directly from master. Parse binlog position.
+            [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
+            rm xtrabackup_binlog_info
+            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
+                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
+          fi
+
+          # Check if we need to complete a clone by starting replication.
+          if [[ -f change_master_to.sql.in ]]; then
+            echo "Waiting for mysqld to be ready (accepting connections)"
+            until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
+
+            echo "Initializing replication from clone position"
+            # In case of container restart, attempt this at-most-once.
+            mv change_master_to.sql.in change_master_to.sql.orig
+            mysql -h 127.0.0.1 <<EOF
+          $(<change_master_to.sql.orig),
+            MASTER_HOST='mysql-0.mysql',
+            MASTER_USER='root',
+            MASTER_PASSWORD='',
+            MASTER_CONNECT_RETRY=10;
+          START SLAVE;
+          EOF
+          fi
+
+          # Start a server to send backups when requested by peers.
+          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
+            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
+        volumeMounts:
+        - name: data
+          mountPath: /var/lib/mysql
+          subPath: mysql
+        - name: conf
+          mountPath: /etc/mysql/conf.d
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+      volumes:
+      - name: conf
+        emptyDir: {}
+      - name: config-map
+        configMap:
+          name: mysql
+  volumeClaimTemplates:
+  - metadata:
+      name: data
+    spec:
+      accessModes: ["ReadWriteOnce"]
+      resources:
+        requests:
+          storage: 10Gi
@@ -0,0 +1,34 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx-svc
+  labels:
+    app: nginx
+spec:
+  type: LoadBalancer
+  ports:
+  - port: 80
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+  labels:
+    app: nginx
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80
@@ -0,0 +1,23 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+        resources:
+          limits:
+            memory: "128Mi"
+            cpu: "500m"
+        ports:
+        - containerPort: 80
@@ -0,0 +1,19 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80
@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx-svc
+  labels:
+    app: nginx
+spec:
+  type: LoadBalancer
+  ports:
+  - port: 80
+  selector:
+    app: nginx
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: shell-demo
+spec:
+  volumes:
+  - name: shared-data
+    emptyDir: {}
+  containers:
+  - name: nginx
+    image: nginx
+    volumeMounts:
+    - name: shared-data
+      mountPath: /usr/share/nginx/html
@@ -0,0 +1,19 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  minReadySeconds: 5
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80
@@ -0,0 +1,18 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.11.9 # update the image
+        ports:
+        - containerPort: 80
@@ -0,0 +1,47 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  labels:
+    app: nginx
+spec:
+  ports:
+  - port: 80
+    name: web
+  clusterIP: None
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+spec:
+  serviceName: "nginx"
+  podManagementPolicy: "Parallel"
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: k8s.gcr.io/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:
+  - metadata:
+      name: www
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      resources:
+        requests:
+          storage: 1Gi
@@ -0,0 +1,47 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  labels:
+    app: nginx
+spec:
+  ports:
+  - port: 80
+    name: web
+  clusterIP: None
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+spec:
+  serviceName: "nginx"
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: k8s.gcr.io/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:
+  - metadata:
+      name: www
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      resources:
+        requests:
+          storage: 1Gi
+
@@ -0,0 +1,65 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: wordpress-mysql
+  labels:
+    app: wordpress
+spec:
+  ports:
+    - port: 3306
+  selector:
+    app: wordpress
+    tier: mysql
+  clusterIP: None
+---
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: mysql-pv-claim
+  labels:
+    app: wordpress
+spec:
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 20Gi
+---
+apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
+kind: Deployment
+metadata:
+  name: wordpress-mysql
+  labels:
+    app: wordpress
+spec:
+  selector:
+    matchLabels:
+      app: wordpress
+      tier: mysql
+  strategy:
+    type: Recreate
+  template:
+    metadata:
+      labels:
+        app: wordpress
+        tier: mysql
+    spec:
+      containers:
+      - image: mysql:5.6
+        name: mysql
+        env:
+        - name: MYSQL_ROOT_PASSWORD
+          valueFrom:
+            secretKeyRef:
+              name: mysql-pass
+              key: password
+        ports:
+        - containerPort: 3306
+          name: mysql
+        volumeMounts:
+        - name: mysql-persistent-storage
+          mountPath: /var/lib/mysql
+      volumes:
+      - name: mysql-persistent-storage
+        persistentVolumeClaim:
+          claimName: mysql-pv-claim
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Jim Angel	d322ec5958	Merge pull request #23333 from savitharaghunathan/config_update_1_15 Update release-1.15 branch config.toml for release v1.19	2020-08-26 14:53:48 -05:00
Savitha Raghunathan	d680b39fb5	Updated url for 1.18 in config.toml	2020-08-23 15:27:17 -04:00
Savitha Raghunathan	81111d4322	Updated config.toml for release v1.19	2020-08-22 11:21:20 -04:00
Kubernetes Prow Robot	420fbb1d72	Merge pull request #19896 from kbhawkey/netlify-bug-redirects-1.15 update static _redirects, release-1.15	2020-04-03 08:53:47 -07:00
Karen Bradshaw	2eb4bb653f	update static _redirects, release-1.15	2020-03-27 11:53:53 -04:00
Vineeth Pothulapati	6a8dcc16de	Update config.toml file as part of 1.18 release. (#19842 ) Signed-off-by: vineeth <vineethpothulapati@outlook.com>	2020-03-26 20:32:23 -07:00
Brian Pursley	d44c2116b2	Change version selector to retain current page when switching versions (#19468 )	2020-03-11 11:29:36 -07:00
Damini Satya	34b9f3ba1b	Update config.toml(release-1.15) for 1.17 (#18027 ) * Update config.toml(release-1.15) for 1.17 * Update config.toml	2019-12-09 16:19:31 -08:00
Zach Corleissen	278548294a	Update Hugo version for 1.15 to 0.57.2 (#16813 )	2019-10-27 12:21:24 -07:00
aimeeu	3258742eda	Cherry pick PR - Fix site build (#16531 ) (#16646 ) The `*.profile` file referenced do not need to be provided in a separate file. Making them separate files is preventing Hugo 0.57.2 from correctly building the site.	2019-10-01 15:53:08 -07:00
Yuk, Yongsu	bb47cbea1b	Updated outdated korean content in `release-1.15` (#16577 )	2019-09-26 17:17:37 -07:00
June Yi	ff769259c7	Sixth Korean l10n work for release-1.15 (#16550 ) * Remove duplicated sentence (+1 squashed commit) (#16265) * Fix links to locate Korean docs (#16289) * Fix typo (#16304) * Modify #16364 and links in korean docs. (#16516) * Updated outdated content in `dev-1.15-ko.6` (#16500) * Modify #16415, #16417 korean docs. (#16501) Co-Authored-By: 한지승 <jinh574@naver.com> Co-Authored-By: June Yi <gochist@gmail.com>	2019-09-26 06:59:16 -07:00
simplytunde	d7de46dec8	Tune feature-gates table (#16389 ) (#16410 ) This PR separates the graduated/deprecated feature gates into a separate table. When updating the table contents by browsing the source code, we also found some missing items which are added in this PR as well. (cherry picked from commit `faae88f478`)	2019-09-23 00:31:23 -07:00
M00nF1sh	d885aec73a	promote AWS-NLB Support from alpha to beta (#14451 ) (#16459 ) (#16483 )	2019-09-22 20:23:23 -07:00
成臣 Chengchen	13fa2cf8b0	1. Add _index file to cooncepts root, containers, extend-kubernetes, overview, policy and services-networking folders. (#16494 ) 2. Fix up containers, extend-kubernetes, overview, policy and services-networking files. Add the lost files and sync them with en version documents.	2019-09-22 02:51:22 -07:00
成臣 Chengchen	c87a30450a	Merge release 1.14 into 1.15. (#16439 ) 1. Confirm the document content is similar as en version. 2. Merge the zh release-1.14 version into 1.15 version 3. add the 1.14 all sample into 1.15 for template work. The build looks fine. - docs - concepts - architecture	2019-09-19 06:07:01 -07:00
simplytunde	7c47a2e7c4	Merge pull request #16312 from simplytunde/toml-1.15 Update config.toml(release-1.15) for 1.16	2019-09-18 18:18:53 -05:00
simplytunde	c903edba3e	Merge pull request #16418 from simplytunde/merged-master-release-1.15 Merged master into release 1.15 before release	2019-09-18 08:07:28 -05:00
simplytunde	9eab5297c2	Merge remote-tracking branch 'upstream/master' into merged-master-release-1.15	2019-09-17 22:13:07 -05:00
simplytunde	543c8a4c8b	Add instructions for switching to iptables-legacy (#16271 ) (#16369 ) (cherry picked from commit `9cdaf4ead1`)	2019-09-16 08:52:38 -07:00
fang duan	be8c86a0e5	localization: logging architecture (#16239 ) * Translate logging architecture * Add origin english doc * FIX missing content * Fix missing content * Fix missing content * Update content/zh/docs/concepts/cluster-administration/logging.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/zh/docs/concepts/cluster-administration/logging.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/zh/docs/concepts/cluster-administration/logging.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/zh/docs/concepts/cluster-administration/logging.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/zh/docs/concepts/cluster-administration/logging.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/zh/docs/concepts/cluster-administration/logging.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Leave sidebar untranslated	2019-09-15 05:56:38 -07:00
Tunde Oladipupo	73b9853fcb	Update config.toml(release-1.15) for 1.16	2019-09-13 01:24:55 -06:00
Kubernetes Prow Robot	3120d4f413	Merge pull request #16224 from simplytunde/merged-master-release-1.15 Merged master into release 1.15	2019-09-12 08:58:29 -07:00
Tunde Oladipupo	90bfdbb69b	Merge remote-tracking branch 'upstream/master' into merged-master-release-1.15	2019-09-12 01:51:28 -06:00
simplytunde	1c1b953870	Merge remote-tracking branch 'upstream/master' into merged-master-release-1.15	2019-09-09 07:49:39 -05:00
simplytunde	2ece69220a	Merge remote-tracking branch 'upstream/master' into merged-master-release-1.15	2019-09-05 03:09:26 -05:00
Kubernetes Prow Robot	cdb9642bb9	Merge pull request #16038 from simplytunde/merged-master-release-1.15 Merged master into release 1.15	2019-08-27 00:46:41 -07:00
simplytunde	b847e3b623	Merge remote-tracking branch 'upstream/master' into merged-master-release-1.15	2019-08-23 12:37:53 -05:00
simplytunde	8c769cc0b6	Merge pull request #15822 from simplytunde/release-1.15-merge-master Merge Master into release-1.15	2019-08-17 17:01:37 -05:00
simplytunde	ca4ae505d6	Merge remote-tracking branch 'upstream/master' into HEAD	2019-08-12 08:01:07 -05:00
Kubernetes Prow Robot	37b17d92dd	Merge pull request #15680 from simplytunde/release-1.15-merge-master Release 1.15 merge master	2019-08-05 16:03:50 -07:00
simplytunde	ca31485991	Merge remote-tracking branch 'upstream/master' into HEAD	2019-08-05 17:51:08 -05:00
MAKOSCAFEE	e30e6f5389	initial commit	2019-06-21 00:36:17 +03:00