关于kubernetes:适合-Kubernetes-初学者的一些实战练习二

53次阅读

共计 3729 个字符,预计需要花费 10 分钟才能阅读完成。

本系列的第一篇文章,咱们学习了每一个 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 不能启动的理论问题。

正文完
 0