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

5次阅读

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

本系列的前两篇文章：

适宜 Kubernetes 初学者的一些实战练习 (一)
适宜 Kubernetes 初学者的一些实战练习 (二)

咱们曾经实现了下列在 Kubernetes 中的练习：

如何在 Kubernetes 里创立一个 Nginx 利用
如何在 Kubernetes 里创立一个 Nginx Service
Kubenetes 里 Pod 和 Service 绑定的实现形式
应用 Kubernetes 里的 job 计算圆周率后 2000 位
Kubernetes 里的 ConfigMap 的用处
应用脚本在 Linux 服务器上主动装置 Kubernetes 的包管理器 Helm
一个简略的例子了解 Kubernetes 的三种 IP 地址类型
应用 describe 命令进行 Kubernetes pod 谬误排查

本文持续通过实战来学习 Kubernetes 相干常识。

咱们能够首先应用 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 了：

Gardener 是一个开源我的项目，github 地址在这里.

应用 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 可能失常工作了。

在 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 集群的步骤，心愿对大家有所帮忙。

本系列前两篇文章蕴含的练习，请参阅之前的文章：

本系列的前两篇文章：