上回说到,小X在方老师的引导下,开始学习容器技术。
这天,小X开发了一个应用,叫TRUMP-Gambling,可以开盘口预测,那个人气最高的新冠患者会不会因为这个而去见华盛顿。当然,小X采用的是流行的Web-App-DB三层架构。
为了试一下牛刀,小X决定,把TRUMP-Gambling应用部署在容器上。
三层架构如下所示:
如图,Nginx作为Web前端,作用是呈现一个页面,可以在页面上选择自己的预测;
而Tomcat里面运行着小X编写的Java程序,实现了简单的计算赔率和拉起支付等功能;
DB则使用MySQL实现,储存着每个人的下注记录。
小X将TRUMP-Gambling的三个组件在开发测试环境里面开发好以后,利用 docker commit命令将三个组件制作成镜像,并提交到自己私有的镜像仓库,再切换到生产环境,使用docker pull和docker run命令,大家就可以愉快地预测特没谱会不会成为第一个由于新冠挂掉的现任国家元首啦。
小X吸取上次特没谱被肖战XX导致感染新冠的教训,这次打算用kubernetes来部署容器,以实现所谓的容器自动伸缩。她想起方老师经常说的一句话:
"要知其然,更要知其所以然!"
她下载了一个tuber浏览器,在四个自信的指导下投入到学习kubernetes强国的洪流中。
这一下,小X发现了一个惊天秘密——
原来,kubernetes实际上并不创建和运行容器。它只是容器的搬运工。
当小X需要运行容器镜像 trump_gambling_app的时候,可以输入这条命令:
little_x@centos8:~$ sudo docker run -it trump_gambling_app
对于需要运行10个同样的实例的情况下,小x需要将这个命令进行变换(想一想,变换哪里?这个问题下期解答)以后,键入10遍命令。
当然,为了将这10个容器的实例组成一个集群,实现负载分担及HA,小x还需要手工配置iptables的负载均衡(反向NAT)。
而kubernetes却可以代替小X键入重复的命令,只需要预先配置好yaml文件:
trump_gambling_app.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: trump_gambling_app
labels:
name: trump_gambling_app
spec:
containers:
- name: trump_gambling_app
image: trump_gambling_tomcat:v1
ports:
- containerPort: 8080
然后,在命令行中输入命令:
#kubectl create -f trump_gambling_app.yaml
这时,通过命令
#kubectl get pods
就可以查看目前运行的容器了。
我们注意到,kubernetes调度容器的基本单位是pod,而不是container。当然,在我们目前的阶段,可以将pod视为与container等价。
实际上,kubernetes的kubectl create这条命令,正是调用了docker等容器运行时平台执行的。
从kubectl到docker之间信息的传递,就是我们这个专题的主角——cri (container runtime interface)。
在下一期中,我们开始详解cri的机制。