From 95d6d7d86dc45b45fe29d457ab3fd88065b8ceb6 Mon Sep 17 00:00:00 2001 From: AdamDang Date: Fri, 27 Apr 2018 04:09:27 +0800 Subject: [PATCH] Some typo fixes in blog (#8149) * Update 2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md * Update 2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md * Update 2016-08-00-Create-Couchbase-Cluster-Using-Kubernetes.md * Update 2017-04-00-Rbac-Support-In-Kubernetes.md --- .../_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md | 2 +- .../_posts/2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md | 2 +- .../2016-08-00-Create-Couchbase-Cluster-Using-Kubernetes.md | 2 +- ...-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md | 2 +- blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md b/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md index 9d83349dce..0a687da690 100644 --- a/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md +++ b/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md @@ -108,7 +108,7 @@ Agenda: * one proposal is to use pre-start hook. another is precondition probe - pre-start hook could do a probe. does anything respond when i hit this svc address or ip, then probe fails. could be implemented in pre-start hook. more useful than post-start. is part of rkt spec. has stages 0, 1, 2. hard to do in docker today, easy in rocket. * pre-start hook in container: how will affect readiness probe since the container might have a lock until some arbitrary condition is met if you implement with prestart hook. there has to be some compensation on when kubelet runs readiness/liveness probes if you have a hook. systemd has timeouts around the stages of process lifecycle. * if we go to black box model of container pre-start makes sense; if container spec becomes more descriptive of process model like systemd, then does kubelet need to know more about process model to do the right thing -* ideally msg from inside the container to say i've done all of my pre-start actions. sdnotify for systemd does this. you tell systemd that you're done, it will communicate to to other deps that you're alive. +* ideally msg from inside the container to say i've done all of my pre-start actions. sdnotify for systemd does this. you tell systemd that you're done, it will communicate to other deps that you're alive. * but... someone could just implement preconds inside their container. makes it easier to adapt an app w/o having to change their image. alternative is just have a pattern how they do it themselves but we don't do it for them. [1]: http://metadata.name/ diff --git a/blog/_posts/2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md b/blog/_posts/2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md index 409fbbf5c2..6a1414eeec 100644 --- a/blog/_posts/2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md +++ b/blog/_posts/2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md @@ -50,7 +50,7 @@ The first phase of this effort invoking CRIU directly to dump a process tree run Docker sets up /etc/{hostname,hosts,resolv.conf} as targets with source files outside the container's mount namespace. -The --ext-mount-map command line option was added to CRIU to specify the path of the external bind mounts. For example, assuming default Docker configuration, /etc/hostname in the container's mount namespace is bind mounted from the source at /var/lib/docker/containers/\/hostname. When checkpointing, we tell CRIU to record /etc/hostname's "map" as, say, etc\_hostname. When restoring, we tell CRIU that that the file previously recorded as etc\_hostname should be mapped from the external bind mount at /var/lib/docker/containers/\/hostname. +The --ext-mount-map command line option was added to CRIU to specify the path of the external bind mounts. For example, assuming default Docker configuration, /etc/hostname in the container's mount namespace is bind mounted from the source at /var/lib/docker/containers/\/hostname. When checkpointing, we tell CRIU to record /etc/hostname's "map" as, say, etc\_hostname. When restoring, we tell CRIU that the file previously recorded as etc\_hostname should be mapped from the external bind mount at /var/lib/docker/containers/\/hostname. diff --git a/blog/_posts/2016-08-00-Create-Couchbase-Cluster-Using-Kubernetes.md b/blog/_posts/2016-08-00-Create-Couchbase-Cluster-Using-Kubernetes.md index fea6a34dfd..31f4053c1c 100644 --- a/blog/_posts/2016-08-00-Create-Couchbase-Cluster-Using-Kubernetes.md +++ b/blog/_posts/2016-08-00-Create-Couchbase-Cluster-Using-Kubernetes.md @@ -270,7 +270,7 @@ This RC also creates a single replica of Couchbase using the same arungupta/couc - TYPE environment variable is set to WORKER. This adds a worker Couchbase node to be added to the cluster. - COUCHBASE\_MASTER environment variable is passed the value of couchbase-master-service. This uses the service discovery mechanism built into Kubernetes for pods in the worker and the master to communicate. -- AUTO\_REBALANCE environment variable is set to false. This ensures that the node is only added to the cluster but the cluster itself is not rebalanced. Rebalancing is required to to re-distribute data across multiple nodes of the cluster. This is the recommended way as multiple nodes can be added first, and then cluster can be manually rebalanced using the Web Console. +- AUTO\_REBALANCE environment variable is set to false. This ensures that the node is only added to the cluster but the cluster itself is not rebalanced. Rebalancing is required to re-distribute data across multiple nodes of the cluster. This is the recommended way as multiple nodes can be added first, and then cluster can be manually rebalanced using the Web Console. Let’s create a worker: diff --git a/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md b/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md index 3f6572cfe4..5400f78a8f 100644 --- a/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md +++ b/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md @@ -57,7 +57,7 @@ I realize we need to perform a rolling update to a newer version of that app tha ![](https://lh4.googleusercontent.com/RdA8N8LPDwnAb-RDX4MHNmHvxc8YRlID79-5WmGJQb7NYuz8oZseVorzATQZWOTTQ_-yp8roniNKuBqmQewzYzyvBRdHcQf_VENm2Qqde0v6LW9-L1FLmqsUx8h9Z5RYfpD_alXx){:.big-img} -Now that that Replica Set’s been created, I can open the logs for one of its pods to confirm that it’s been successfully connected to the API server. +Now that Replica Set’s been created, I can open the logs for one of its pods to confirm that it’s been successfully connected to the API server. diff --git a/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md b/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md index a0dbbc958a..913c4facf1 100644 --- a/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md +++ b/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md @@ -9,7 +9,7 @@ pagination: _Editor’s note: this post is part of a [series of in-depth articles](http://blog.kubernetes.io/2017/03/five-days-of-kubernetes-1.6.html) on what's new in Kubernetes 1.6_ -One of the highlights of the [Kubernetes 1.6](http://blog.kubernetes.io/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale.html) release is the RBAC authorizer feature moving to _beta_. RBAC, Role-based access control, is an an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows configuration of flexible authorization policies that can be updated without cluster restarts. +One of the highlights of the [Kubernetes 1.6](http://blog.kubernetes.io/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale.html) release is the RBAC authorizer feature moving to _beta_. RBAC, Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows configuration of flexible authorization policies that can be updated without cluster restarts. The focus of this post is to highlight some of the interesting new capabilities and best practices.