Update config.toml(release-1.17) for 1.17 (#18031 )

Update for v1.17 (#18034 )
Reference Documentation for kubectl Commands for 1.17 (#18017 )
2019-12-09 16:01:31 -08:00 · 2019-12-09 15:14:40 -08:00 · 2019-12-09 15:12:40 -08:00 · 2019-12-09 12:58:03 -08:00 · 2019-12-09 12:44:04 -08:00 · 2019-12-06 17:48:50 -05:00
30 changed files with 246 additions and 1001 deletions
@@ -19,18 +19,13 @@ aliases:
  sig-docs-blog-owners: # Approvers for blog content
    - castrojo
    - kbarnard10
-    - onlydole
    - zacharysarah
-    - mrbobbytables
  sig-docs-blog-reviewers: # Reviewers for blog content
-    - castrojo
    - cody-clark
-    - kbarnard10
    - mrbobbytables
    - onlydole
    - parispittman
    - vonguard
-    - onlydole
  sig-docs-de-owners: # Admins for German content
    - bene2k1
    - mkorbi
@@ -75,16 +75,16 @@ Within just a few commands, data scientists and software engineers can now creat
 # Community Contributions
 It’d be impossible to have gotten where we are without enormous help from everyone in the community. Some specific contributions that we want to highlight include:

-* [Argo](https://github.com/kubeflow/kubeflow/tree/v0.7.0/kubeflow/argo) for managing ML workflows
+* [Argo](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/argo) for managing ML workflows
 * [Caffe2 Operator](https://github.com/kubeflow/caffe2-operator) for running Caffe2 jobs
 * [Horovod & OpenMPI](https://github.com/kubeflow/kubeflow/tree/master/components/openmpi-controller) for improved distributed training performance of TensorFlow
 * [Identity Aware Proxy](https://github.com/kubeflow/kubeflow/blob/master/docs/gke/iap_request.py), which enables using security your services with identities, rather than VPNs and Firewalls
 * [Katib](https://github.com/kubeflow/katib) for hyperparameter tuning
 * [Kubernetes volume controller](https://github.com/kubeflow/experimental-kvc) which provides basic volume and data management using volumes and volume sources in a Kubernetes cluster.
 * [Kubebench](https://github.com/kubeflow/kubebench) for benchmarking of HW and ML stacks
-* [Pachyderm](https://github.com/kubeflow/kubeflow/tree/v0.7.0/kubeflow/pachyderm) for managing complex data pipelines
+* [Pachyderm](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/pachyderm) for managing complex data pipelines
 * [PyTorch operator](https://github.com/kubeflow/pytorch-operator) for running PyTorch jobs
-* [Seldon Core](https://github.com/kubeflow/kubeflow/tree/v0.7.0/kubeflow/seldon) for running complex model deployments and non-TensorFlow serving
+* [Seldon Core](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/seldon) for running complex model deployments and non-TensorFlow serving

 It’s difficult to overstate how much the community has helped bring all these projects (and more) to fruition. Just a few of the contributing companies include: Alibaba Cloud, Ant Financial, Caicloud, Canonical, Cisco, Datawire, Dell, GitHub, Google, Heptio, Huawei, Intel, Microsoft, Momenta, One Convergence, Pachyderm, Project Jupyter, Red Hat, Seldon, Uber and Weaveworks.

@@ -93,7 +93,7 @@ It’s difficult to overstate how much the community has helped bring all these
 If you’d like to try out Kubeflow, we have a number of options for you:

 1. You can use sample walkthroughs hosted on [Katacoda](https://www.katacoda.com/kubeflow)
-2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [GitHub Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/v0.5.1/agents).
+2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [GitHub Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
 3. You can start a cluster on your own and try your own model. Any Kubernetes conformant cluster will support Kubeflow including those from contributors [Caicloud](https://www.prnewswire.com/news-releases/caicloud-releases-its-kubernetes-based-cluster-as-a-service-product-claas-20-and-the-first-tensorflow-as-a-service-taas-11-while-closing-6m-series-a-funding-300418071.html), [Canonical](https://jujucharms.com/canonical-kubernetes/), [Google](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster), [Heptio](https://heptio.com/products/kubernetes-subscription/), [Mesosphere](https://github.com/mesosphere/dcos-kubernetes-quickstart), [Microsoft](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough), [IBM](https://cloud.ibm.com/docs/containers?topic=containers-cs_cluster_tutorial#cs_cluster_tutorial), [Red Hat/Openshift ](https://docs.openshift.com/container-platform/3.3/install_config/install/quick_install.html#install-config-install-quick-install)and [Weaveworks](https://www.weave.works/product/cloud/).

 There were also a number of sessions at KubeCon + CloudNativeCon  EU 2018 covering Kubeflow. The links to the talks are here; the associated videos will be posted in the coming days. 
@@ -1,162 +0,0 @@
---
-layout: blog
-title: "Kubernetes 1.17 Feature: Kubernetes In-Tree to CSI Volume Migration Moves to Beta"
-date: 2019-12-09T09:00:00+08:00
-slug: kubernetes-1-17-feature-csi-migration-beta
---
-
-**Authors:** David Zhu, Software Engineer, Google
-
-The Kubernetes in-tree storage plugin to [Container Storage Interface (CSI)](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) migration infrastructure is now beta in Kubernetes v1.17. CSI migration was introduced as alpha in Kubernetes v1.14.
-
-Kubernetes features are generally introduced as alpha and moved to beta (and eventually to stable/GA) over subsequent Kubernetes releases. This process allows Kubernetes developers to get feedback, discover and fix issues, iterate on the designs, and deliver high quality, production grade features.
-
-## Why are we migrating in-tree plugins to CSI?
-
-Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.
-
-As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.
-
-## What is CSI migration?
-
-The CSI migration effort enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding [CSI driver](https://kubernetes-csi.github.io/docs/introduction.html). If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
-
-When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
-
-The Kubernetes team has worked hard to ensure the stability of storage APIs and for the promise of a smooth upgrade experience. This involves meticulous accounting of all existing features and behaviors to ensure backwards compatibility and API stability. You can think of it like changing the wheels on a racecar while it’s speeding down the straightaway.
-
-## How to try out CSI migration for existing plugins?
-
-If you are Kubernetes distributor that deploys in one of the environments listed below, now would be a good time to start testing the CSI migration and figuring out how to deploy/manage the appropriate CSI driver.
-
-To try out CSI migration in beta for an existing plugin you must be using Kubernetes v1.17 or higher. First, you must update/create a Kubernetes cluster with the feature flags `CSIMigration` (on by default in 1.17) and `CSIMigration{provider}` (off by default) enabled on the `kube-apiserver`, `kube-controller-manager`, as well as the `kubelet`’s. Where {provider} is the in-tree cloud provider storage type that is used in your cluster.
-
-You must also install the requisite CSI driver on your cluster - instructions for this can generally be found from you provider of choice. CSI migration is available for GCE Persistent Disk and AWS Elastic Block Store in beta as well as for Azure Ffile/Ddisk and Openstack/Cinder in alpha. Kubernetes distributors should look at automating the deployment and management (upgrade, downgrade, etc.) of the CSI Drivers they will depend on.
-
-To verify the feature flag is enabled and driver installed on a particular node you can get the CSINode object. You should see the in-tree plugin name of the migrated plugin as well as your driver in the drivers list.
-
-```shell
-kubectl get csinodes -o yaml
-```
-
-```yaml
- apiVersion: storage.k8s.io/v1
-  kind: CSINode
-  metadata:
-    annotations:
-      storage.alpha.kubernetes.io/migrated-plugins: kubernetes.io/gce-pd
-    name: test-node
-    ...
-  spec:
-    drivers:
-      name: pd.csi.storage.gke.io
-      ...
-```
-
-After the above set up is complete you can confirm that your cluster has functioning CSI migration by deploying a stateful workload using the legacy APIs.
-
-```yaml
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: test-disk
-spec:
-  storageClassName: standard
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi
---
-apiVersion: v1
-kind: Pod
-metadata:
-  name: web-server
-spec:
-  containers:
-   - name: web-server
-     image: nginx
-     volumeMounts:
-       - mountPath: /var/lib/www/html
-         name: mypvc
-  volumes:
-   - name: mypvc
-     persistentVolumeClaim:
-       claimName: test-disk
-```
-
-Verify that the pod is RUNNING after some time
-
-```shell
-kubectl get pods web-server
-```
-
-```shell
-NAME         READY   STATUS    RESTARTS   AGE
-web-server   1/1     Running   0          39s
-```
-
-To confirm that the CSI driver is actually serving your requests it may be prudent to check the container logs of the CSI Driver after exercising the storage management operations. Note that your container logs may look different depending on the provider used.
-
-```shell
-kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}
-```
-
-```shell
-/csi.v1.Controller/ControllerPublishVolume called with request: ...
-Attaching disk ... to ...
-ControllerPublishVolume succeeded for disk ... to instance ...
-```
-
-## Current limitations
-
-Although CSI migration is now beta there is one major limitation that prevents us from turning it on by default. Turning on migration still requires a cluster administrator to install a CSI driver before storage functionality is seamlessly handed over. We are currently working with SIGsig-cloudprovider to provide a frictionless experience of bundling the required CSI Drivers with cloud distributions.
-
-## What is the timeline/status?
-
-The timeline for CSI migration is actually set by the cloud provider extraction project. It is part of the effort to remove all cloud provider code from Kubernetes. By migrating cloud storage plugins to external CSI drivers we are able to extract out all the cloud provider dependencies.
-
-Although the overall feature is beta and not on by default, there is still work to be done on a per-plugin basis. Currently only GCE PD and AWS EBS have gone beta with Migration and yet both are still off by default since they depend on a manual installation of their respective CSI Drivers. Azure File/Disk, OpenStack, and VMWare plugins are currently in less mature states and non-cloud plugins such as NFS, Portworx, RBD etc are still in the planning stages.
-
-The current and targeted releases for each individual cloud driver is shown in the table below:
-
-| Driver            | Alpha         | Beta (in-tree deprecated) | GA            | Target "in-tree plugin" removal |
-| ----------------- | ------------- | ------------------------- | ------------- | ------------------------------- |
-| AWS EBS           | 1.14          | 1.17                      | 1.19 (Target) | 1.21                            |
-| GCE PD            | 1.14          | 1.17                      | 1.19 (Target) | 1.21                            |
-| OpenStack Cinder  | 1.14          | 1.18 (Target)             | 1.19 (Target) | 1.21                            |
-| Azure Disk + File | 1.15          | 1.18 (Target)             | 1.19 (Target) | 1.21                            |
-| VSphere           | 1.18 (Target) | 1.19 (Target)             | 1.20 (Target) | 1.22                            |
-
-## What's next?
-
-Major upcoming work includes implementing and hardening CSI migration for the remaining in-tree plugins, installing CSI Drivers by default in distributions, turning on CSI migration by default, and finally removing all in-tree plugin code as a part of cloud provider extraction. We expect to complete this project including the full switch to “on-by-default” migration by Kubernetes v1.21.
-
-## What should I do as a user?
-
-Note that all new features for the Kubernetes storage system (like volume snapshotting) will only be added to the CSI interface. Therefore, if you are starting up a new cluster, creating stateful applications for the first time, or require these new features we recommend using CSI drivers natively (instead of the in-tree volume plugin API). Follow the [updated user guides for CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) and use the new CSI APIs.
-
-However, if you choose to roll a cluster forward or continue using specifications with the legacy volume APIs, CSI Migration will ensure we continue to support those deployments with the new CSI drivers.
-
-## How do I get involved?
-
-The Kubernetes Slack channel csi-migration along with any of the standard [SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and migration working group teams.
-
-This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. We offer a huge thank you to the contributors who stepped up these last quarters to help the project reach Beta:
-
- David Zhu
- Deep Debroy
- Cheng Pan
- Jan Šafránek
-
-With special thanks to:
-
- Michelle Au
- Saad Ali
- Jonathan Basseri
- Fabio Bertinatto
- Ben Elder
- Andrew Sy Kim
- Hemant Kumar
-
-For fruitful dialogues, insightful reviews, and thorough consideration of CSI migration in other features.
@@ -1,129 +0,0 @@
---
-layout: blog
-title: "Kubernetes 1.17: Stability"
-date: 2019-12-09T13:00:00-08:00
-slug: kubernetes-1-17-release-announcement
---
-
-**Authors:** [Kubernetes 1.17 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md)
-
-We’re pleased to announce the delivery of Kubernetes 1.17, our fourth and final release of 2019! Kubernetes v1.17 consists of 22 enhancements: 14 enhancements have graduated to stable, 4 enhancements are moving to beta, and 4 enhancements are entering alpha.
-
-## Major Themes
-
-### Cloud Provider Labels reach General Availability
-
-Added as a beta feature way back in v1.2, v1.17 sees the general availability of cloud provider labels.
-
-### Volume Snapshot Moves to Beta
-
-The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced as alpha in Kubernetes v1.12, with a second alpha with breaking changes in Kubernetes v1.13.
-
-### CSI Migration Beta
-
-The Kubernetes in-tree storage plugin to Container Storage Interface (CSI) migration infrastructure is now beta in Kubernetes v1.17. CSI migration was introduced as alpha in Kubernetes v1.14.
-
-## Cloud Provider Labels reach General Availability
-
-When nodes and volumes are created, a set of standard labels are applied based on the underlying cloud provider of the Kubernetes cluster. Nodes get a label for the instance type. Both nodes and volumes get two labels describing the location of the resource in the cloud provider topology, usually organized in zones and regions.
-
-Standard labels are used by Kubernetes components to support some features. For example, the scheduler would ensure that pods are placed on the same zone as the volumes they claim; and when scheduling pods belonging to a deployment, the scheduler would prioritize spreading them across zones. You can also use the labels in your pod specs to configure things as such node affinity. Standard labels allow you to write pod specs that are portable among different cloud providers.
-
-The labels are reaching general availability in this release. Kubernetes components have been updated to populate the GA and beta labels and to react to both. However, if you are using the beta labels in your pod specs for features such as node affinity, or in your custom controllers, we recommend that you start migrating them to the new GA labels. You can find the documentation for the new labels here:
-
- [node.kubernetes.io/instance-type](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
- [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion)
- [topology.kubernetes.io/zone](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-
-## Volume Snapshot Moves to Beta
-
-The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced as alpha in Kubernetes v1.12, with a second alpha with breaking changes in Kubernetes v1.13.  This post summarizes the changes in the beta release.
-
-### What is a Volume Snapshot?
-
-Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block Storage, and many on-premise storage systems) provide the ability to create a “snapshot” of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore an existing volume to a previous state (represented by the snapshot).
-
-### Why add Volume Snapshots to Kubernetes?
-
-The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
-
-Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
-
-The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
-
-By providing a standard way to trigger snapshot operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations).
-
-Instead, Kubernetes users are now empowered to incorporate snapshot operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
-
-Additionally these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
-
-You can read more in the blog entry about [releasing CSI volume snapshots to beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-cis-volume-snapshot-beta/).
-
-## CSI Migration Beta
-
-### Why are we migrating in-tree plugins to CSI?
-
-Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.
-
-As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.
-What is CSI migration?
-
-The CSI migration effort enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding CSI driver. If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
-
-When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
-
-The Kubernetes team has worked hard to ensure the stability of storage APIs and for the promise of a smooth upgrade experience. This involves meticulous accounting of all existing features and behaviors to ensure backwards compatibility and API stability. You can think of it like changing the wheels on a racecar while it’s speeding down the straightaway.
-
-You can read more in the blog entry about [CSI migration going to beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/).
-
-## Other Updates
-
-### Graduated to Stable 💯
-
- [Taint Node by Condition](https://github.com/kubernetes/enhancements/issues/382)
- [Configurable Pod Process Namespace Sharing](https://github.com/kubernetes/enhancements/issues/495)
- [Schedule DaemonSet Pods by kube-scheduler](https://github.com/kubernetes/enhancements/issues/548)
- [Dynamic Maximum Volume Count](https://github.com/kubernetes/enhancements/issues/554)
- [Kubernetes CSI Topology Support](https://github.com/kubernetes/enhancements/issues/557)
- [Provide Environment Variables Expansion in SubPath Mount](https://github.com/kubernetes/enhancements/issues/559)
- [Defaulting of Custom Resources](https://github.com/kubernetes/enhancements/issues/575)
- [Move Frequent Kubelet Heartbeats To Lease Api](https://github.com/kubernetes/enhancements/issues/589)
- [Break Apart The Kubernetes Test Tarball](https://github.com/kubernetes/enhancements/issues/714)
- [Add Watch Bookmarks Support](https://github.com/kubernetes/enhancements/issues/956)
- [Behavior-Driven Conformance Testing](https://github.com/kubernetes/enhancements/issues/960)
- [Finalizer Protection For Service Loadbalancers](https://github.com/kubernetes/enhancements/issues/980)
- [Avoid Serializing The Same Object Independently For Every Watcher](https://github.com/kubernetes/enhancements/issues/1152)
-
-### Major Changes
-
- [Add IPv4/IPv6 Dual Stack Support](https://github.com/kubernetes/enhancements/issues/563)
-
-### Other Notable Features
-
- [Topology Aware Routing of Services (Alpha)](https://github.com/kubernetes/enhancements/issues/536)
- [RunAsUserName for Windows](https://github.com/kubernetes/enhancements/issues/1043)
-
-### Availability
-
-Kubernetes 1.17 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.17.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/). You can also easily install 1.17 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/).
-
-### Release Team
-
-This release is made possible through the efforts of hundreds of individuals who contributed both technical and non-technical content. Special thanks to the [release team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md) led by Guinevere Saenger. The 35 individuals on the release team coordinated many aspects of the release, from documentation to testing, validation, and feature completeness.
-
-As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid pace. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. Kubernetes has had over [39,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 66,000 people.
-
-
-### Webinar
-
-Join members of the Kubernetes 1.17 release team on Jan 7th, 2020 to learn about the major features in this release. Register [here](https://zoom.us/webinar/register/9315759188139/WN_kPOZA_6RTjeGdXTG7YFO3A).
-
-### Get Involved
-
-The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support.
-
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
- Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
- Join the community on [Slack](http://slack.k8s.io/)
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
@@ -1,452 +0,0 @@
---
-layout: blog
-title: "Kubernetes 1.17 Feature: Kubernetes Volume Snapshot Moves to Beta"
-date: 2019-12-09T10:00:00-08:00
-slug: kubernetes-1-17-feature-cis-volume-snapshot-beta
---
-
-**Authors:** Xing Yang, VMware & Xiangqian Yu, Google
-
-The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced [as alpha](https://kubernetes.io/blog/2018/10/09/introducing-volume-snapshot-alpha-for-kubernetes/) in Kubernetes v1.12, with a [second alpha](https://kubernetes.io/blog/2019/01/17/update-on-volume-snapshot-alpha-for-kubernetes/) with breaking changes in Kubernetes v1.13.  This post summarizes the changes in the beta release.
-
-## What is a Volume Snapshot?
-
-Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block Storage, and many on-premise storage systems) provide the ability to create a “snapshot” of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore an existing volume to a previous state (represented by the snapshot).
-
-## Why add Volume Snapshots to Kubernetes?
-
-The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
-
-Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
-
-The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
-
-By providing a standard way to trigger snapshot operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations).
-
-Instead, Kubernetes users are now empowered to incorporate snapshot operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
-
-Additionally these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
-
-## What’s new in Beta?
-
-With the promotion of Volume Snapshot to beta, the feature is now enabled by default on standard Kubernetes deployments instead of being opt-in.
-
-The move of the Kubernetes Volume Snapshot feature to beta also means:
-
- A revamp of volume snapshot APIs.
- The CSI external-snapshotter sidecar is split into two controllers, a common snapshot controller and a CSI external-snapshotter sidecar.
- Deletion secret is added as an annotation to the volume snapshot content.
- A new finalizer is added to the volume snapshot API object to prevent it from being deleted when it is bound to a volume snapshot content API object.
-
-## Kubernetes Volume Snapshots Requirements
-
-As mentioned above, with the promotion of Volume Snapshot to beta, the feature is now enabled by default on standard Kubernetes deployments instead of being opt-in.
-
-In order to use the Kubernetes Volume Snapshot feature, you must ensure the following components have been deployed on your Kubernetes cluster:
-
- [Kubernetes Volume Snapshot CRDs](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
- [Volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller)
- CSI Driver supporting Kubernetes volume snapshot beta
-
-See the deployment section below for details.
-
-## Which drivers support Kubernetes Volume Snapshots?
-
-Kubernetes supports three types of volume plugins: in-tree, Flex, and CSI. See [Kubernetes Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for details.
-
-Snapshots are only supported for CSI drivers (not for in-tree or Flex). To use the Kubernetes snapshots feature, ensure that a CSI Driver that implements snapshots is deployed on your cluster.
-
-Read the “[Container Storage Interface (CSI) for Kubernetes GA](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/)” blog post to learn more about CSI and how to deploy CSI drivers.
-
-As of the publishing of this blog, the following CSI drivers have been updated to support volume snapshots beta:
-
- [GCE Persistent Disk CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)
- [Portworx CSI Driver](https://github.com/libopenstorage/openstorage/tree/master/csi)
- [NetApp Trident CSI Driver](https://github.com/NetApp/trident)
-
-Beta level Volume Snapshot support for other [CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) is pending, and should be available soon.
-
-## Kubernetes Volume Snapshot Beta API
-
-A number of changes were made to the Kubernetes volume snapshot API between alpha to beta. These changes are not backward compatible. The purpose of these changes was to make API definitions clear and easier to use.
-
-The following changes are made:
-
- `DeletionPolicy` is now a required field rather than optional in both `VolumeSnapshotClass` and `VolumeSnapshotContent`. This way the user has to explicitly specify it, leaving no room for confusion.
- `VolumeSnapshotSpec` has a new required `Source` field. `Source` may be either a `PersistentVolumeClaimName` (if dynamically provisioning a snapshot) or `VolumeSnapshotContentName` (if pre-provisioning a snapshot).
- `VolumeSnapshotContentSpec` also has a new required `Source` field. This `Source` may be either a `VolumeHandle` (if dynamically provisioning a snapshot) or a `SnapshotHandle` (if pre-provisioning volume snapshots).
- `VolumeSnapshotStatus` now contains a `BoundVolumeSnapshotContentName` to indicate the `VolumeSnapshot` object is bound to a `VolumeSnapshotContent`.
- `VolumeSnapshotContent`now contains a `Status` to indicate the current state of the content. It has a field `SnapshotHandle` to indicate that the `VolumeSnapshotContent` represents a snapshot on the storage system.
-
-The beta Kubernetes VolumeSnapshot API object:
-
-```go
-type VolumeSnapshot struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Spec VolumeSnapshotSpec
-        Status *VolumeSnapshotStatus
-}
-```
-
-```go
-type VolumeSnapshotSpec struct {
-	Source VolumeSnapshotSource
-	VolumeSnapshotClassName *string
-}
-// Exactly one of its members MUST be specified
-type VolumeSnapshotSource struct {
-	// +optional
-	PersistentVolumeClaimName *string
-	// +optional
-	VolumeSnapshotContentName *string
-}
-```
-
-```go
-type VolumeSnapshotStatus struct {
-	BoundVolumeSnapshotContentName *string
-	CreationTime *metav1.Time
-	ReadyToUse *bool
-	RestoreSize *resource.Quantity
-	Error *VolumeSnapshotError
-}
-```
-
-
-The beta Kubernetes VolumeSnapshotContent API object:
-
-```go
-type VolumeSnapshotContent struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Spec VolumeSnapshotContentSpec
-        Status *VolumeSnapshotContentStatus
-}
-```
-
-```go
-type VolumeSnapshotContentSpec struct {
-         VolumeSnapshotRef core_v1.ObjectReference
-         Source VolumeSnapshotContentSource
-         DeletionPolicy DeletionPolicy
-         Driver string
-         VolumeSnapshotClassName *string
-}
-```
-
-```go
-type VolumeSnapshotContentSource struct {
-	// +optional
-	VolumeHandle *string
-	// +optional
-	SnapshotHandle *string
-}
-```
-
-```go
-type VolumeSnapshotContentStatus struct {
-	CreationTime *int64
-	ReadyToUse *bool
-	RestoreSize *int64
-	Error *VolumeSnapshotError
-           SnapshotHandle *string
-}
-```
-
-The beta Kubernetes VolumeSnapshotClass API object:
-
-```go
-type VolumeSnapshotClass struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Driver string
-        Parameters map[string]string
-        DeletionPolicy DeletionPolicy
-}
-```
-
-### How do I deploy support for Volume Snapshots on my Kubernetes Cluster?
-
-Please note that the Volume Snapshot feature now depends on a new, common [volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller) in addition to the volume snapshot CRDs. Both the volume snapshot controller and the CRDs are independent of any CSI driver. Regardless of the number CSI drivers deployed on the cluster, there must be only one instance of the volume snapshot controller running and one set of volume snapshot CRDs installed per cluster.
-
-Therefore, it is strongly recommended that Kubernetes distributors bundle and deploy the controller and CRDs as part of their Kubernetes cluster management process (independent of any CSI Driver).
-
-If your cluster does not come pre-installed with the correct components, you may manually install these components by executing the following steps.
-
-#### Install Snapshot Beta CRDs
-
- `kubectl create -f config/crd`
- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
- Do this once per cluster
-
-
-#### Install Common Snapshot Controller
-
- `kubectl create -f deploy/kubernetes/snapshot-controller`
- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller)
- Do this once per cluster
-
-#### Install CSI Driver
-
-Follow instructions provided by your CSI Driver vendor.
-
-### How do I use Kubernetes Volume Snapshots?
-
-Assuming all the required components (including CSI driver) are already deployed and running on your cluster, you can create volume snapshots using the VolumeSnapshot API object, and restore them by specifying a VolumeSnapshot data source on a PVC.
-
-#### Creating a New Volume Snapshot with Kubernetes
-
-You can enable creation/deletion of volume snapshots in a Kubernetes cluster, by creating a VolumeSnapshotClass API object pointing to a CSI Driver that support volume snapshots.
-
-The following VolumeSnapshotClass, for example, tells the Kubernetes cluster that a CSI driver, `testdriver.csi.k8s.io`, can handle volume snapshots, and that when these snapshots are created, their deletion policy should be to delete.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshotClass
-metadata:
-  name: test-snapclass
-driver: testdriver.csi.k8s.io
-deletionPolicy: Delete
-parameters:
-  csi.storage.k8s.io/snapshotter-secret-name: mysecret
-  csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace
-```
-
-The common snapshot controller reserves the parameter keys `csi.storage.k8s.io/snapshotter-secret-name` and `csi.storage.k8s.io/snapshotter-secret-namespace`. If specified, it fetches the referenced Kubernetes secret and sets it as an annotation on the volume snapshot content object.  The CSI external-snapshotter sidecar retrieves it from the content annotation and passes it to the CSI driver during snapshot creation.
-
-#### Creation of a volume snapshot is triggered by the creation of a VolumeSnapshot API object.
-
-The VolumeSnapshot object must specify the following source type:
-`persistentVolumeClaimName` - The name of the PVC to snapshot. Please note that the source PVC, PV, and VolumeSnapshotClass for a VolumeSnapshot object must point to the same CSI driver.
-
-The following VolumeSnapshot, for example, triggers the creation of a snapshot for a PVC called `test-pvc` using the VolumeSnapshotClass above.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshot
-metadata:
-  name: test-snapshot
-spec:
-  volumeSnapshotClassName: test-snapclass
-  source:
-    persistentVolumeClaimName: test-pvc
-```
-
-When volume snapshot creation is invoked, the common snapshot controller first creates a VolumeSnapshotContent object with the `volumeSnapshotRef`, source `volumeHandle`, `volumeSnapshotClassName` if specified, `driver`, and `deletionPolicy`.
-
-The CSI external-snapshotter sidecar then passes the VolumeSnapshotClass parameters, the source volume ID, and any referenced secret(s) to the CSI driver (in this case `testdriver.csi.k8s.io`) via a CSI `CreateSnapshot` call. In response, the CSI driver creates a new snapshot for the specified volume, and returns the ID for that snapshot. The CSI external-snapshotter sidecar then updates the `snapshotHandle`, `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshotContent object that represents the new snapshot. For a storage system that needs to upload the snapshot after it is being cut, the CSI external-snapshotter sidecar will keep calling the CSI `CreateSnapshot` to check the status until upload is complete and `readyToUse` is true.
-
-The common snapshot controller binds the VolumeSnapshotContent object to the VolumeSnapshot (sets `BoundVolumeSnapshotContentName`), updating the `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshot object based on the status field of the VolumeSnapshotContent object.
-
-If no `volumeSnapshotClassName` is specified, one is automatically selected as follows:
-The `StorageClass` from PVC or PV of the source volume is fetched.
-The default VolumeSnapshotClass is fetched, if available. A default VolumeSnapshotClass is a snapshot class created by the admin with the `snapshot.storage.kubernetes.io/is-default-class` annotation. If the `Driver` field of the default VolumeSnapshotClass is the same as the `Provisioner` field in the StorageClass, the default VolumeSnapshotClass is used. If there is no default VolumeSnapshotClass or more than one default VolumeSnapshotClass for a snapshot, an error will be returned.
-
-Please note that the Kubernetes Snapshot API does not provide any consistency guarantees. You have to prepare your application (pause application, freeze filesystem etc.) before taking the snapshot for data consistency either manually or using some other higher level APIs/controllers.
-
-You can verify that the VolumeSnapshot object is created and bound with VolumeSnapshotContent by running `kubectl describe volumesnapshot`:
-
-`Bound Volume Snapshot Content Name` - field in the `Status` indicates indicates the volume is bound to the specified VolumeSnapshotContent.
-`Ready To Use` - field in the `Status` indicates this volume snapshot is ready for use.
-`Creation Time` - field in the `Status` indicates when the snapshot was actually created (cut).
-`Restore Size` - field in the `Status` indicates the minimum volume size required when restoring a volume from this snapshot.
-
-```
-Name:         test-snapshot
-Namespace:    default
-Labels:       <none>
-Annotations:  <none>
-API Version:  snapshot.storage.k8s.io/v1beta1
-Kind:         VolumeSnapshot
-Metadata:
-  Creation Timestamp:  2019-11-16T00:36:04Z
-  Finalizers:
-    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
-    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
-  Generation:        1
-  Resource Version:  1294
-  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/new-snapshot-demo
-  UID:               32ceaa2a-3802-4edd-a808-58c4f1bd7869
-Spec:
-  Source:
-    Persistent Volume Claim Name:  test-pvc
-  Volume Snapshot Class Name:      test-snapclass
-Status:
-  Bound Volume Snapshot Content Name:  snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
-  Creation Time:                       2019-11-16T00:36:04Z
-  Ready To Use:                        true
-  Restore Size:                        1Gi
-```
-
-As a reminder to any developers building controllers using volume snapshot APIs: before using a VolumeSnapshot API object, validate the bi-directional binding between the VolumeSnpashot and the VolumeSnapshotContent it is bound to, to ensure the binding is complete and correct (not doing so may result in security issues).
-
-```shell
-kubectl describe volumesnapshotcontent
-```
-
-```
-Name:         snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
-Namespace:
-Labels:       <none>
-Annotations:  <none>
-API Version:  snapshot.storage.k8s.io/v1beta1
-Kind:         VolumeSnapshotContent
-Metadata:
-  Creation Timestamp:  2019-11-16T00:36:04Z
-  Finalizers:
-    snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection
-  Generation:        1
-  Resource Version:  1292
-  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/volumesnapshotcontents/snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
-  UID:               7dfdf22e-0b0c-4b71-9ddf-2f1612ca2aed
-Spec:
-  Deletion Policy:  Delete
-  Driver:           testdriver.csi.k8s.io
-  Source:
-    Volume Handle:             d1b34a5f-0808-11ea-808a-0242ac110003
-  Volume Snapshot Class Name:  test-snapclass
-  Volume Snapshot Ref:
-    API Version:       snapshot.storage.k8s.io/v1beta1
-    Kind:              VolumeSnapshot
-    Name:              test-snapshot
-    Namespace:         default
-    Resource Version:  1286
-    UID:               32ceaa2a-3802-4edd-a808-58c4f1bd7869
-Status:
-  Creation Time:    1573864564608810101
-  Ready To Use:     true
-  Restore Size:     1073741824
-  Snapshot Handle:  127c5798-0809-11ea-808a-0242ac110003
-Events:             <none>
-```
-
-#### Importing an existing volume snapshot with Kubernetes
-
-You can always expose a pre-existing volume snapshot in Kubernetes by manually creating a VolumeSnapshotContent object to represent the existing volume snapshot. Because VolumeSnapshotContent is a non-namespace API object, only a cluster admin may have the permission to create it. By specifying the `volumeSnapshotRef` the cluster admin specifies exactly which user can use the snapshot.
-
-The following VolumeSnapshotContent, for example exposes a volume snapshot with the name `7bdd0de3-aaeb-11e8-9aae-0242ac110002` belonging to a CSI driver called `testdriver.csi.k8s.io`.
-
-A VolumeSnapshotContent object should be created by a cluster admin with the following fields to represent an existing snapshot:
-
- `driver` - CSI driver used to handle this volume. This field is required.
- `source` - Snapshot identifying information
- `snapshotHandle` - name/identifier of the snapshot. This field is required.
- `volumeSnapshotRef` - Pointer to the VolumeSnapshot object this content should bind to.
- `name` and `namespace` - Specifies the name and namespace of the VolumeSnapshot object which the content is bound to.
- `deletionPolicy` - Valid values are `Delete` and `Retain`. If the `deletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the - `deletionPolicy` is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshotContent
-metadata:
-  name: manually-created-snapshot-content
-spec:
-  deletionPolicy: Delete
-  driver: testdriver.csi.k8s.io
-  source:
-    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
-  volumeSnapshotRef:
-    name: test-snapshot
-    namespace: default
-```
-
-Once a VolumeSnapshotContent object is created, a user can create a VolumeSnapshot object pointing to the VolumeSnapshotContent object. The name and namespace of the VolumeSnapshot object must match the name/namespace specified in the volumeSnapshotRef of the VolumeSnapshotContent. It specifies the following fields:
-`volumeSnapshotContentName` - name of the volume snapshot content specified above. This field is required.
-`volumeSnapshotClassName` - name of the volume snapshot class. This field is optional.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshot
-metadata:
-  name: manually-created-snapshot
-spec:
-  source:
-        volumeSnapshotContentName: test-content
-```
-
-Once both objects are created, the common snapshot controller verifies the binding between VolumeSnapshot and VolumeSnapshotContent objects is correct and marks the VolumeSnapshot as ready (if the CSI driver supports the `ListSnapshots` call, the controller also validates that the referenced snapshot exists). The CSI external-snapshotter sidecar checks if the snapshot exists if ListSnapshots CSI method is implemented, otherwise it assumes the snapshot exists. The external-snapshotter sidecar sets `readyToUse` to true in the status field of VolumeSnapshotContent. The common snapshot controller marks the snapshot as ready accordingly.
-## Create Volume From Snapshot
-Once you have a bound and ready VolumeSnapshot object, you can use that object to provision a new volume that is pre-populated with data from the snapshot.
-
-To provision a new volume pre-populated with data from a snapshot, use the `dataSource` field in the `PersistentVolumeClaim`. It has three parameters:
-`name` - name of the VolumeSnapshot object representing the snapshot to use as source
-`kind` - must be VolumeSnapshot
-`apiGroup` - must be snapshot.storage.k8s.io
-
-The namespace of the source VolumeSnapshot object is assumed to be the same as the namespace of the `PersistentVolumeClaim` object.
-
-```yaml
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: pvc-restore
-  namespace: demo-namespace
-spec:
-  storageClassName: testdriver.csi.k8s.io
-  dataSource:
-    name: manually-created-snapshot
-    kind: VolumeSnapshot
-    apiGroup: snapshot.storage.k8s.io
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 1Gi
-```
-
-When the `PersistentVolumeClaim` object is created, it will trigger provisioning of a new volume that is pre-populated with data from the specified snapshot.
-As a storage vendor, how do I add support for snapshots to my CSI driver?
-To implement the snapshot feature, a CSI driver MUST add support for additional controller capabilities `CREATE_DELETE_SNAPSHOT` and `LIST_SNAPSHOTS`, and implement additional controller RPCs: `CreateSnapshot`, `DeleteSnapshot`, and `ListSnapshots`. For details, see the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md) and the [Kubernetes-CSI Driver Developer Guide](https://kubernetes-csi.github.io/docs/snapshot-restore-feature.html).
-
-Although Kubernetes is as minimally prescriptive on the packaging and deployment of a CSI Volume Driver as possible, it provides a suggested mechanism for deploying an arbitrary containerized CSI driver on Kubernetes to simplify deployment of containerized CSI compatible volume drivers.
-
-As part of this recommended deployment process, the Kubernetes team provides a number of sidecar (helper) containers, including the [external-snapshotter sidecar](https://kubernetes-csi.github.io/docs/external-snapshotter.html) container.
-
-The external-snapshotter watches the Kubernetes API server for VolumeSnapshotContent object and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint. The CSI [external-provisioner sidecar container](https://kubernetes-csi.github.io/docs/external-provisioner.html) has also been updated to support restoring volume from snapshot using the dataSource PVC field.
-
-In order to support snapshot feature, it is recommended that storage vendors deploy the external-snapshotter sidecar containers in addition to the external provisioner, along with their CSI driver.
-
-## What are the limitations of beta?
-
-The beta implementation of volume snapshots for Kubernetes has the following limitations:
-
- Does not support reverting an existing volume to an earlier state represented by a snapshot (beta only supports provisioning a new volume from a snapshot).
- No snapshot consistency guarantees beyond any guarantees provided by storage system (e.g. crash consistency). These are the responsibility of higher level APIs/controllers
-
-##  What’s next?
-
-Depending on feedback and adoption, the Kubernetes team plans to push the CSI Snapshot implementation to GA in either 1.18 or 1.19. Some of the features we are interested in supporting include consistency groups, application consistent snapshots, workload quiescing, in-place restores, volume backups, and more.
-
-## How can I learn more?
-
-You can also have a look at the [external-snapshotter source code repository](https://github.com/kubernetes-csi/external-snapshotter).
-
-Check out additional documentation on the snapshot feature [here](http://k8s.io/docs/concepts/storage/volume-snapshots) and [here](https://kubernetes-csi.github.io/docs/).
-
-## How do I get involved?
-
-This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together.
-
-We offer a huge thank you to the contributors who stepped up these last few quarters to help the project reach Beta:
-
- Xing Yang (xing-yang)
- Xiangqian Yu (yuxiangqian)
- Jing Xu (jingxu97)
- Grant Griffiths (ggriffiths)
- Can Zhu (zhucan)
-
-With special thanks to the following people for their insightful reviews and thorough consideration with the design:
-
- Michelle Au (msau42)
- Saad Ali (saadali)
- Patrick Ohly (pohly)
- Tim Hockin (thockin)
- Jordan Liggitt (liggitt).
-
-Those interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage). We’re rapidly growing and always welcome new contributors.
-
-We also hold regular [SIG-Storage Snapshot Working Group meetings](https://docs.google.com/document/d/1qdfvAj5O-tTAZzqJyz3B-yczLLxOiQd-XKpJmTEMazs/edit?usp=sharing). New attendees are welcome to join for design and development discussions.
@@ -40,6 +40,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error as well as files</td>
    </tr>

+    <tr>
+      <td colspan="2">--application-metrics-count-limit int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 100</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of application metrics to store (per container)</td>
+    </tr>
+
    <tr>
      <td colspan="2">--as string</td>
    </tr>
@@ -61,6 +68,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td>
    </tr>

+    <tr>
+      <td colspan="2">--boot-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/proc/sys/kernel/random/boot_id"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for boot-id. Use the first one that exists.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "~/.kube/http-cache"</td>
    </tr>
@@ -103,6 +117,27 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The name of the kubeconfig cluster to use</td>
    </tr>

+    <tr>
+      <td colspan="2">--container-hints string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/cadvisor/container_hints.json"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">location of the container hints file</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--containerd string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/run/containerd/containerd.sock"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">containerd endpoint</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--containerd-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "k8s.io"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">containerd namespace</td>
+    </tr>
+
    <tr>
      <td colspan="2">--context string</td>
    </tr>
@@ -124,6 +159,97 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.</td>
    </tr>

+    <tr>
+      <td colspan="2">--disable-root-cgroup-stats</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Disable collecting root Cgroup stats</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "unix:///var/run/docker.sock"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">docker endpoint</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-env-metadata-whitelist string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">a comma-separated list of environment variable keys that needs to be collected for docker containers</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-only</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Only report docker containers in addition to root stats</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-root string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/var/lib/docker"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker)</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">use TLS to connect to docker</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls-ca string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "ca.pem"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">path to trusted CA</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls-cert string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cert.pem"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">path to client certificate</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls-key string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "key.pem"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">path to private key</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--enable-load-reader</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Whether to enable cpu load reader</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--event-storage-age-limit string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "default=0"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--event-storage-event-limit string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "default=0"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--global-housekeeping-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1m0s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between global housekeepings</td>
+    </tr>
+
    <tr>
      <td colspan="2">-h, --help</td>
    </tr>
@@ -131,6 +257,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kubectl</td>
    </tr>

+    <tr>
+      <td colspan="2">--housekeeping-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between container housekeepings</td>
+    </tr>
+
    <tr>
      <td colspan="2">--insecure-skip-tls-verify</td>
    </tr>
@@ -152,6 +285,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">when logging hits line file:N, emit a stack trace</td>
    </tr>

+    <tr>
+      <td colspan="2">--log-cadvisor-usage</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Whether to log the usage of the cAdvisor container</td>
+    </tr>
+
    <tr>
      <td colspan="2">--log-dir string</td>
    </tr>
@@ -187,6 +327,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error instead of files</td>
    </tr>

+    <tr>
+      <td colspan="2">--machine-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/machine-id,/var/lib/dbus/machine-id"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for machine-id. Use the first one that exists.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--match-server-version</td>
    </tr>
@@ -257,6 +404,55 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">logs at or above this threshold go to stderr</td>
    </tr>

+    <tr>
+      <td colspan="2">--storage-driver-buffer-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1m0s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-db string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cadvisor"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database name</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-host string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "localhost:8086"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database host:port</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-password string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "root"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database password</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-secure</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">use secure connection with database</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-table string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stats"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">table name</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-user string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "root"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database username</td>
+    </tr>
+
    <tr>
      <td colspan="2">--token string</td>
    </tr>
@@ -264,6 +460,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Bearer token for authentication to the API server</td>
    </tr>

+    <tr>
+      <td colspan="2">--update-machine-info-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5m0s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between machine info updates.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--user string</td>
    </tr>
@@ -39,7 +39,7 @@ kubeadm upgrade node [flags]
    </tr>

    <tr>
-      <td colspan="2">--etcd-upgrade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+      <td colspan="2">--etcd-upgrade</td>
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Perform the upgrade of etcd.</td>
@@ -32,7 +32,7 @@ kubeadm upgrade node phase control-plane [flags]
    </tr>

    <tr>
-      <td colspan="2">--etcd-upgrade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+      <td colspan="2">--etcd-upgrade</td>
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Perform the upgrade of etcd.</td>
@@ -71,7 +71,7 @@ their authors, not the Kubernetes team.
 | dotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
 | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
 | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
-| Haskell              | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) |
+| Haskell              | [github.com/soundcloud/haskell-kubernetes](https://github.com/soundcloud/haskell-kubernetes) |
 {{% /capture %}}


@@ -53,7 +53,7 @@ Suivez les étapes ci-dessous pour commencer et explorer Minikube.
 2. Vous pouvez maintenant interagir avec votre cluster à l'aide de kubectl.
   Pour plus d'informations, voir [Interagir avec votre cluster.](#interacting-with-your-cluster).

-    Créons un déploiement Kubernetes en utilisant une image existante nommée `echoserver`, qui est un serveur HTTP, et exposez-la sur le port 8080 à l’aide de `--port`.
+    Créons un déploiement Kubernetes en utilisant une image existante nommée `echoserver`, qui est un serveur HTTP, et exposez-la sur le port 8080 à l’aide de` --port`.

    ```shell
    kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
@@ -71,7 +71,7 @@ Suivez les étapes ci-dessous pour commencer et explorer Minikube.
    kubectl expose deployment hello-minikube --type=NodePort --port=8080
    ```

-    L'option `--type=NodePort` spécifie le type du Service.
+    L'option `--type = NodePort` spécifie le type du service.

    Le résultat est similaire à ceci:

@@ -81,27 +81,27 @@ Suivez les étapes ci-dessous pour commencer et explorer Minikube.

 4. Le Pod `hello-minikube` est maintenant lancé, mais vous devez attendre que le Pod soit opérationnel avant d'y accéder via le Service.

-   Vérifiez si le Pod est opérationnel:
+   Vérifiez si le pod est opérationnel:

   ```shell
   kubectl get pod
   ```

-   Si la sortie affiche le `STATUS` comme `ContainerCreating`, le Pod est toujours en cours de création:
+   Si la sortie affiche le `STATUS` comme` ContainerCreating`, le pod est toujours en cours de création:

   ```text
   NAME                              READY     STATUS              RESTARTS   AGE
   hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
   ```

-   Si la sortie indique le statut `STATUS` comme `Running`, le Pod est maintenant opérationnel:
+   Si la sortie indique le statut `STATUS` comme` Running`, le pod est maintenant opérationnel:

   ```text
   NAME                              READY     STATUS    RESTARTS   AGE
   hello-minikube-3383150820-vctvh   1/1       Running   0          13s
   ```

-5. Obtenez l'URL du Service exposé pour afficher les détails du service:
+5. Obtenez l'URL du service exposé pour afficher les détails du service:

   ```shell
   minikube service hello-minikube --url
@@ -200,7 +200,7 @@ Suivez les étapes ci-dessous pour commencer et explorer Minikube.

 La commande `minikube start` peut être utilisée pour démarrer votre cluster.
 Cette commande crée et configure une machine virtuelle qui exécute un cluster Kubernetes à un seul nœud.
-Cette commande configure également [kubectl](/docs/user-guide/kubectl-overview/) pour communiquer avec ce cluster.
+Cette commande configure également [kubectl] (/docs/user-guide/kubectl-overview/) pour communiquer avec ce cluster.

 {{< note >}}
 Si vous êtes derrière un proxy Web, vous devez transmettre ces informations à la commande `minikube start`:
@@ -226,11 +226,11 @@ minikube start --kubernetes-version {{< param "fullversion" >}}

 #### Spécification du pilote de machine virtuelle

-Vous pouvez changer le pilote de machine virtuelle en ajoutant l'indicateur `--vm-driver=<nom_du_pilote>` à `minikube start`.
-Par exemple, la commande serait:
+Vous pouvez changer le pilote de machine virtuelle en ajoutant l'indicateur `--vm-driver = <nom_du_processeur>` à `minikube start`.
+Par exemple, la commande serait.

 ```shell
-minikube start --vm-driver=<nom_du_pilote>
+minikube start --vm-driver=<driver_name>
 ```

 Minikube prend en charge les pilotes suivants:
@@ -410,7 +410,7 @@ minikube dashboard

 ### Services

-Pour accéder à un service exposé via un port de nœud, exécutez cette commande dans un shell après le démarrage de Minikube pour obtenir l'adresse:
+Pour accéder à un service exposé via un port de noeud, exécutez cette commande dans un shell après le démarrage de Minikube pour obtenir l'adresse:

 ```shell
 minikube service [-n NAMESPACE] [--url] NAME
@@ -1,4 +1,7 @@
 ---
+reviewers:
+- bgrant0607
+- mikedanese
 title: Cos'è Kubernetes
 content_template: templates/concept
 weight: 10
@@ -64,7 +67,7 @@ Kubernetes vi permette di montare automaticamente un sistema di archiviazione di
 Kubernetes permette di specificare quanta CPU e memoria (RAM) ha bisogno ogni container. Quando i container dispongono di richieste di risorse specifiche, Kubernetes può prendere decisioni migliori per gestire le risorse per i container.
 * **Auto risoluzione**
 Kubernetes riavvia i container che si bloccano, sostituisce i container, termina i container che non rispondono al controllo di salute definito dall'utente, e non li distribuisce ai clienti finché non sono pronti per funzionare correttamente..
-* **Gestione di informazioni sensibili e della configurazione**
+* **Gestione di informazioni sensibili e della configurazione
 Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi ssh. È possibile distribuire e aggiornare i segreti e la configurazione dell'applicazione senza dover ricostruire le immagini del container e senza rivelare segreti nella configurazione della pila.

 ## Cosa non è Kubernetes
@@ -1,19 +0,0 @@
---
-title: Container
-id: container
-date: 2019-29-11
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
-short_description: >
-  Một image nhẹ, khả chuyển và có khả năng thực thi, chứa phần mềm và tất cả các dependencies của nó.
-
-aka:
-tags:
-  - fundamental
-  - workload
---
-
-Một image nhẹ, khả chuyển và có khả năng thực thi, chứa phần mềm và tất cả các dependencies của nó.
-
-<!--more-->
-
-Containers tách rời các ứng dụng khỏi hạ tầng máy chủ nhằm giúp cho việc triển khai dễ dàng hơn trên từng hệ thống cloud hay hệ điều hành khác nhau, và đơn giản hóa việc nhân rộng.
@@ -1,18 +0,0 @@
---
-title: Container runtime interface (CRI)
-id: cri
-date: 2019-29-11
-full_link: /docs/concepts/overview/components/#container-runtime
-short_description: >
-  Một API phục vụ cho việc tích hợp container runtimes với kubelet.
-
-aka:
-tags:
-  - fundamental
---
-
-Container runetime interface (CRI) là một API phục vụ cho việc tích hợp container runtimes với kubelet trên một node.
-
-<!--more-->
-
-Để biết thêm chi tiết, đọc thêm về [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) API.
@@ -1,20 +0,0 @@
---
-title: Deployment
-id: deployment
-date: 2019-29-11
-full_link: /docs/concepts/workloads/controllers/deployment/
-short_description: >
-  Một API object quản lý việc nhân rộng bản sao của ứng dụng.
-
-aka:
-tags:
-  - fundamental
-  - core-object
-  - workload
---
-
-Một API object quản lý việc nhân rộng bản sao của ứng dụng.
-
-<!--more-->
-
-Mỗi bản sao là một đại diện diện cho một {{< glossary_tooltip term_id="pod" >}}, và các pods này được phân bố giữa các nodes trong cluster.
@@ -1,18 +0,0 @@
---
-title: Docker
-id: docker
-date: 2019-29-11
-full_link: https://docs.docker.com/engine/
-short_description: >
-  Docker là một công nghệ phần mềm thực hiện việc ảo hóa tầng hệ điều hành được gọi là container.
-
-aka:
-tags:
-  - fundamental
---
-
-Docker (cụ thể là Docker Engine) là một công nghệ phần mềm thực hiện việc ảo hóa tầng hệ điều hành, còn được gọi là container.
-
-<!--more-->
-
-Docker sử dụng khả năng cô lập các tài nguyên của Linux kernel như cgroups và kernel namespaces, cùng với một hệ thống tệp tin có khả năng kết hợp như OverlayFS và một vài thành phần khác để các containers có thể chạy độc lập trên cùng một máy Linux, tránh được việc bị overhead khi khởi động và bảo trì máy ảo (VMs).
@@ -1,21 +0,0 @@
---
-title: kube-proxy
-id: kube-proxy
-date: 2019-29-11
-full_link: /docs/reference/command-line-tools-reference/kube-proxy/
-short_description: >
-  `kube-proxy` là một network proxy chạy trên mỗi node trong cluster.
-
-aka:
-tags:
-  - fundamental
-  - networking
---
-
-[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) là một network proxy chạy trên mỗi node trong cluster, thực hiện một phần Kubernetes {{< glossary_tooltip term_id="service">}}.
-
-<!--more-->
-
-kube-proxy duy trình network rules trên các node. Những network rules này cho phép kết nối mạng đến các pods từ trong hoặc ngoài cluster.
-
-Kube-proxy sử dụng lớp packet filtering của hệ điều hành nếu có sẵn. Nếu không thì kube-proxy sẽ tự điều hướng network traffic.
@@ -1,19 +0,0 @@
---
-title: Kubelet
-id: kubelet
-date: 2019-29-11
-full_link: /docs/reference/generated/kubelet
-short_description: >
-  Một agent chạy trên mỗi node nằm trong cluster. Nó giúp đảm bảo rằng các containers đã chạy trong một pod.
-
-aka:
-tags:
-  - fundamental
-  - core-object
---
-
-Một agent chạy trên mỗi node nằm trong cluster. Nó giúp đảm bảo rằng các containers đã chạy trong một pod.
-
-<!--more-->
-
-Kubelet sẽ nhận một tập các PodSpecs (đặc tính của Pod) được cung cấp thông qua các cơ chế khác nhau và bảo đảm rằng containers được mô tả trong những PodSpecs này chạy ổn định và khỏe mạnh. Kubelet không quản lý những containers không được tạo bởi Kubernetes.
@@ -1,18 +0,0 @@
---
-title: Label
-id: label
-date: 2019-29-11
-full_link: /docs/concepts/overview/working-with-objects/labels
-short_description: >
-  Gán nhãn các đối tượng (tags objects) với các thuộc tính xác định, có ý nghĩa và có liên quan tới người dùng.
-
-aka:
-tags:
-  - fundamental
---
-
-Gán nhãn các đối tượng (tags objects) với các thuộc tính xác định, có ý nghĩa và có liên quan tới người dùng.
-
-<!--more-->
-
-Labels là những cặp key/value gắn liền với những đối tượng như {{< glossary_tooltip text="pod" term_id="pod" >}}. Chúng được dùng để tổ chức và chọn lựa giữa những tập hợp con của các đối tượng này.
@@ -1,18 +0,0 @@
---
-title: Node
-id: node
-date: 2019-29-11
-full_link: /docs/concepts/architecture/nodes/
-short_description: >
-  Một node là một máy worker trong Kubernetes
-
-aka:
-tags:
-  - fundamental
---
-
-Một node là một máy worker trong Kubernetes
-
-<!--more-->
-
-Một worker node có thể là một máy tính ảo hay máy tính vậy lý, tùy thuộc vào cluster. Nó bao gồm một số daemons hoặc services cần thiết để chạy các {{< glossary_tooltip text="Pods" term_id="pod" >}} và được quản lý bởi control plane. Daemons trên một node bao gồm {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, và một container runtime triển khai theo {{< glossary_tooltip text="CRI" term_id="cri" >}} như {{< glossary_tooltip term_id="docker" >}}.
@@ -1,19 +0,0 @@
---
-title: Pod
-id: pod
-date: 2019-29-11
-full_link: /docs/concepts/workloads/pods/pod-overview/
-short_description: >
-  Đối tượng nhỏ nhất và đơn giản nhất của Kubernetes. Một Pod đại diện cho một tập các containers đang chạy trên cluster.
-
-aka:
-tags:
-  - core-object
-  - fundamental
---
-
-Đối tượng nhỏ nhất và đơn giản nhất của Kubernetes. Một Pod đại diện cho một tập các {{< glossary_tooltip text="containers" term_id="container" >}} đang chạy trên cluster.
-
-<!--more-->
-
-Một Pod thường được set up để chạy với một container chính yếu. Nó đồng thời có thể chạy kèm với các sidecar containers giúp bổ trợ thêm một số tính năng như thu thập log. Các Pods thường được quản lý bởi một {{< glossary_tooltip term_id="deployment" >}}.
@@ -1,18 +0,0 @@
---
-title: Selector
-id: selector
-date: 2019-29-11
-full_link: /docs/concepts/overview/working-with-objects/labels/
-short_description: >
-  Cho phép người dùng lọc ra một danh sách tài nguyên dựa trên labels (nhãn).
-
-aka:
-tags:
-  - fundamental
---
-
-Cho phép người dùng lọc ra một danh sách tài nguyên dựa trên labels (nhãn).
-
-<!--more-->
-
-Selectors được áp dụng khi truy vấn những danh sách tài nguyên để lọc dựa trên {{< glossary_tooltip text="labels" term_id="label" >}} chúng được đánh.
@@ -1,19 +0,0 @@
---
-title: Service
-id: service
-date: 2019-29-11
-full_link: /docs/concepts/services-networking/service/
-short_description: >
-  Một cách để thể hiện ứng dụng đang chạy trong một tập các Pods dưới dạng dịch vụ mạng.
-
-aka:
-tags:
-  - fundamental
-  - core-object
---
-
-Một cách để thể hiện ứng dụng đang chạy trong một tập các {{< glossary_tooltip text="Pods" term_id="pod" >}} dưới dạng dịch vụ mạng.
-
-<!--more-->
-
-Một tập các Pods được một Service nhắm đến (thường) được xác định với một {{< glossary_tooltip text="selector" term_id="selector" >}}. Nếu có nhiều Pods được thêm vào hay xóa đi, tập những Pods hợp với selector sẽ thay đổi. Service đảm bảo network traffic có thể đến tới tập những Pods để giải quyết công việc.
@@ -12,7 +12,7 @@ tags:
  - fundamental
 ---

-Là một đối tượng bao gồm ba thuộc tính bắt buộc: key, value, và effect. Taints (dấu chờ) ngăn cản việc lập lịch cho các pod chạy trên các {{< glossary_tooltip text="node" term_id="node" >}} hay nhóm các node.
+Là một đối tượng bao gồm ba thuộc tính bắt buộc: key, value, và effect. Taints (dấu chờ) ngăn cản việc lập lịch cho các pod chạy trên các node hay nhóm các node.

 <!--more-->

@@ -1489,7 +1489,7 @@ GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte

 Quobyte 支持{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}。
 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。
-Quobyte 的 GitHub 项目具有[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)以及使用示例来部署 CSI 的 Quobyte。
+Quobyte 的 GitHub 项目具有[说明(https://github.com/quobyte/quobyte/quobyte-csi#quobyte-csi)以及使用示例来部署 CSI 的 Quobyte。

 ### rbd {#rbd}

@@ -31,14 +31,14 @@ This page assumes you have a working Juju deployed cluster.
 <!--
 ## Implementation

-The TLS and easyrsa implementations use the following [layers](https://old-docs.jujucharms.com/2.5/en/developer-layers).
+The TLS and easyrsa implementations use the following [layers](https://jujucharms.com/docs/2.2/developer-layers).

 [layer-tls-client](https://github.com/juju-solutions/layer-tls-client)
 [layer-easyrsa](https://github.com/juju-solutions/layer-easyrsa)
 -->
 ## 实现

-TLS 和 easyrsa 的实现使用以下 [layers](https://old-docs.jujucharms.com/2.5/en/developer-layers)。
+TLS 和 easyrsa 的实现使用以下 [layers](https://jujucharms.com/docs/2.2/developer-layers)。

 [layer-tls-client](https://github.com/juju-solutions/layer-tls-client)
 [layer-easyrsa](https://github.com/juju-solutions/layer-easyrsa)
@@ -52,7 +52,7 @@ By default the administrator can ssh to any deployed node in a cluster. You can

 Note: The Juju controller node will still have open ssh access in your cloud, and will be used as a jump host in this case.

-Refer to the [model management](https://old-docs.jujucharms.com/2.5/en/models) page in the Juju documentation for instructions on how to manage ssh keys.
+Refer to the [model management](https://jujucharms.com/docs/2.2/models) page in the Juju documentation for instructions on how to manage ssh keys.
 -->
 ## 限制 ssh 访问

@@ -62,7 +62,7 @@ Refer to the [model management](https://old-docs.jujucharms.com/2.5/en/models) p

 注意：Juju 控制器节点在您的云中仍然有开放的 ssh 访问权限，并且在这种情况下将被用作跳板机。

-有关如何管理 ssh 密钥的说明，请参阅 Juju 文档中的 [模型管理](https://old-docs.jujucharms.com/2.5/en/models) 页面。
+有关如何管理 ssh 密钥的说明，请参阅 Juju 文档中的 [模型管理](https://jujucharms.com/docs/2.2/models) 页面。
 {{% /capture %}}


@@ -62,13 +62,13 @@ policies using an example application.
 ## Deploying Cilium for Production Use

 For detailed instructions around deploying Cilium for production, see:
-[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
+[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
 This documentation includes detailed requirements, instructions and example
 production DaemonSet files.
 -->

 ## 部署 Cilium 用于生产用途
-关于部署 Cilium 用于生产的详细说明，请见[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
+关于部署 Cilium 用于生产的详细说明，请见[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
 ，此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。

 {{% /capture %}}
@@ -103,7 +103,7 @@ There are two main components to be aware of:
 on the traffic to/from Pods on that node using Linux BPF.
 - For production deployments, Cilium should leverage the key-value store cluster
 (e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.
-The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
+The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
 includes an example DaemonSet which can be customized to point to this key-value
 store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such
 configuration because it automatically connects to the minikube's etcd instance.
@@ -112,7 +112,7 @@ configuration because it automatically connects to the minikube's etcd instance.

 - 在集群中的每个节点上都会运行一个 `cilium` Pod，并利用Linux BPF执行网络策略管理该节点上进出 Pod 的流量。
 - 对于生产部署，Cilium 应该复用 Kubernetes 所使用的键值存储集群（如 etcd），其通常在Kubernetes 的 master 节点上运行。
-[Cilium Kubernetes安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
+[Cilium Kubernetes安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
 包括了一个示例 DaemonSet，可以自定义指定此键值存储集群。
 简单的 minikube 的“一体化” DaemonSet 不需要这样的配置，因为它会自动连接到 minikube 的 etcd 实例。

@@ -35,7 +35,7 @@ content_template: templates/task


 * [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
-    * [Romana 网络策略示例](https://github.com/romana/core/blob/master/doc/policy.md)
+    * [Romana 网络策略示例](https://github.com/romana/core/tree/master/policy)

 * NetworkPolicy API

@@ -604,7 +604,7 @@ Kubernetes 可能会在创建新的日志文件时删除旧的日志文件; 您
 [gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
 [kubeconfig]: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
 [fluentd]: http://www.fluentd.org/
-[fluentd_install_doc]: https://docs.fluentd.org/v/0.12/articles/quickstart#step1-installing-fluentd
+[fluentd_install_doc]: http://docs.fluentd.org/v0.12/articles/quickstart#step1-installing-fluentd
 [logstash]: https://www.elastic.co/products/logstash
 [logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
 [kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
@@ -1,12 +1,3 @@
---
-reviewers:
- chenopis
-
-title: 使用 CronJob 运行自动化任务
-content_template: templates/task
-weight: 10
---
-
 <!--
 ---
 title: Running Automated Tasks with a CronJob
@@ -17,6 +8,15 @@ weight: 10
 ---
 -->

+---
+reviewers:
+- chenopis
+
+title: 使用 CronJob 运行自动化任务
+content_template: templates/task
+weight: 10
+---
+
 {{% capture overview %}}

 <!--
@@ -318,10 +318,8 @@
 /docs/tutorials/kubernetes-basics/expose-intro/     /docs/tutorials/kubernetes-basics/expose/expose-intro/ 301
 /docs/tutorials/kubernetes-basics/scale-interactive/     /docs/tutorials/kubernetes-basics/scale/scale-interactive/ 301
 /docs/tutorials/kubernetes-basics/scale-intro/     /docs/tutorials/kubernetes-basics/scale/scale-intro/ 301
-/ja/docs/tutorials/kubernetes-basics/scale-intro/     /ja/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301
 /docs/tutorials/kubernetes-basics/update-interactive/    /docs/tutorials/kubernetes-basics/update/update-interactive/ 301
 /docs/tutorials/kubernetes-basics/update-intro/     /docs/tutorials/kubernetes-basics/update/update-intro/ 301
-/ja/docs/tutorials/kubernetes-basics/update-intro/     /ja/docs/tutorials/kubernetes-basics/update/update-intro/ 301
 /docs/tutorials/example-tutorial-template.md -> /example-templates/example-tutorial-template.md 301
 /docs/tutorials/object-management-kubectl/declarative-object-management-configuration/      /docs/concepts/overview/object-management-kubectl/declarative-config/ 301
 /docs/tutorials/object-management-kubectl/imperative-object-management-command/      /docs/concepts/overview/object-management-kubectl/imperative-command/ 301
@@ -517,16 +515,12 @@ https://kubernetes-io-v1-7.netlify.com/*    https://v1-7.docs.kubernetes.io/:spl
 /docs/setup/minikube/     /docs/setup/learning-environment/minikube/   301
 /docs/setup/cri/     /docs/setup/production-environment/container-runtimes/   301
 /docs/setup/independent/install-kubeadm/     /docs/setup/production-environment/tools/kubeadm/install-kubeadm/   301
-/ja/docs/setup/independent/install-kubeadm/     /ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/   301
 /docs/setup/independent/troubleshooting-kubeadm/     /docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/   301
 /docs/setup/independent/create-cluster-kubeadm/     /docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/   301
-/ja/docs/setup/independent/create-cluster-kubeadm/     /ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/   301
 /docs/setup/independent/control-plane-flags/     /docs/setup/production-environment/tools/kubeadm/control-plane-flags/   301
 /docs/setup/independent/ha-topology/     /docs/setup/production-environment/tools/kubeadm/ha-topology/   301
-/ja/docs/setup/independent/ha-topology/     /ja/docs/setup/production-environment/tools/kubeadm/ha-topology/   301
 /docs/setup/independent/high-availability/     /docs/setup/production-environment/tools/kubeadm/high-availability/   301
 /docs/setup/independent/setup-ha-etcd-with-kubeadm/     /docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/   301
-/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/     /ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/   301
 /docs/setup/independent/kubelet-integration/     /docs/setup/production-environment/tools/kubeadm/kubelet-integration/   301
 /docs/setup/custom-cloud/kops/     /docs/setup/production-environment/tools/kops/   301
 /docs/setup/custom-cloud/kubespray/     /docs/setup/production-environment/tools/kubespray/   301
Author	SHA1	Message	Date
Damini Satya	0eecbd40e3	Update config.toml(release-1.17) for 1.17 (#18031 )	2019-12-09 16:01:31 -08:00
Tim Bannister	68e8fb5a82	Update for v1.17 (#18034 )	2019-12-09 15:14:40 -08:00
Damini Satya	253bcb2283	Reference Documentation for kubectl Commands for 1.17 (#18017 )	2019-12-09 15:12:40 -08:00
Damini Satya	50139f0132	Update feature-gates.md (#18033 )	2019-12-09 12:58:03 -08:00
Damini Satya	638a341877	Reference Documentation for the Kubernetes API for 1.17 (#18019 )	2019-12-09 12:44:04 -08:00
daminisatya	fa71e44da1	Promote VolumeSubpathEnvExpansion to GA	2019-12-06 17:48:50 -05:00
Yasen Simeonov	8cfbabadbd	add Antrea description in dev-1.17 (#17919 )	2019-12-06 17:48:50 -05:00
Tim Bannister	c3917a5e50	Cleanup kubectl generators docs (#17609 ) * Write ReplicationController without a space * Drop mentioning unsupported cluster versions * Fix capitalization for “API group” * Tweak wording * Avoid using deprecated generator in example	2019-12-06 17:48:49 -05:00
Joe Betz	3d7e739b5b	Add resource version section to api-concepts documentation (#16910 ) * Add Resource Version semantics section to api concepts * Clarify risks of going back in time, add details about compaction and watch cache sizes * Apply suggestions from liggitt Co-Authored-By: Jordan Liggitt <jordan@liggitt.net> * remove pesudocode, apply feedback * Fix typo * Clarify equality rules	2019-12-06 17:48:49 -05:00
Cheng Pan	0247b7897e	Update AWS EBS Migration Feature state (#16126 )	2019-12-06 17:48:49 -05:00
Jordan Liggitt	3c40a092f7	Update WebhookAdmissionConfiguration examples (#17549 )	2019-12-06 17:48:49 -05:00
Jordan Liggitt	a8020b6275	AdmissionConfiguration v1 (#17548 )	2019-12-06 17:48:49 -05:00
Jordan Liggitt	1bdaa20400	Update docs for v1 resource quota configuration (#17547 )	2019-12-06 17:48:49 -05:00
Draven	162292ac2f	feat: update TaintNodesByCondition in feature gates table (#17377 )	2019-12-06 17:48:49 -05:00
Jianzhu Zhang	fe6087b601	update doc for kubelet option --reserved-cpus (#17648 )	2019-12-06 17:48:48 -05:00
Patrick Lang	6fde238d15	doc: Simplify Windows deployments with RuntimeClass (#16697 ) * doc: Simplify Windows deployments with RuntimeClass * Updating on review feedback * doc: Adding windows-build label from enhancement 1301	2019-12-06 17:48:48 -05:00
Lubomir I. Ivanov	1156daf227	kubeadm: update the upgrade documentation for 1.17 (#17587 )	2019-12-06 17:48:48 -05:00
Draven	0e5d8e520e	feat: graduate ResourceQuotaScopeSelectors to GA in 1.17 (#17554 )	2019-12-06 17:48:48 -05:00
Tim Bannister	6be1509c2b	Update Node concept for TaintNodesByCondition going GA (#17577 )	2019-12-06 17:48:48 -05:00
Deep Debroy	fea3bf18c5	Update list of feature flags for in-tree plugins migrated to CSI (#17533 ) Signed-off-by: Deep Debroy <ddebroy@docker.com>	2019-12-06 17:48:48 -05:00
John Belamaric	d8ee2090f2	Service topology alpha documentation (#17459 )	2019-12-06 17:48:48 -05:00
Andrew Sy Kim	a4447802db	add topology.kubernetes.io/zone, topology.kubernetes.io/region and node.kubernetes.io/instance-type labels to docs (#17498 ) Signed-off-by: Andrew Sy Kim <kiman@vmware.com>	2019-12-06 17:48:47 -05:00
Lachlan Evenson	5702296827	(docs/dualstack): v1.17 updates (#17457 ) * Add placehold doc updates for dualstack in 1.17 Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Add Downward API and /etc/hosts Pod IP validation Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * remove addressed known issue via k/k pr 85246 Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Remove known issue and add flag as part of k/k 79993 Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * remove follow up placeholders Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Update verbiage Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Make IP addressing consistent throughout the task Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Update to status.podIPs Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Update content/en/docs/tasks/network/validate-dual-stack.md Use set instead of env Co-Authored-By: Khaled Henidak (Kal) <khnidk@outlook.com>	2019-12-06 17:48:47 -05:00
Rob Scott	6e6f90acc1	Updating EndpointSlice documentation for beta release in 1.17 (#17411 )	2019-12-06 17:48:47 -05:00
Xing Yang	38684c3035	Add documentation for VolumeSnapshot Beta (#17233 )	2019-12-06 17:48:47 -05:00
Dr. Stefan Schimanski	d42940b264	Update CRD defaulting docs for GA (#17450 )	2019-12-06 17:48:47 -05:00
Louise Daly	bfa4e7ca9d	Fix broken Topology Manager link (#17746 ) Part of What's Next Device Plugin section	2019-12-06 17:48:47 -05:00
Louise Daly	e1f50b1d63	Update Topology Manager docs (#17451 ) * Added information on how device plugins can take advantage of Topology Manager * Updated the Topology Manager documentation to include additionalinformation and update some out of date sections	2019-12-06 17:48:47 -05:00
Zihong Zheng	9278d3cfac	Update service load balancer finalizer doc for GA (#17438 )	2019-12-06 17:48:46 -05:00
Lee Verberne	50d9795fb8	Promote PodShareProcessNamespace to stable (#17192 ) * Promote PodShareProcessNamespace to stable * Add for_k8s_version to feature-state label Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Readd version-check to shareProcessNamespace task	2019-12-06 17:48:46 -05:00
Fabio Bertinatto	68ef194ead	Promote Node-specific volume limits to GA (#17432 )	2019-12-06 17:48:46 -05:00
Patrick Lang	7524f7d954	Update RunAsUsername to beta (#17460 ) * doc:Update RunAsUsername to beta * doc: update samples - kubernetes.io/os is no longer beta * Updating based on review feedback	2019-12-06 17:48:46 -05:00
Michelle Au	ddd2a14a7c	Update docs for csi topology ga (#17408 )	2019-12-06 17:48:46 -05:00
Wojciech Tyczynski	1a884b1f97	Promote NodeLease feature to GA (#17189 )	2019-12-06 17:48:46 -05:00
David Zhu	b04abcfb61	Move CSIMigration and CSIMigrationGCE to Beta in Kubernetes v1.17 (#17478 )	2019-12-06 17:48:45 -05:00
Ciprian Hacman	3c89724c93	Use exact version numbers for installing Docker in Ubuntu (#17428 )	2019-12-06 17:48:45 -05:00
Ciprian Hacman	703b2658c2	Update Docker installation instructions (#17405 )	2019-12-06 17:48:45 -05:00
Draven	012a41a5fc	feat: graduate ScheduleDaemonSetPods to GA (#17350 )	2019-12-06 17:48:45 -05:00
Wojciech Tyczynski	877978350f	Watch bookmarks to GA (#17026 )	2019-12-06 17:48:45 -05:00
Matthias Bertschy	dde56f2463	Promote StartupProbe to beta (enabled by default). (#17164 )	2019-12-06 17:48:45 -05:00
Draven	3dd265c40b	feat: graduate TaintNodesByCondition to GA (#17073 )	2019-12-06 17:48:44 -05:00