共计 3808 个字符，预计需要花费 10 分钟才能阅读完成。
本系列记录了笔者刚刚接触并学习 Kubernetes 时动手做过的一些练习，这里分享出本人的 Kubernetes 学习历程，心愿对宽广 Kubernetes 初学者有所帮忙。
练习 1 – 如何在 Kubernetes 里创立一个 Nginx 利用
应用命令行 kubectl run –image=nginx nginx-app –port=80 创立一个名为 nginx-app 的利用
后果: deployment.apps/nginx-app created
应用命令行 kubectl get pods 查看创立后果，状态曾经为 running：
应用命令行 kubectl describe pods 查看 pod 明细：
把 pod id 记下来: nginx-app-f75d46bd9-q6c76
应用该 pod id 能够执行一些命令：
- kubectl exec nginx-app-f75d46bd9-q6c76 ps aux
- kubectl describe pod nginx-app-f75d46bd9-q6c76
- kubectl logs nginx-app-f75d46bd9-q6c76
练习 2 – 如何在 Kubernetes 里创立一个 Nginx Service
前一个练习，咱们曾经应用 kubectl 命令行创立了 Pod，然而在 kubernetes 中，Pod 的 IP 地址会随着 Pod 的重启而变动，因而用 Pod 的 IP 地址来拜访咱们部署的 nginx 利用不太适合。
Kubernetes 里举荐的形式是用 Service 来生产 nginx 服务。
Service 为一组 Pod 提供一个对立的入口，并为它们提供负载平衡和服务发现反对。
应用如下命令行基于 pod 创立一个 service：
kubectl expose deployment nginx-app –type=NodePort –port=80
收到 service/nginx-app exposed 音讯。
应用命令行拿到创立胜利的 service 的明细：
kubectl describe service nginx-app
应用 http://<node_id>:32624 拜访这个 nginx 利用：
看到上图阐明拜访 nginx 胜利了。
应用命令行查看 nginx 拜访日志：
kubectl logs nginx-app-f75d46bd9-q6c76
练习 3 – Kubenetes 里 Pod 和 Service 绑定的实现形式
前一个练习，咱们介绍了如何创立一个 Kubernetes pod 和 service，应用的办法是命令 kubectl run.
本文介绍另一种形式，通过这种形式来学习 Kubernetes 里 pod 和对应的 service 是如何绑定的。
首先应用上面的命令行创立一个名称为 jerry-nginx-1982 的 deployment：
kubectl create deployment jerry-nginx-1982 –image=nginx
而后应用命令行 kubectl get deployment 失去创立好的 deployment：
而后创立一个同名的 service，类型为 nodeport.
kubectl create service nodeport jerry-nginx-1982 –tcp 80:80
创立实现后，应用命令行 kubectl get svc 失去名称为 jerry-nginx-1982 对外裸露的端口号：31954：
而后就能通过这个端口号拜访 nginx server 了：
那么这两个同名的 pod 和 service 是如何关联的呢？
首先关上 kubernetes dashboard，找到之前创立的 pod：
其明细为：jerry-nginx-1982-67cb658cb8-9hl99
再关上同名 service：
再关上这个 service 里的 pod，发现就是咱们后面找到的 jerry-nginx-1982-67cb658cb8-9hl99，阐明 pod 和 service 是通过名称关联的。
咱们能够做一个 negative 测试，间接创立一个名为 test 的 service，但不给它事后创立名为 test 的 pod：
kubectl create service nodeport test –tcp 80:80
service 创立胜利后，关上这个 service，发现外面没有调配任何 pod：
这个后果和咱们预测的统一。
练习 4 – 应用 Kubernetes 里的 job 计算圆周率后 2000 位
应用 Kubernetes 里的 job（作业），咱们能够很不便地执行一些比拟耗时的操作。
新建一个 job.ymal 文件：
定义了一个 Kubernetes job，名称为 pi，类型为 job，容器名称为 pi，镜像为 perl，执行的 perl 命令为 print bpi(2000):
这个 ymal 文件的残缺内容：
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
name: pi
spec:
containers:
name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never 应用命令 kubectl create -f 导入这个 yaml 文件，创立一个新的 job：
之后在 Kubernetes 的 dashboard 里能看到这个新建的 job：
job 对应的 pod 状态为 Waiting ContainerCreating：
稍后，其状态从 Running 变为了 Terminated：Completed，总共花了 14 分钟。
在 pod 的事件日志里，能看到大部分工夫花在了 perl 镜像的下载上：
点击 dashboard 的 logs 按钮，就能看到这个 2000 位圆周率的计算结果：
练习 5 – Kubernetes 里的 ConfigMap 的用处
顾名思义，ConfigMap 用于保留配置数据的键值对，能够用来保留单个属性，也能够用来保留配置文件。
ConfigMap 同 Kubernetes 的另一个概念 secret 相似，区别是 ConfigMap 次要用于保留不蕴含敏感信息的明文字符串。
创立形式：
kubectl create configmap special-config –from-literal=i042416=jerry
上述命令行创立了一个名为 special-config 的键值对，
key 为 i042416, 值为 jerry
接下来我心愿用这个 key 为 i042416 的值 ”jerry” 来定义成 pod 里的一个环境变量。
上面是我的 yaml 文件：
apiVersion: v1
2 kind: Pod
3 metadata:
4 name: jerry-config-pod
5 spec:
6 containers:
7 - name: test-container
8 image: http://gcr.io/google_containers/busybox
9 command: ["/bin/sh", "-c", "env"]
10 env:
11 - name: JERRY_NAME
12 valueFrom:
13 configMapKeyRef:
14 name: special-config
15 key: i042416
16 restartPolicy: Never能够看到第 15 行援用了我的 ConfigMap 的 key：i042416
上面应用 create -f 将该 yaml 文件导入，创立一个新的 pod：
创立之后，能在 pod 的明细页面看到 configMap 的 key 曾经作为环境变量显示进去了：
因为我 yaml 文件里指定 pod 执行的 script 为 /bin/sh -c env, 因而最初会将容器里所有的环境变量都打印进去，咱们定义在 ConfigMap 里的 i042416 的值 jerry 也被显示了进去：
这种定义环境变量的做法和 SAP 云平台 CloudFoundry 环境里定义环境变量的形式很相似。
CloudFoundry 环境变量一览表：
https://docs.run.pivotal.io/d…
- CF_INSTANCE_ADDR
- CF_INSTANCE_GUID
- CF_INSTANCE_INDEX
- CF_INSTANCE_IP
- CF_INSTANCE_INTERNAL_IP
- CF_INSTANCE_PORT
- CF_INSTANCE_PORTS
- DATABASE_URL
- HOME
- LANG
- MEMORY_LIMIT
- PORT
- PWD
- TMPDIR
- USER
- VCAP_APP_PORT
- VCAP_APPLICATION
- VCAP_SERVICES
当应用 cf push 命令将本地利用部署到 SAP 云平台的 CloudFoundry 环境下时，某些环境变量会主动被零碎写入相应的值，这个行为同 ABAP 的 sy-sysid 主动被设置为以后零碎 ID 具备一样的逻辑。
比方 app router 会把用户拜访申请重定向到 XSUAA 实例上。
app router 在 manifest.yml 里定义的 XSUAA 实例名称为 xsuaa-jerry-demo，
在运行时这个 XSUAA 的 id 会被 SAP 云平台主动写入环境变量 VCAP_SERVICES 里：
总结
本文介绍了每一个 Kubernetes 从业者的理论工作中简直都会应用的步骤：创立 Deployment 和 Service，同时通过理论例子解说了 Pod 和 Service 绑定的实现形式，介绍了应用 Kubernetes Job 计算圆周率这种费时的操作，心愿对 Kubernetes 初学者能有所帮忙。
