本系列的第一篇文章，咱们学习了每一个 Kubernetes 从业者的理论工作中简直都会应用的步骤：创立 Deployment 和 Service，同时通过理论例子解说了 Pod 和 Service 绑定的实现形式，介绍了应用 Kubernetes Job 计算圆周率这种费时的操作。
本文作为 Kubernetes 学习系列的第二篇文章，咱们持续学习 XX.
练习 1 – 应用脚本在 Linux 服务器上主动装置 Kubernetes 的包管理器 Helm
Helm 之于 Kubernetes 好比 yum 之于 Red Hat Enterprise Linux，或者 apt-get 之于 Ubuntu.
Helm 是由 helm CLI 和 Tiller 组成，是典型的 Client/Server 利用。helm 运行于客户端，提供命令行界面；Tiller 利用运行于 Kubernetes 外部。
本练习应用一种全自动的做法，应用装置脚本主动装置。
(1) 主动下载安装脚本
curl https://raw.githubusercontent… > get_helm.sh
关上脚本，能够看到 helm 装置的环境变量 HELM_INSTALL_DIR 为 /usr/local/bin:
(2) chmod 700 get_helm.sh
./get_helm.sh:
(3) 执行 helm init, 看到 Happy Helming 音讯，阐明装置胜利。
练习 2 – 一个简略的例子了解 Kubernetes 的三种 IP 地址类型
很多 Kubernetes 的初学者对 Kubernetes 外面三种不同的 IP 地址和工作机制了解得不是很分明。
本练习咱们通过一个最简略的例子来学习。
用如下命令行创立一个基于 nginx 的 deployment：
kubectl run nginx –image=nginx:maxline
用 kubectl get deploy 查看胜利生成的名为 nginx 的 deployment：
此时这个 deployment 里的 nginx pod 还无奈对外界提供服务。
咱们创立一个 service 让外界可能生产。应用命令行创立这样的一个 service：
kubectl expose deployment nginx –type=LoadBalancer –port=80 –target-port=80
type 的类型抉择为 LoadBalancer，–port 指定的是 80 端口，意思是这个 service 对外界裸露进去的服务端口是 80，–target-port=80，这个端口是 pod 外部的 nginx docker 容器提供服务的工作端口，默认为 80。这里实际上建设了向外界开发的 80 端口同 nginx 容器外部端口的一个映射关系。
执行结束后，咱们调用上面的命令行，看到了创立的 service 的 Cluster IP 和 External IP.
其中 external IP 很好了解，这个 service 通过 external IP 加上咱们后面介绍的被映射到 80 端口向外界提供服务：
浏览器里输出 External IP http://35.241.173.27:80, 能胜利拜访 nginx 服务器的 index.html:
而咱们通过 Service 的 Cluster IP 是无法访问这个 Service 提供的性能的。
咱们晓得 Kubernetes 里的所有 pod 都能够彼此通信，而不须要通过网络地址转换（Network Address Translation-NAT），所有的节点也能够与所有的 pod 通信。而 Service 的 Cluster IP，是一个外部的 IP 地址，专门用于同 Cluste r 外部的节点或者 pod 通信。同外界通信，还是通过 External IP 进行。
接下来再试试 NodePort.
kubectl expose deployment nginx –type=NodePort –port=80 –target-port=80
留神看下图的 PORT 栏上面显示的类型为 NodePort 的端口：31375
这个端口号是 Kubernetes expose 命令主动生成的，范畴在 30000 到 32767 之间。如果须要批改，能够编辑 api server 的配置文件：/etc/kubernetes/apiserver:
有了这个端口号，咱们轻易应用一个 node 的 IP 地址，前面拼接上 :31375 即是内部能够生产的残缺地址。
应用命令行 kubectl get nodes -o wide, 在后果里抉择任意节点的 External-IP，前面加上:31375:
测试：
http://146.148.23.183:31375/
测试通过。
接下来持续学习 Pod 的端口转发性能。
值得一提的是，有时咱们出于测试的目标，须要一种简略的方法查看一个 pod 是否能失常提供服务。如果每次通过 kubectl 的形式创立 service 就太麻烦了。
本练习介绍一种简略的方法：pod 的端口转发性能（port forward）。
比方咱们想测试下图 get pods 返回的第一个 pod 的性能，名称为 nginx-6f754dd4b9-74jdn：
执行命令行 kubectl port-forward pod/nginx-6f754dd4b9-74jdn 8080:80
看到提示信息 Forwarding from 127.0.0.1:8080 -> 80, 意思是把以后主机的 8080 端口映射到 nginx pod 的 80 工作端口：
最初，就可能通过 localhost:8080 间接拜访 nginx pod 提供的服务了：
练习 3 – 应用 describe 命令进行 Kubernetes pod 谬误排查
我有一个 pod 名叫 another，用 kubectl create 创立后发现过了 29 分钟，状态还是处于 ContainerCreating 阶段。
应用 kubectl describe 命令查看：
从谬误音讯发现是因为这个 pod attach volume 失败：
FailedAttachVolume 2m1s (x22 over 31m) attachdetach-controller AttachVolume.Attach failed for volume “pvc-c4d41f5c-e7ed-11e8-8726-fe6d42bf075f” : googleapi: Error 400: RESOURCE_IN_USE_BY_ANOTHER_RESOURCE – The disk resource ‘projects/sap-pi-coo-acdc-dev/zones/europe-west1-b/disks/shoot–k8s-train–shac-pvc-c4d41f5c-e7ed-11e8-8726-fe6d42bf075f’ is already being used by ‘projects/sap-pi-coo-acdc-dev/zones/europe-west1-b/instances/shoot–k8s-train–shacw46-worker-prvfv-z1-7844dc6744-ghd5m’
Warning FailedMount 31s (x14 over 29m) kubelet, shoot–k8s-train–shacw46-worker-prvfv-z1-7844dc6744-hhrmd Unable to mount volumes for pod “another_part-0110(13f15fa4-e819-11e8-8726-fe6d42bf075f)”: timeout expired waiting for volumes to attach or mount for pod “part-0110″/”another”. list of unmounted volumes=[content-storage]. list of unattached volumes=[content-storage default-token-6z5sk]
依据下面的谬误音讯顺藤摸瓜，查看这个 pod 的 yaml 文件，果然发现有一个 persistent volume 的 claim：
用命令 kubectl get pv, 发现以后所有的 persistent volume 都被占用了（BOUND 状态）：
解决方案有很多种，出于测试目标，我只是简略地将另一个同样申明了 nginx-pvc 作为 PersistentVolumeClaim 的 pod 删除，而后这个名为 another 的 pod 状态就很快变成 Running 了：
从 describe 命令生成的日志里也能分明的察看到这个胜利 mount volume 的事件：
Normal SuccessfulAttachVolume 84s attachdetach-controller AttachVolume.Attach succeeded for volume “pvc-c4d41f5c-e7ed-11e8-8726-fe6d42bf075f”
总结
继本系列第一局部 介绍了 Kubernetes 创立 Pod 和 Service 的根底操作，以及 Pod 和 Service 绑定的实现原理后，本文作为该系列的第二局部，分享了 Kubernetes 包管理器 Helm 的装置形式，以及 Kubernetes 三种 IP 类型，最初介绍了如何应用 describe 命令剖析一个 Pod 不能启动的理论问题。