本系列的前两篇文章：
我们已经完成了下列在 Kubernetes 中的练习：
- 如何在 Kubernetes 里创建一个 Nginx 应用
- 如何在 Kubernetes 里创建一个 Nginx Service
- Kubenetes 里 Pod 和Service 绑定的实现方式
- 使用 Kubernetes 里的 job 计算圆周率后 2000 位
- Kubernetes 里的 ConfigMap 的用途
- 使用脚本在 Linux 服务器上自动安装 Kubernetes 的包管理器 Helm
- 一个简单的例子理解 Kubernetes 的三种 IP 地址类型
- 使用 describe 命令进行 Kubernetes pod 错误排查
本文继续通过实战来学习 Kubernetes 相关知识。
练习1：通过 describe 命令学习 Kubernetes 的 pod 详细属性
我们可以首先使用 kubectl get pods 命令得到 pod 列表，比如我们想研究 pod nginx-storage-pod 的明细：
使用命令 kubectl describe pod nginx-storage-pod > nginx-storage-pod.yaml, 将 describe 命令的输出重定向到一个 yaml 文件里。用 vi 打开这个 yaml 文件：
pod 的所有属性可以从这个 yaml 文件里学习：
node：shoot–k8s-train–shacw46-worker-prvfv-z1-7844dc6744-ghd5m/10.250.0.6
表明 pod 所在的 node，这个 node 一定是命令
kubectl get node返回的结果之一：
Image：代表该 pod 是基于哪一个 docker image 创建的。
Mount：该 pod 使用的 persistent volume 对应的物理文件目录，我的例子是 usr/share/nginx/html:
这个路径从哪里来的呢？就是我的 pod 文件的 yaml 文件里的定义：
describe命令除了本文介绍的可以用来深入学习 pod 的属性外，还可以用于 pod 不能正常启动时的错误排查。
比如我有一个 pod 名为 another3，状态一直处于 CrashLoopBackOff, RESTART 次数为12：
使用 kubectl describe pod another3 就可以看到这个容器启动的明细：
Back-off restarting failed container
仔细检查 pod 的 yaml 文件，发现原因是因为我定义了 volume 的 name 为 content-storage，但是没有指定 persistentvolumeclaim.
当我把 volumes: - name: content-storage 删除之后，
下图是修改后的 yaml 文件：
重新创建名为 another3 的 pod，很快就创建成功并且状态处于 running 了：
练习2 - 使用 Gardener 在 Google Cloud Platform 上创建 Kubernetes 集群
使用 Gardener，我们可以在几分钟之内在 GCP, AWS, Azure 或者 Openstack 上轻松创建Kubernetes Cluster.
点击新建按钮创建一个 Cluster，这里 Infrastructure 我选择的是 gcp：
创建成功后，状态变为 Ready，表明该集群已经可用了。
点击集群名称 jerrycls，进入集群明细页面，在 Access 标签页下面获得这个集群的用户名admin 和密码。
点击 dashboard 超链接，会弹出输入用户米和密码的提示。用户名输入 admin，密码从上面 Access 标签页获取。即可进入集群的管理页面。
从左下角处查看这个集群的三个 namespace：default，kube-public 和 kube-system：
这是 Gardener 自动为我分配的工作节点：
点击 kubeconfig，获得这个集群的 config yaml 文件，把它的内容复制下来：
我使用的操作系统是 ubuntu，上面安装了 kubectl.
进入目录 /home/vagrant/.kube, 用 vi 编辑 config 文件：
把从 Gardener 里拷贝的内容粘贴到 config 文件里。
现在使用 kubectl get ns，就可以看到 Kubernetes cluster 上的三个 namespace，和我们前面在 dashboard 里观察到的一致。
使用 kubectl get node -o wide, 看到一个工作节点，和之前在 Kubernetes dashboard 里观察到的一致。
使用命令 kubectl run nginx --image=nginx:1.12.2 创建一个 deployment，运行 nginx container：
创建好 deployment 之后，使用命令行创建一个 service，把 nginx 服务暴露给外部：
kubectl expose deployment nginx --type=loadBalancer --port=80 --target-port=80
使用 kubectl get svc 查看生成的 service，供外部访问的 IP 地址从 EXTERNAL-IP 处获得：35.233.45.209：
在浏览器里直接访问这个 ip 地址，看到 nginx 默认的首页，说明部署在 Google Cloud Platform 上的 Kubernetes cluster 能够正常工作了。
练习3 - 如何使用 Kubernetes 的 configmap 通过环境变量注入到 pod 里
在 Kubernetes 官网里，提到了 Kubernetes 里的一个最佳实践就是把应用代码同配置信息分开，一种方式就是使用 Kubernetes 1.2 里引入的 configmap 概念。
configmap实际上就是一系列键值对，存储于 etcd 里。etcd 的官网有这样一句话：
etcd is a distributed key-value store designed to reliably and quickly preserve and provide access to critical data.
etcd 是一个高性能的分布式键值对存储库，用于存储和访问关键数据。
使用下面的命令行创建一个 Kubernetes config map：
kubectl create configmap test-config --from-literal=test.type=unit --from-literal=test.exec=always
创建一个名为 test-config 的键值对，key 为 test.type，值为 unit，key 为 test.exec, 值为 always。
下面我打算创建一个 pod，消费这个名为 test-config 的 configmap.
创建一个内容如下的 yaml 文件：
apiVersion: v1 kind: Pod metadata: name: test-configmap spec: containers: - name: test-container image: alpine:3.8 command: [ "/bin/sh", "-c", "env" ] env: - name: TEST_TYPE valueFrom: configMapKeyRef: name: test-config key: test.type - name: TEST_EXEC valueFrom: configMapKeyRef: name: test-config key: test.exec restartPolicy: Never
这个 yaml 文件定义的 pod 基于 docker 镜像 alpine，执行 shell 命令 /bin/sh -c env 查看环境变量。
在 env 区域，我给该 pod 注入一个名为 TEST_TYPE 的环境变量，值从 configMap 键值对的键名称为 test.type 的值中取。
kubectl create -f 创建这个 pod：
使用命令 kubectl logs test-configmap 查看这个 pod 运行生成的日志，发现输出的环境变量列表中，出现了 TEST_TYPE=unit，这个 TEST_TYPE 是我在 yaml 文件里注入的环境变量名称，而 unit 就来自 configmap 里 test-config 的值 unit。
总结
本文作为该系列的第三篇文章，首先学习了如何使用 describe 这个常用命令来深入学习 pod 的属性和一些常见故障的排查工作，接着通过 ConfigMap 使用方法的学习，了解了 Kubernetes 世界里应用代码同配置信息相分离的这一最佳实践，最后学习了使用开源项目 Gardener 在云平台上创建 Kubernetes 集群的步骤，希望对大家有所帮助。
本系列前两篇文章包含的练习，请参阅之前的文章：
本系列的前两篇文章：
