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
2018-04-27 04:09:27 +08:00
parent 78042ccaa7
commit 95d6d7d86d
5 changed files with 5 additions and 5 deletions
@@ -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/
@@ -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/\<container-id\>/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/\<container-id\>/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/\<container-id\>/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/\<container-id\>/hostname.



@@ -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:


@@ -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.  



@@ -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.