Kubernetes学习路上的那些事儿,很有必要分享出来
![70dc538af7f4d940012db29d9894726f.png](https://i-blog.csdnimg.cn/blog_migrate/a8bfc486af3d10a1c6d8ec798088b525.jpeg)
![8c7cae4f31f4f9004e4e27264ec0d752.png](https://i-blog.csdnimg.cn/blog_migrate/5a190dac0a31c0f4431f78b68395ace5.jpeg)
什么是Pod
要弄清楚这个概念,我们还是先上官网瞧瞧,https://kubernetes.io/zh/docs/concepts/workloads/pods/
![1da289e62619b5f829a52473e7e1ef65.png](https://i-blog.csdnimg.cn/blog_migrate/220de9c2da89f7ca89c87fa8a6809b5e.jpeg)
个人的理解,Pod就是k8s中的一个个篮子,至于里面是装韭菜,还是装鸡蛋,得根据具体的业务环境要求来定。在k8s世界中,重点是把这些篮子调度和管理好,所以得首先学Pod,只有理解和掌握了Pod,后面的一些k8s组件学习起来才有意思。
实操过程
实验准备:
Kubernetes集群环境一套,可以选择在本地虚拟机(VirtualBox)上搭建,也可以选择在公有云上利用云主机来搭建,比如移动云、阿里云、腾讯云、华为云等。
当然,在生产环境中,肯定建议直接使用服务器进行搭建。以下是我的实验环境,1台master节点,2台node节点。
![66655ccf38993f259eb1203b15e725c8.png](https://i-blog.csdnimg.cn/blog_migrate/fe9723f19dce0fdf6194d16c84d5553a.jpeg)
步骤一:编写Pod的yaml文件。因为在k8s中是“声明式”命令,通过编写的yaml文件来实现组件的操作。
在Master节点的当前环境下,先编写一个名字叫“pod1.yaml”的文件,具体代码如下:
apiVersion: v1kind: Podmetadata: name: pod1 namespace: default labels: evn: dev res: stablespec: containers: - name: testpod-dev image: nginx ports: - containerPort: 80
还是那句老话,先别慌,会奉上详细的解释的,如下图:
![7b1551ebc29e2ab90d1569738ea018a6.png](https://i-blog.csdnimg.cn/blog_migrate/e77fdf2ac22fa51ff77ecf8b5d899cff.jpeg)
步骤二:提交yaml文件并创建Pod。在这个小实验里,只创建了一个Pod,且该Pod中只有一个容器,该容器安装的是nginx最新版本的镜像,也就是部署了一个nginx容器。
kubectl apply -f pod1.yamlkubectl get pod
由于我做实验的环境设置的带宽低,所以拉取镜像的过程比较长一些,如果运行正常,获取的Pod状态是Running。如果是非Running的状态,可使用kubectl describe pod pod1命令来查看pod1的运行信息,以便找到问题,然后解决问题。
![40f8152f3f0ed30bfbca286784266126.png](https://i-blog.csdnimg.cn/blog_migrate/dfe1f3df0b0a123d98d1198d8106b4fa.jpeg)
![e6c7332f47b77be2a8031dfd31eb9113.png](https://i-blog.csdnimg.cn/blog_migrate/d8c3f3daacdae4380b7c628fb604387f.jpeg)
步骤三:验证结果。可以使用kubectl命令行直接进入Pod内,然后查看nginx安装文件。如果想使用curl命令看nginx欢迎页面信息,单独操作Pod是不行的,需要配合Service组件来使用,后续会单独分享Service。毕竟k8s是集群调度,无论是从物理层面的“垂直维度”,还是从编排层面的“水平维度”,都是做了隔离的,这跟单独操作虚拟机还是有较大区别的。
kubectl exec -it pod1 -c testpod-dev -- /bin/bash //pod1是本实验的Pod名称,testpod-dev是本实验pod1中的容器名称,该docker容器部署了nginx
![fdd76a1d5c63a6608e9dccbd0221519b.png](https://i-blog.csdnimg.cn/blog_migrate/29d54189324ef016e4d537698e375819.jpeg)
以上红色方框中的配置文件,就是咱们熟悉的nginx配置文件了,/conf.d/default.conf中可以修改监控端口(默认是80),nginx.conf中可以修改worker_processes的数量。
步骤四:一个Pod中部署多个docker容器。这里就开始体现k8s的好处了,只需要在原来的pod1.yaml文件上里的spec语句块中,继续增加容器规格参数即可。为了方便对比,增加了代码的文件叫pod-1.yaml,同时名称定义为pod-1。
![974230306e475d2919499f2f56864ec2.png](https://i-blog.csdnimg.cn/blog_migrate/9175addf285964cd57bb4fb74c1f234f.jpeg)
然后使用同样的命令,创建pod-1。
kubectl apply -f pod-1.yaml //增加了my-tomcat容器的yaml文件kubectl get pod //查看pod状态,直到状态变成Running
![a9b8bb5a7fd46f5dc612716c81bca979.png](https://i-blog.csdnimg.cn/blog_migrate/bf54e35d79885a0c1c22db46f6a15bd9.jpeg)
做个对比,pod1中只有一个docker容器,而pod-1中有两个docker容器。
![6fdf6f2a06b0e05d273ff33bc2632e91.png](https://i-blog.csdnimg.cn/blog_migrate/5280d1efd3193c80611bb2a032073d6a.jpeg)
![4c462a649e5a75309f9a301e8c33a2dd.png](https://i-blog.csdnimg.cn/blog_migrate/7b68734e37f5bf80639a5ff057b8d2b1.jpeg)
步骤五:在Pod中限制docker容器的资源使用。操作也很简单,仍然是通过修改yaml文件的相应配置区来实现。
为了好做对比,在pod1.yaml基础上复制一个pod11.yaml文件,然后增加资源设置语句块。
![e3eaa3a31efd618d0b09e39e0ece413a.png](https://i-blog.csdnimg.cn/blog_migrate/4cfb2b827cecf60b4bbab91971643e0e.jpeg)
然后让pod1(没有设置资源限制)和pod-11(设置了资源限制)都Running起来,然后使用命令查看当前Node上的运行情况。
kubectl get pod -o wide //查看pod在哪些Node上kubectl describe node k8s-node2 //查看k8s-node2这个Node上的运行信息
![7ff5c24a85d7923df7b852d10739cf8f.png](https://i-blog.csdnimg.cn/blog_migrate/5c4608249a71c0c794bfbc5170cd3177.jpeg)
扩展内容
1)实验环境的对比,公有云VS本地虚拟机
如果使用公有云上的云主机搭建环境,好处是“一次部署,永久运行”,想做实验的时候,马上登陆云主机即可,不好的地方是要注意安全组的配置,注意端口的放通,如果为了省事儿也可以将所有端口放通,但因为是公有云又容易被攻击。
如果使用本地虚拟机环境搭建,好处是不用配置安全组,也不用担心80,8080这些常用的web端口进行备案,不好的地方就是PC要关机,虚拟机环境自然要关机,由于无线网络ip地址变化,每次启动虚拟机环境后需要捣鼓网络,因为既要能够上公网(为了能够从公共镜像仓库拉取镜像),也要保证节点注册不受影响。
2)Pod中其它配置项
Pod中可配置项很多,本实验只是列举了一部分,主要目的是简单介绍如何使用Pod。在k8s中直接操作Pod的机会不多,更多的是通过deployment,ReplicationController,ReplicaSet,Service,Job等组件来自动调度和操作Pod。
更多配置项及解释可参照如下:(转自网络:https://www.jianshu.com/p/35dde2b1951b )
apiVersion: v1 #指定api版本,此值必须在kubectl apiversion中 kind: Pod #指定创建资源的角色/类型 metadata: #资源的元数据/属性 name: web04-pod #资源的名字,在同一个namespace中必须唯一 labels: #设定资源的标签,详情请见http://blog.csdn.net/liyingke112/article/details/77482384 k8s-app: apache version: v1 kubernetes.io/cluster-service: "true" annotations: #自定义注解列表 - name: String #自定义注解名字 spec:#specification of the resource content 指定该资源的内容 restartPolicy: Always #表明该容器一直运行,默认k8s的策略,在此容器退出后,会立即创建一个相同的容器 nodeSelector: #节点选择,先给主机打标签kubectl label nodes kube-node1 zone=node1 zone: node1 containers: - name: web04-pod #容器的名字 image: web:apache #容器使用的镜像地址 imagePullPolicy: Never #三个选择Always、Never、IfNotPresent,每次启动时检查和更新(从registery)images的策略, # Always,每次都检查 # Never,每次都不检查(不管本地是否有) # IfNotPresent,如果本地有就不检查,如果没有就拉取 command: ['sh'] #启动容器的运行命令,将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT args: ["$(str)"] #启动容器的命令参数,对应Dockerfile中CMD参数 env: #指定容器中的环境变量 - name: str #变量的名字 value: "/etc/run.sh" #变量的值 resources: #资源管理,请求请见http://blog.csdn.net/liyingke112/article/details/77452630 requests: #容器运行时,最低资源需求,也就是说最少需要多少资源容器才能正常运行 cpu: 0.1 #CPU资源(核数),两种方式,浮点数或者是整数+m,0.1=100m,最少值为0.001核(1m) memory: 32Mi #内存使用量 limits: #资源限制 cpu: 0.5 memory: 32Mi ports: - containerPort: 80 #容器开发对外的端口 name: httpd #名称 protocol: TCP livenessProbe: #pod内容器健康检查的设置,详情请见http://blog.csdn.net/liyingke112/article/details/77531584 httpGet: #通过httpget检查健康,返回200-399之间,则认为容器正常 path: / #URI地址 port: 80 #host: 127.0.0.1 #主机地址 scheme: HTTP initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始 timeoutSeconds: 5 #检测的超时时间 periodSeconds: 15 #检查间隔时间 #也可以用这种方法 #exec: 执行命令的方法进行监测,如果其退出码不为0,则认为容器正常 # command: # - cat # - /tmp/health #也可以用这种方法 #tcpSocket: //通过tcpSocket检查健康 # port: number lifecycle: #生命周期管理 postStart: #容器运行之前运行的任务 exec: command: - 'sh' - 'yum upgrade -y' preStop:#容器关闭之前运行的任务 exec: command: ['service httpd stop'] volumeMounts: #详情请见http://blog.csdn.net/liyingke112/article/details/76577520 - name: volume #挂载设备的名字,与volumes[*].name 需要对应 mountPath: /data #挂载到容器的某个路径下 readOnly: True volumes: #定义一组挂载设备 - name: volume #定义一个挂载设备的名字 #meptyDir: {} hostPath: path: /opt #挂载设备类型为hostPath,路径为宿主机下的/opt,这里设备类型支持很多种