diff options
| author | Kubernetes Submit Queue <k8s-merge-robot@users.noreply.github.com> | 2017-10-26 20:29:53 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-10-26 20:29:53 -0700 |
| commit | 4377efa625d91ed8367bbc6a6672b7dff03dbd2b (patch) | |
| tree | d4852d82672e6780c98be80ccf90af735b476fa5 | |
| parent | b8ceddfde59c0d3975073166281beae92b9eb43b (diff) | |
| parent | 5e3a738bd4fa9fd3965e8343f65da4baede693c6 (diff) | |
Merge pull request #1284 from chenhonggc/update_some_files
Automatic merge from submit-queue.
update cloud-provider-refactoring.md and kubelet-cri-logging.md
fixed some mistake spelling.
| -rw-r--r-- | contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md | 2 | ||||
| -rw-r--r-- | contributors/design-proposals/node/kubelet-cri-logging.md | 2 |
2 files changed, 2 insertions, 2 deletions
diff --git a/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md b/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md index 7a554b4c..e716d90b 100644 --- a/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md +++ b/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md @@ -133,7 +133,7 @@ This is the only step that is different in the upgrade process. In order to comp kubectl apply -f cloud-controller-manager.yml ``` -This will start the cloud specific controller manager in your kuberentes setup. +This will start the cloud specific controller manager in your kubernetes setup. The downgrade steps are also the same as before for all the components except the cloud-controller-manager. In case of the cloud-controller-manager, the deployment should be deleted using diff --git a/contributors/design-proposals/node/kubelet-cri-logging.md b/contributors/design-proposals/node/kubelet-cri-logging.md index 0cda9901..41c5cc9c 100644 --- a/contributors/design-proposals/node/kubelet-cri-logging.md +++ b/contributors/design-proposals/node/kubelet-cri-logging.md @@ -59,7 +59,7 @@ the format and the metadata (i.e., timestamps) of the logs. In the current implementation, kubelet calls `docker logs` with parameters to return the log content. As of now, docker only supports `log` operations for the “journal” and “json-file” drivers [2]. In other words, *the support of `kubectl logs` is not -universal in all kuernetes deployments*. +universal in all kubernetes deployments*. **Cluster logging support** |