Update contents

.travis.yml

@@ -0,0 +1,18 @@
+sudo: required
+
+language: go
+
+go:
+  - 1.11.x
+
+
+before_script:
+  - go get -u github.com/client9/misspell/cmd/misspell
+  - go version
+
+
+jobs:
+  include:
+    - stage: Verify
+      script: make spell
+

Makefile

@@ -30,6 +30,11 @@ install:
 clean:
 	rm -rf $(BOOK_OUTPUT)
 
+.PHONY: spell
+spell:
+	go get github.com/client9/misspell/cmd/misspell
+	git ls-files | xargs misspell -error -o stderr	
+
 .PHONY: help
 help:
 	@echo "Help for make"
@@ -39,4 +44,5 @@ help:
 	@echo "make install  - Install gitbook and plugins"
 	@echo "make epub     - Build epub book"
 	@echo "make pdf      - Build pdf book"
+	@echo "make spell    - Check splling"
 	@echo "make clean    - Remove generated files"

addons/cluster-autoscaler.md

@@ -60,10 +60,17 @@ Cluster AutoScaler 也会定期（默认间隔 10s）自动监测 Node 的资源
 ## 最佳实践
 
 - Cluster AutoScaler 可以和 Horizontal Pod Autoscaler（HPA）配合使用
+
+  ![image-20190316184848223](assets/image-20190316184848223.png)
+
 - 不要手动修改 Node 配置，保证集群内的所有 Node 有相同的配置并属于同一个 Node 组
+
 - 运行 Pod 时指定资源请求
+
 - 必要时使用 PodDisruptionBudgets 阻止 Pod 被误删除
+
 - 确保云服务商的配额充足
+
 - Cluster AutoScaler **与云服务商提供的 Node 自动扩展功能以及基于 CPU 利用率的 Node 自动扩展机制冲突，不要同时启用**
 
 ## 参考文档

apps/argo.md

@@ -7,7 +7,7 @@ Argo 是一个基于 Kubernetes 的工作流引擎，同时也支持 CI、CD 等
 ### 使用 argo install
 
 ```sh
-# Downlaod Argo.
+# Download Argo.
 curl -sSL -o argo https://github.com/argoproj/argo/releases/download/v2.1.0/argo-linux-amd64
 chmod +x argo
 sudo mv argo /usr/local/bin/argo
@@ -67,7 +67,7 @@ $ kubectl edit configmap workflow-controller-configmap -n argo
 > 注意：当前 Helm Charts 使用的 Minio 版本较老，部署有可能会失败。
 
 ```sh
-# Downlaod Argo.
+# Download Argo.
 curl -sSL -o /usr/local/bin/argo https://github.com/argoproj/argo/releases/download/v2.0.0/argo-linux-amd64
 chmod +x /usr/local/bin/argo
 

architecture/architecture.md

@@ -75,7 +75,7 @@ Kubernetes 设计理念和功能其实就是一个类似 Linux 的分层架构
 
 
 
-关于分层架构，可以关注下 Kubernetes 社区正在推进的 [Kubernetes architectual roadmap](https://github.com/kubernetes/community/tree/master/sig-architecture)。
+关于分层架构，可以关注下 Kubernetes 社区正在推进的 [Kubernetes architectural roadmap](https://github.com/kubernetes/community/tree/master/sig-architecture)。
 
 ## 参考文档
 

components/apiserver.md

@@ -9,6 +9,10 @@ kube-apiserver 是 Kubernetes 最重要的核心组件之一，主要提供以
 
 kube-apiserver 支持同时提供 https（默认监听在 6443 端口）和 http API（默认监听在 127.0.0.1 的 8080 端口），其中 http API 是非安全接口，不做任何认证授权机制，不建议生产环境启用。两个接口提供的 REST API 格式相同，参考 [Kubernetes API Reference](https://kubernetes.io/docs/api-reference/v1.8/) 查看所有 API 的调用格式。
 
+![img](assets/API-server-space.png)
+
+（图片来自 [OpenShift Blog](https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/)）
+
 在实际使用中，通常通过 [kubectl](https://kubernetes.io/docs/user-guide/kubectl-overview/) 来访问 apiserver，也可以通过 Kubernetes 各个语言的 client 库来访问 apiserver。在使用 kubectl 时，打开调试日志也可以看到每个 API 调用的格式，比如
 
 ```sh
@@ -138,6 +142,16 @@ kube-apiserver 提供了 Kubernetes 的 REST API，实现了认证、授权、
 
 ![](images/kube-apiserver.png)
 
+以 `/apis/batch/v2alpha1/jobs` 为例，GET 请求的处理过程如下图所示：
+
+![img](assets/API-server-flow.png)
+
+POST 请求的处理过程为：
+
+![img](assets/API-server-storage-flow.png)
+
+（图片来自 [OpenShift Blog](https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/)）
+
 ## API 访问
 
 有多种方式可以访问 Kubernetes 提供的 REST API：
@@ -215,9 +229,8 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 
 ## API 参考文档
 
-最近 4 个稳定版本的 API 参考文档为：
+最近 3 个稳定版本的 API 参考文档为：
 
+- [v1.13 API Reference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/)
+- [v1.12 API Reference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/)
 - [v1.11 API Reference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/)
-- [v1.10 API Reference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/)
-- [v1.9 API Reference](https://kubernetes.io/docs/api-reference/v1.9/)
-- [v1.8 API Reference](https://kubernetes.io/docs/api-reference/v1.8/)

concepts/autoscaling.md

@@ -142,7 +142,7 @@ Conditions:
   ----                  ------  ------                  -------
   AbleToScale           True    ReadyForNewScale        the last scale time was sufficiently old as to warrant a new scale
   ScalingActive         True    ValidMetricFound        the HPA was able to successfully calculate a replica count from pods metric http_requests
-  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptible range
+  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
 Events:
 ```
 

concepts/ingress.md

@@ -20,13 +20,7 @@
 
 而 Ingress 就是为进入集群的请求提供路由规则的集合，如下图所示
 
-```
-    internet
-        |
-   [Ingress]
-   --|-----|--
-   [Services]
-```
+![image-20190316184154726](assets/image-20190316184154726.png)
 
 Ingress 可以给 service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等。为了配置这些 Ingress 规则，集群管理员需要部署一个 [Ingress controller](../plugins/ingress.md)，它监听 Ingress 和 service 的变化，并根据规则配置负载均衡并提供访问入口。
 
@@ -53,7 +47,7 @@ spec:
 
 | Kubernetes 版本 | Extension 版本     |
 | --------------- | ------------------ |
-| v1.5-v1.9       | extensions/v1beta1 |
+| v1.5+           | extensions/v1beta1 |
 
 ## Ingress 类型
 

deploy/kubespray.md

@@ -108,7 +108,7 @@ node1                      : ok=305  changed=73   unreachable=0    failed=0
 node2                      : ok=276  changed=62   unreachable=0    failed=0
 node3                      : ok=276  changed=62   unreachable=0    failed=0
 
-Kubernetes deployed successfuly
+Kubernetes deployed successfully
 ```
 > 其中 `-n` 为部署的网络插件类型，目前支持 calico、flannel、weave 与 canal。
 

devel/contribute.md

@@ -6,7 +6,7 @@ Kubernetes 支持以许多种方式来贡献社区，包括汇报代码缺陷、
 
 Kubernetes 社区由三部分组成
 
-- [Steering committe](http://blog.kubernetes.io/2017/10/kubernetes-community-steering-committee-election-results.html)
+- [Steering committee](http://blog.kubernetes.io/2017/10/kubernetes-community-steering-committee-election-results.html)
 - [Special Interest Groups (SIG)](https://contributor.kubernetes.io/sigs/)
 - [Working Groups (WG)](https://contributor.kubernetes.io/sigs/#master-working-group-list)
 

etc/sysconfig/docker

@@ -29,7 +29,7 @@ if [ -z "${DOCKER_CERT_PATH}"  ]; then
 
 # Location used for temporary files, such as those created by
 # docker load and build operations. Default is /var/lib/docker/tmp
-# Can be overriden by setting the following environment variable.
+# Can be overridden by setting the following environment variable.
 # DOCKER_TMPDIR=/var/tmp
 
 # Controls the /etc/cron.daily/docker-logrotate cron job status.

examples/evaluate-pod-creation.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # Evaluate pod creation process.
-# This is ususally used for evaluationg whether a cluster is configured properly.
+# This is usually used for evaluating whether a cluster is configured properly.
 set -e
 
 create_pod() {

network/network.md

@@ -41,6 +41,16 @@ kubenet 是一个基于 CNI bridge 的网络插件，它为每个容器建立一
 
 - Traffic shaping，支持通过 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth` 等 Annotation 设置 Pod 网络带宽限制
 
+下图是一个 Kubernetes on Azure 多节点的 Pod 之间相互通信的原理：
+
+![image-20190316183639488](assets/image-20190316183639488.png)
+
+跨节点 Pod 之间相互通信时，会通过云平台或者交换机配置的路由转发到正确的节点中：
+
+![image-20190316183650404](assets/image-20190316183650404.png)
+
+
+
 未来 kubenet 插件会迁移到标准的 CNI 插件（如 ptp），具体计划见 [这里](https://docs.google.com/document/d/1glJLMHrE2eqwRrAN4fdsz4Vg3R1Iqt6bm5GJQ4GdjlQ/edit#)。
 
 ## CNI plugin

plugins/CRI.md

@@ -6,6 +6,10 @@
 
 CRI 最早从从 1.4 版就开始设计讨论和开发，在 v1.5 中发布第一个测试版。在 v1.6 时已经有了很多外部容器运行时，如 frakti 和 cri-o 等。v1.7 中又新增了 cri-containerd 支持用 Containerd 来管理容器。
 
+采用 CRI 后，Kubelet 的架构如下图所示：
+
+![image-20190316183052101](assets/image-20190316183052101.png)
+
 ## CRI 接口
 
 CRI 基于 gRPC 定义了 RuntimeService 和 ImageService 等两个 gRPC 服务，分别用于容器运行时和镜像的管理。其定义在
@@ -52,6 +56,8 @@ func main() {
 
 对于 Streaming API（Exec、PortForward 和 Attach），CRI 要求容器运行时返回一个 streaming server 的 URL 以便 Kubelet 重定向 API Server 发送过来的请求。在 v1.10 及更早版本中，容器运行时必需返回一个 API Server 可直接访问的 URL（通常跟 Kubelet 使用相同的监听地址）；而从 v1.11 开始，Kubelet 新增了 `--redirect-container-streaming`（默认为 false），默认不再转发而是代理 Streaming 请求，这样运行时可以返回一个 localhost 的 URL（当然也不再需要配置 TLS）。
 
+![image-20190316183005314](assets/image-20190316183005314.png)
+
 详细的实现方法可以参考 [dockershim](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/dockershim) 或者 [cri-o](https://github.com/kubernetes-incubator/cri-o)。
 
 ### Kubelet 配置
@@ -64,6 +70,16 @@ kubelet --container-runtime=remote --container-runtime-endpoint=unix:///var/run/
 
 ## 容器运行时
 
+| **CRI** **容器运行时** | **维护者** | **主要特性**                 | **容器引擎**               |
+| ---------------------- | ---------- | ---------------------------- | -------------------------- |
+| **Dockershim**         | Kubernetes | 内置实现、特性最新           | docker                     |
+| **cri-o**              | Kubernetes | OCI标准不需要Docker          | OCI（runc、kata、gVisor…） |
+| **cri-containerd**     | Containerd | 基于 containerd 不需要Docker | OCI（runc、kata、gVisor…） |
+| **Frakti**             | Kubernetes | 虚拟化容器                   | hyperd、docker             |
+| **rktlet**             | Kubernetes | 支持rkt                      | rkt                        |
+| **PouchContainer**     | Alibaba    | 富容器                       | OCI（runc、kata…）         |
+| **Virtlet**            | Mirantis   | 虚拟机和QCOW2镜像            | Libvirt（KVM）             |
+
 目前基于 CRI 容器引擎已经比较丰富了，包括
 
 - Docker: 核心代码依然保留在 kubelet 内部（[pkg/kubelet/dockershim](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/dockershim)），是最稳定和特性支持最好的运行时

plugins/auth.md

@@ -14,8 +14,7 @@ Kubernetes 集群的所有操作基本上都是通过 kube-apiserver 这个组
 
 > **Kubernetes 不直接管理用户**
 >
-> 虽然 Kubernetes 认证和授权用到了 username，但 Kubernetes 并不直接管理用户，不能创建 `user` 对象，
-> 也不存储 username。但是 Kubernetes 提供了 Service Account，用来与 API 交互。
+> 虽然 Kubernetes 认证和授权用到了 user 和 group，但 Kubernetes 并不直接管理用户，不能创建 `user` 对象，也不存储 user。
 
 目前，Kubernetes 支持以下认证插件：
 

plugins/authentication.md

@@ -4,8 +4,7 @@
 
 > **Kubernetes 不直接管理用户**
 >
-> 虽然 Kubernetes 认证和授权用到了 username，但 Kubernetes 并不直接管理用户，不能创建 `user` 对象，
-> 也不存储 username。但是 Kubernetes 提供了 Service Account，用来与 API 交互。
+> 虽然 Kubernetes 认证和授权用到了 user 和 group，但 Kubernetes 并不直接管理用户，不能创建 `user` 对象，也不存储 user。
 
 目前，Kubernetes 支持以下认证插件：
 
@@ -21,12 +20,31 @@
 
 ## X509 证书
 
-使用 X509 客户端证书只需要 API Server 启动时配置 `--client-ca-file=SOMEFILE`。在证书认证时，其 CN 域用作用户名，而组织机构域则用作 group 名。
+使用 X509 客户端证书只需要 API Server 启动时配置 `--client-ca-file=SOMEFILE`。在证书认证时，其 Common Name（CN）域用作用户名，而 Organization（O）域则用作 group 名。
 
 创建一个客户端证书的方法为：
 
 ```sh
-openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
+# Create private key
+openssl genrsa -out username.key 2048
+# Create CSR (certificate signing request)
+openssl req -new -key username.key -out username.csr -subj "/CN=username/O=group"
+# Create certificate from CSR using the cluster authority 
+openssl x509 -req -in username.csr -CA $CA_LOCATION/ca.crt -CAkey $CA_LOCATION/ca.key -CAcreateserial -out username.crt -days 500
+```
+
+接着，就可以使用 username.key 和 username.crt 来访问集群：
+
+```sh
+# Config cluster
+kubectl config set-cluster my-cluster --certificate-authority=ca.pem --embed-certs=true --server=https://<APISERVER_IP>:6443
+# Config credentials
+kubectl config set-credentials username --client-certificate=username.crt --client-key=username.key --embed-certs=true
+# Config context
+kubectl config set-context username --cluster=my-cluster --user=username
+# Config RBAC if it's enabled
+# Finally, switch to new context
+kubectl config use-context username
 ```
 
 ## 静态 Token 文件

plugins/csi.md

@@ -1,22 +1,26 @@
 # Container Storage Interface
 
-Container Storage Interface (CSI) 是从 v1.9 引入的容器存储接口，用于扩展 Kubernetes 的存储生态。实际上，CSI 是整个容器生态的标准存储接口，同样适用于 Mesos、Cloud Foundry 等其他的容器集群调度系统。
+Container Storage Interface (CSI) 是从 v1.9 引入的容器存储接口，并于 v1.13 版本正式 GA。实际上，CSI 是整个容器生态的标准存储接口，同样适用于 Mesos、Cloud Foundry 等其他的容器集群调度系统。
 
 **版本信息**
 
 | Kubernetes | CSI Spec | Status |
 | ---------- | -------- | ------ |
-| v1.9 | v0.1     | Alpha  |
-| v1.10      | v0.2     | Beta   |
-| v1.11-v1.12 | v0.3     | Beta   |
+| v1.9 | v0.1.0   | Alpha  |
+| v1.10      | v0.2.0   | Beta   |
+| v1.11-v1.12 | v0.3.0   | Beta   |
+| v1.13 | [v0.3.0](https://github.com/container-storage-interface/spec/releases/tag/v0.3.0), [v1.0.0](https://github.com/container-storage-interface/spec/releases/tag/v1.0.0) | GA |
 
 Sidecar 容器版本
 
-| Container Name   | CSI spec | Latest Release Tag |
-| ---------------- | -------- | ------------------ |
-| csi-provisioner  | v0.3     | v0.3.1             |
-| csi-attacher     | v0.3     | v0.3.0             |
-| driver-registrar | v0.3     | v0.3.0             |
+| Container Name           | Description                                                  | CSI spec | Latest Release Tag |
+| ------------------------ | ------------------------------------------------------------ | -------- | ------------------ |
+| external-provisioner     | Watch PVC and create PV                                      | v1.0.0   | v1.0.1             |
+| external-attacher        | Operate VolumeAttachment                                     | v1.0.0   | v1.0.1             |
+| external-snapshotter     | Operate VolumeSnapshot                                       | v1.0.0   | v1.0.1             |
+| node-driver-registrar    | Register kubelet plugin                                      | v1.0.0   | v1.0.2             |
+| cluster-driver-registrar | Register [CSIDriver Object](https://kubernetes-csi.github.io/docs/csi-driver-object.html) | v1.0.0   | v1.0.1             |
+| livenessprobe            | Monitors health of CSI driver                                | v1.0.0   | v1.0.2             |
 
 ## 原理
 
@@ -28,7 +32,7 @@ Sidecar 容器版本
 
 由于 CSI 监听在 unix socket 文件上， kube-controller-manager 并不能直接调用 CSI 插件。为了协调 Volume 生命周期的管理，并方便开发者实现 CSI 插件，Kubernetes 提供了几个 sidecar 容器并推荐使用下述方法来部署 CSI 插件：
 
-![](images/container-storage-interface_diagram1.png)
+![Recommended CSI Deployment Diagram](assets/container-storage-interface_diagram1.png)
 
 该部署方法包括：
 

plugins/flex-volume.md

@@ -2,6 +2,8 @@
 
 FlexVolume 是 Kubernetes v1.8+ 支持的一种存储插件扩展方式。类似于 CNI 插件，它需要外部插件将二进制文件放到预先配置的路径中（如 `/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`），并需要在系统中安装好所有需要的依赖。
 
+> 对于新的存储插件，推荐基于 [CSI](csi.md) 构建。
+
 ## FlexVolume 接口
 
 实现一个 FlexVolume 包括两个步骤
@@ -69,5 +71,5 @@ spec:
 
 注意：
 
-- 在 v1.7 版本，部署新的 FlevVolume 插件后需要重启 kubelet 和 kube-controller-manager；而从 v1.8 开始不需要重启它们了。
-- FlexVolume 不支持 [Dynamic Volume Provisioning](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/)，以 PVC 方式使用前需要管理员预先创建好对应的 PV。
+- 在 v1.7 版本，部署新的 FlevVolume 插件后需要重启 kubelet 和 kube-controller-manager；
+- 而从 v1.8 开始不需要重启它们了。