020.掌握Pod-Pod基础使用

一 Pod定义详解

1.1 完整Pod定义文件

  1 apiVersion: v1			#必选,版本号,例如v1,版本号必须可以用 kubectl api-versions 查询到
  2 kind: Pod				#必选,Pod
  3 metadata:				#必选,元数据
  4   name: string			#必选,Pod名称,需符合RFC 1035规范
  5   namespace: string			#必选,Pod所属的命名空间,默认为"default"
  6   labels:				#自定义标签
  7     - name: string			#自定义标签名字
  8   annotations:			#自定义注释列表
  9     - name: string
 10 spec:				#必选,Pod中容器的详细定义
 11   containers:			#必选,Pod中容器列表
 12   - name: string			#必选,容器名称,需符合RFC 1035规范
 13     image: string			#必选,容器的镜像名称
 14     imagePullPolicy: [ Always|Never|IfNotPresent ]	#获取镜像的策略,Alawys表示每次都尝试下载镜像,IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像
 15     command: [string]		#容器的启动命令列表,如不指定,使用打包时使用的启动命令
 16     args: [string]			#容器的启动命令参数列表
 17     workingDir: string		#容器的工作目录
 18     volumeMounts:			#挂载到容器内部的存储卷配置
 19     - name: string			#引用pod定义的共享存储卷的名称,需用volumes[]部分定义的的卷名
 20       mountPath: string		#存储卷在容器内mount的绝对路径,应少于512字符
 21       readOnly: boolean		#是否为只读模式,默认为读写模式
 22     ports:				#需要暴露的端口库号列表
 23     - name: string			#端口的名称
 24       containerPort: int		#容器需要监听的端口号
 25       hostPort: int		        #容器所在主机需要监听的端口号,默认与Container相同
 26       protocol: string		#端口协议,支持TCP和UDP,默认TCP
 27     env:				#容器运行前需设置的环境变量列表
 28     - name: string			#环境变量名称
 29       value: string		        #环境变量的值
 30     resources:			#资源限制和请求的设置
 31       limits:			#资源限制的设置
 32         cpu: string		        #CPU的限制,单位为core数,将用于docker run --cpu-shares参数
 33         memory: string		#内存限制,单位可以为Mib/Gib,将用于docker run --memory参数
 34       requests:			#资源请求的设置
 35         cpu: string		        #CPU请求,容器启动的初始可用数量
 36         memory: string		#内存请求,容器启动的初始可用数量
 37     livenessProbe:			#对Pod内各容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可
 38       exec:			        #对Pod容器内检查方式设置为exec方式
 39         command: [string]		#exec方式需要制定的命令或脚本
 40       httpGet:			#对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、port
 41         path: string
 42         port: number
 43         host: string
 44         scheme: string
 45         HttpHeaders:
 46         - name: string
 47           value: string
 48       tcpSocket:			#对Pod内个容器健康检查方式设置为tcpSocket方式
 49          port: number
 50        initialDelaySeconds: 0	#容器启动完成后首次探测的时间,单位为秒
 51        timeoutSeconds: 0		#对容器健康检查探测等待响应的超时时间,单位秒,默认1秒
 52        periodSeconds: 0		#对容器监控检查的定期探测时间设置,单位秒,默认10秒一次
 53        successThreshold: 0
 54        failureThreshold: 0
 55        securityContext:
 56          privileged: false
 57     restartPolicy: [Always | Never | OnFailure]	#Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该Pod
 58     nodeSelector: obeject		#设置NodeSelector表示将该Pod调度到包含这个label的node上,以key:value的格式指定
 59     imagePullSecrets:		#Pull镜像时使用的secret名称,以key:secretkey格式指定
 60     - name: string
 61     hostNetwork: false		#是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
 62     volumes:			#在该pod上定义共享存储卷列表
 63     - name: string			#共享存储卷名称 (volumes类型有很多种)
 64       emptyDir: {}			#类型为emtyDir的存储卷,与Pod同生命周期的一个临时目录。为空值
 65       hostPath: string		#类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
 66         path: string		#Pod所在宿主机的目录,将被用于同期中mount的目录
 67       secret:			#类型为secret的存储卷,挂载集群与定义的secre对象到容器内部
 68         scretname: string
 69         items:
 70         - key: string
 71           path: string
 72       configMap:			#类型为configMap的存储卷,挂载预定义的configMap对象到容器内部
 73         name: string
 74         items:
 75         - key: string
 76           path: string

二 Pod的基本用法

2.1 创建Pod

Pod可以由1个或多个容器组合而成,通常对于紧耦合的两个应用,应该组合成一个整体对外提供服务,则应该将这两个打包为一个pod。

属于一个Pod的多个容器应用之间相互访问只需要通过localhost即可通信,这一组容器被绑定在一个环境中。

  1 [root@k8smaster01 study]# vi frontend-localredis-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: redis-php
  6   label:
  7     name: redis-php
  8 spec:
  9   containers:
 10   - name: frontend
 11     image: kubeguide/guestbook-php-frontend:localredis
 12     ports:
 13     - containersPort: 80
 14   - name: redis-php
 15     image: kubeguide/redis-master
 16     ports:
 17     - containersPort: 6379
 18 
 19 [root@k8smaster01 study]# kubectl create -f frontend-localredis-pod.yaml
 20 

2.2 查看Pod

  1 [root@k8smaster01 study]# kubectl get pods	                #READY为2/2,表示此Pod中运行了yaml定义的两个容器
  2 NAME        READY   STATUS    RESTARTS   AGE
  3 redis-php   2/2     Running   0          7m45s
  4 [root@k8smaster01 study]# kubectl describe pod redis-php	#查看详细信息
  5 

三 静态Pod

3.1 静态Pod概述

静态pod是由kubelet进行管理的仅存在于特定Node的Pod上,他们不能通过API Server进行管理,无法与ReplicationController、Deployment或者DaemonSet进行关联,并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建,并且总是在kubelet所在的Node上运行。

创建静态Pod有两种方式:配置文件或者HTTP方式。

3.2 配置文件方式创建

  1 [root@k8snode01 ~]# mkdir -p /etc/kubelet.d
  2 [root@k8snode01 ~]# vi /etc/kubelet.d/static-web.yaml
  3 apiVersion: v1
  4 kind: Pod
  5 metadata:
  6   name: static-web
  7   label:
  8     name: static-web
  9 spec:
 10   containers:
 11   - name: static-web
 12     image: nginx
 13     ports:
 14     - name: web
 15       containersPort: 80
 16 
 17 [root@k8snode01 ~]# vi /etc/systemd/system/kubelet.service
 18 ……
 19   --config=/etc/kubelet.d/ \·				#加入此参数
 20 ……
 21 [root@k8snode01 ~]# systemctl daemon-reload
 22 [root@k8snode01 ~]# systemctl restart kubelet.service	#重启kubelet
 23 [root@k8snode01 ~]# docker ps				#查看创建的pod

提示:由于静态pod不能通过API Server进行管理,因此在Master节点执行删除操作后会变为Pending状态,且无法删除。删除该pod只能在其运行的node上,将定义POD的yaml删除。

3.3 HTTP方式

通过设置kubelet的启动参数--mainfest-url,会定期从该URL下载Pod的定义文件,并以.yaml或.json文件的格式进行解析,从而创建Pod。

四 Pod容器共享Volume

4.1 共享Volume

在同一个Pod中的多个容器能够共享Pod级别的存储就Volume。Volume可以被定义为各种类型,多个容器各自进行挂载操作,将一个Volume挂载为容器内部需要的目录。

示例1:

Pod级别设置Volume “app-logs”,同时Pod包含两个容器,Tomcat向该Volume写日志,busybox读取日志文件。

  1 [root@k8smaster01 study]# vi pod-volume-applogs.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: volume-pod
  6 spec:
  7   containers:
  8   - name: tomcat
  9     image: tomcat
 10     ports:
 11     - containerPort: 8080
 12     volumeMounts:
 13     - name: app-logs
 14       mountPath: /usr/local/tomcat/logs
 15   - name: logreader
 16     image: busybox
 17     command: ["sh","-c","tail -f /logs/catalina*.log"]
 18     volumeMounts:
 19     - name: app-logs
 20       mountPath: /logs
 21   volumes:
 22   - name: app-logs
 23     emptyDir: {}

解释:

Volume名:app-logs;

emptyDir:为Pod分配到Node的时候创建。无需指定宿主机的目录文件,为Kubernetes自动分配的目录。

  1 [root@k8smaster01 study]# kubectl create -f pod-volume-applogs.yaml	#创建
  2 [root@k8smaster01 study]# kubectl get pods				#查看
  3 [root@k8smaster01 study]# kubectl logs volume-pod -c busybox	#读取log
  1 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- ls /usr/local/tomcat/logs
  2 catalina.2019-06-29.log      localhost_access_log.2019-06-29.txt
  3 host-manager.2019-06-29.log  manager.2019-06-29.log
  4 localhost.2019-06-29.log
  5 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- tail /usr/local/tomcat/logs/catalina.2019-06-29.log

提示:通过tomcat容器可查看日志,对比busybox通过共享Volume查看的日志是否一致。

五 Pod配置管理

5.1 Pod配置概述

应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离,使程序更加灵活。将相应的应用打包为镜像,可以通过环境变量或者外挂volume的方式在创建容器的时候进行配置注入,从而实现更好的复用。

Kubernetes提供一种统一的应用配置管理方案:ConfigMap。

5.2 ConfigMap概述

ConfigMap供容器使用的主要场景:

  • 生成容器内部的环境变量;
  • 设置容器的启动命令的参数(需设置为环境变量);
  • 以volume的形式挂载为容器内部的文件或者目录。

ConfigMap以一个或多个key:value的形式定义。value可以是string也可以是一个文件内容,可以通过yaml配置文件或者通过kubectl create configmap 的方式创建configMap。

5.3 创建ConfigMap资源对象——yaml方式

  1 [root@k8smaster01 study]# vi cm-appvars.yaml
  2 apiVersion: v1
  3 kind: ConfigMap
  4 metadata:
  5   name: cm-appvars
  6 data:
  7   apploglevel: info
  8   appdatadir: /var/data
  9 
 10 [root@k8smaster01 study]# kubectl create -f cm-appvars.yaml
 11 configmap/cm-appvars created
 12 [root@k8smaster01 study]# kubectl get configmaps
 13 NAME         DATA   AGE
 14 cm-appvars   2      8s
 15 [root@k8smaster01 study]# kubectl describe configmaps cm-appvars
  1 [root@k8smaster01 study]# kubectl get configmaps cm-appvars -o yaml

5.4 创建ConfigMap资源对象——命令行方式

语法1

  1 # kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source

解释:通过--from-file参数从文件中创建,可以指定key名称,也可以制定多个key。

语法2

  1 # kubectl create configmap NAME --from-file=config-files-dir

解释:通过--from-file参数从目录中创建,该目录下的每个配置文件名都被设置为key,文件的内容被设置为value。

语法3

  1 # kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2

解释:通过--from-literal参数从文本中创建,直接将指定的key#=value#创建为ConfigMap的内容。

5.5 Pod使用ConfigMap

容器应用使用ConfigMap有两种方式:

  • 通过环境变量获取ConfigMap中的内容;
  • 通过Volume挂载的方式将ConfigMap中的内容挂载为容器内容的文件或目录。
  1 [root@k8smaster01 study]# vi cm-test-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: cm-test-pod
  6 spec:
  7   containers:
  8   - name: cm-test
  9     image: busybox
 10     command: ["/bin/sh","-c","env|grep APP"]	#容器里执行查看环境变量的命令
 11     env:
 12     - name: APPLOGLEVEL				#定义容器环境变量名称
 13       valueFrom:
 14         configMapKeyRef:			#环境变量的值来自ConfigMap
 15           name: cm-appvars			#指定来自cm-appvars的ConfigMap
 16           key: apploglevel			#key为apploglevel
 17     - name: APPDATADIR
 18       valueFrom:
 19         configMapKeyRef:
 20           name: cm-appvars
 21           key: appdatadir
 22 
 23 [root@k8smaster01 study]# kubectl create -f cm-test-pod.yaml
 24 [root@k8smaster01 study]# kubectl get pods
 25 NAME          READY   STATUS      RESTARTS   AGE
 26 cm-test-pod   0/1     Completed   2          24s

【挂载形式-待补充】

5.6 ConfigMap限制

  • Configmap必须在pod创建之间创建;
  • ConfigMap受到namespace的限制,只有同一个命名空间下才能引用;
  • ConfigMap暂时无法配置配额;
  • 静态的pod无法使用ConfigMap;
  • 在使用volumeMount挂载的时候,configMap基于items创建的文件会整体的将挂载数据卷的容器的目录下的文件全部覆盖。

六 Pod获取自身信息

6.1 Downward API

pod拥有唯一的名字、IP地址,并且处于某个Namespace中。pod的容器内获取pod的信息科通过Downward API实现。具体有以下两种方式:

  • 环境变量:用于单个变量,可以将pod信息和container信息注入容器内部;
  • volume挂载:将数组类信息生成为文件,挂载至容器内部。

举例1:通过Downward API将Pod的IP、名称和所在的Namespace注入容器的环境变量。

  1 [root@k8smaster01 study]# vi dapi-test-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod
  6 spec:
  7   containers:
  8     - name: test-container
  9       image: busybox
 10       command: [ "/bin/sh", "-c", "env" ]
 11       env:
 12         - name: MY_POD_NAME
 13           valueFrom:
 14             fieldRef:
 15               fieldPath: metadata.name
 16         - name: MY_POD_NAMESPACE
 17           valueFrom:
 18             fieldRef:
 19               fieldPath: metadata.namespace
 20         - name: MY_POD_IP
 21           valueFrom:
 22             fieldRef:
 23               fieldPath: status.podIP
 24   restartPolicy: Never

提示:Downward API提供如下变量:

metadata.name:Pod的名称,当Pod通过RC生成时,其名称是RC随机产生的唯一名称;

status.podIP:Pod的IP地址,POd的IP属于状态数据,而非元数据;

metadata.namespace:Pod所在的namespace。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod | grep MY_POD
  3 MY_POD_NAMESPACE=default
  4 MY_POD_IP=172.30.240.4
  5 MY_POD_NAME=dapi-test-pod
  6 

举例2:通过Downward API将Container的自愿请求和限制信息注入容器的环境变量。

  1 [root@k8smaster01 study]# vi dapi-test-pod-container-vars.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod-container-vars
  6 spec:
  7   containers:
  8     - name: test-container
  9       image: busybox
 10       imagePullPolicy: Never
 11       command: [ "/bin/sh", "-c" ]
 12       args:
 13       - while true; do
 14           echo -en '\n';
 15           printenv MY_CPU_REQUEST MY_CPU_LIMIT;
 16           printenv MY_MEM_REQUEST MY_MEM_LIMIT;
 17           sleep 3600;
 18         done;
 19       resources:
 20         requests:
 21           memory: "32Mi"
 22           cpu: "125m"
 23         limits:
 24           memory: "64Mi"
 25           cpu: "250m"
 26       env:
 27         - name: MY_CPU_REQUEST
 28           valueFrom:
 29             resourceFieldRef:
 30               containerName: test-container
 31               resource: requests.cpu
 32         - name: MY_CPU_LIMIT
 33           valueFrom:
 34             resourceFieldRef:
 35               containerName: test-container
 36               resource: limits.cpu
 37         - name: MY_MEM_REQUEST
 38           valueFrom:
 39             resourceFieldRef:
 40               containerName: test-container
 41               resource: requests.memory
 42         - name: MY_MEM_LIMIT
 43           valueFrom:
 44             resourceFieldRef:
 45               containerName: test-container
 46               resource: limits.memory
 47   restartPolicy: Never

提示:Downward API提供如下变量:

requests.cpu:容器的CPU请求值;

limits.cpu:容器的CPU限制值;

requests.memory:容器的内存请求值;

limits.memory:容器的内存限制值。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-container-vars.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-container-vars
  3 1
  4 1
  5 33554432
  6 67108864

举例3:通过Downward API将Pod的Label、Annotation列表通过Volume挂载为容器内的一个文件。

  1 [root@k8smaster01 study]# vi dapi-test-pod-volume.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod-volume
  6   labels:
  7     zone: us-est-coast
  8     cluster: test-cluster1
  9     rack: rack-22
 10   annotations:
 11     build: two
 12     builder: john-doe
 13 spec:
 14   containers:
 15     - name: test-container
 16       image: busybox
 17       imagePullPolicy: Never
 18       command: [ "/bin/sh", "-c" ]
 19       args:
 20       - while true; do
 21           if [[ -e /etc/labels ]]; then
 22             echo -en '\n\n'; cat /etc/labels; fi;
 23           if [[ -e /etc/annotations ]]; then
 24             echo -en '\n\n'; cat /etc/annotations; fi;
 25           sleep 3600;
 26         done;
 27       volumeMounts:
 28         - name: podinfo
 29           mountPath: /etc
 30           readOnly: false
 31   volumes:
 32     - name: podinfo
 33       downwardAPI:
 34         items:
 35           - path: "labels"
 36             fieldRef:
 37               fieldPath: metadata.labels
 38           - path: "annotations"
 39             fieldRef:
 40               fieldPath: metadata.annotations

注意:Volume中的ddownwardAPI的items语法,将会以path的名称生成文件。如上所示,会在容器内生产/etc/labels和/etc/annotations两个文件,分别包含metadata.labels和metadata.annotations的全部Label。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-volume.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-volume
  3 

提示:DownwardAPI意义:

在某些集群中,集群中的每个节点需要将自身的标识(ID)及进程绑定的IP地址等信息事先写入配置文件中,进程启动时读取此类信息,然后发布到某个类似注册服务中心。此时可通过DowanwardAPI,将一个预启动脚本或Init Container,通过环境变量或文件方式获取Pod自身的信息,然后写入主程序配置文件中,最后启动主程序。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏全栈修仙之路

RxDB 异常机制

RxDB 是一个由 JavaScript 实现,拥有响应式,离线优先等特性的数据库。它拥有以下特性:

5110
来自专栏全栈修仙之路

Node.js 小打小闹之爬虫入门

网络爬虫(英语:web crawler),也叫网络蜘蛛(spider),是一种用来自动浏览万维网的网络机器人。此外爬虫还可以验证超链接和 HTML 代码,用于网...

9220
来自专栏全栈修仙之路

Node.js 小打小闹之Excel解析

近期公司开始做绩效,某一天上午 HR 妹纸发了份 Excel 模板过来,让我下发给小组内成员填写。当天下午下班前,组内的绩效表就收齐了,接下来我就开始进入下一个...

8620
来自专栏营旗的小记录

算法:树和图-实战

思路:回到二叉搜索树,当前节点大于左子树,小于右子树。假如此树是二叉搜索树,那么应该满足这种有序的状态。

3820
来自专栏编程微刊

从零开始学习React-开发环境的搭建(一)

其实16年的时候就已经接触到React,那个时候也只是入门,时隔多年,工作上一直都没有接触到相关的业务,不知不觉,前端的天也开始渐变,看到 了很多招聘要求上都是...

7320
来自专栏营旗的小记录

腾讯云服务器Linux系统--安装MySql

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

43420
来自专栏大前端开发

为什么不学基于TypeScript的Node.js服务端开发?

我们早就知道,如今的JavaScript已经不再是当初那个在浏览器网页中写写简单的表单验证、没事弹个alert框吓吓人的龙套角色了。借助基于v8引擎的Node....

10120
来自专栏全栈修仙之路

Angular Multi Providers 和 APP_INITIALIZER

有些时候,我们希望在 Angular 应用程序启动的时候,执行一些初始化操作。针对这种场景,我们可以利用 APP_INITIALIZER 这个内置的 Token...

7920
来自专栏云爬虫技术研究笔记

由一次线上故障来理解下TCP三握、四挥 & Java堆栈分析到源码的探秘

该服务主要是提供对外的代理接口,大部分接口都会调用第三方接口,获取数据后做聚合处理后,提供给客户端使用。

5510
来自专栏营旗的小记录

算法:列表List、映射Map、集合Set-理论

有很多类实现了List接口,我们比较熟悉的 ArrayList、LinkedList、Stack等等,我们从中选区ArrayList类观察一下源码,看看是怎么实...

5710

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励