文章目录
- k8s之yaml文件详解
- 一、关于yaml文件
- 1、k8s支持的文件格式
- 2、YAML语言格式
- 3、查看api资源版本标签
- 4、编写nginx-test.yaml资源配置清单
- 4.1 编写资源配置清单
- 4.2 创建资源对象
- 4.3 查看创建的pod资源
- 5、创建service服务对外提供访问并测试
- 5.1 编写nginx-svc-test.yaml
- 5.2 创建资源对象
- 5.3 查看创建的service
- 5.4 访问测试
- 6、详解k8s中的port
- 7、试运行生成yaml模板后创建实例
- 7.1 --dry-run:试运行
- 7.2 查看生成yaml格式
- 7.3 查看生成json格式
- 7.4 yaml和json的主要区别
- 7.5 使用yaml格式导出生成模板
- 7.6 删除一些不必要的参数
- 7.7 使用yaml模板创建实例
- 8、将现有资源生成yaml模板导出并保存为文件
- 8.1 将现有的资源生成模板导出
- 8.2 保存到文件中
- 9、explain:查看字段帮助信息
- 10、获取资源配置清单的总结
- 二、编写MySQL的yaml文件
- 1、编写文件
- 2、生成资源
- 3、访问验证
k8s之yaml文件详解
一、关于yaml文件
1、k8s支持的文件格式
- Kubernetes支持YAML和JSON格式管理资源对象
- JSON格式:主要用于api接口之间消息的传递
- YAML格式:用于配置和管理,YAML是一种简洁的非标记性语言,内容格式人性化,较易读
2、YAML语言格式
- 大小写敏感
- 使用缩进表示层级关系
- 不支持Tab键制表符缩进,只使用空格缩进
- 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可,通常开头缩进两个空格
- 符号字符后缩进一个空格,如冒号,逗号,短横杠(-)等
- “—”表示YAML格式,一个文件的开始,用于分隔文件
- “#”表示注释
3、查看api资源版本标签
kubectl api-versions
#查看api资源版本标签
- 如果是业务场景,一般首选使用apps/v1(apps/v1从v1.9版本开始提供API)。
- 在k8s v1.16版本之前使用的是extensions/v1beta1,extensions/v1beta1从v1.20版本开始不再提供Ingress资源。
- 带有beta字样的代表的是测试版本,不用在生产环境中。
4、编写nginx-test.yaml资源配置清单
4.1 编写资源配置清单
mkdir /opt/test
#新建目录
cd !$
cd /opt/test
#切换到新建目录
vim nginx-test.yaml
apiVersion: apps/v1
#指定api版本标签
kind: Deployment
#定义资源的类型/角色,deployment为副本控制器
#此处资源类型可以是Deployment、Job、Ingress、Service等
metadata:
#定义资源的元数据信息,比如资源的名称、namespace、标签等信息
name: nginx-test
#定义资源名称
namespace: luck
#定义deployment所在的命名空间
labels:
#定义标签
app: nginx
#定义资源的名称,在同一个namespace空间中必须是唯一的
spec:
#定义deployment资源需要的参数属性,诸如是否在容器失败时重新启动容器的属性
replicas: 3
#定义副本数量
selector:
#定义标签选择器
matchLabels:
#定义匹配标签
app: nginx
#指定标签为nginx
#需与后面的.spec.template.metadata.labels定义的标签保持一致
template:
#定义业务模板,如果有多个副本,所有副本的属性会按照模板的相关配置进行匹配
metadata:
#pod的元数据
labels:
#定义pod标签
app: nginx
#定义Pod副本将使用的标签,需与前面的.spec.selector.matchLabels定义的标签保持一致
spec:
#定义pod的规格
containers:
#定义容器属性
- name: nginx
#定义一个容器名,一个-name:定义一个容器
image: nginx:1.18
#定义容器使用的镜像以及版本
ports:
#定义容器对外的端口
- containerPort: 80
#定义容器内部监听的端口号
4.2 创建资源对象
kubectl apply -f nginx-test.yaml
#创建资源对象
4.3 查看创建的pod资源
kubectl get pods -owide
#查看创建的pod资源
5、创建service服务对外提供访问并测试
5.1 编写nginx-svc-test.yaml
#编辑yaml文件
vim nginx-svc-test.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: luck
labels:
app: nginx
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginx
#此处定义的selector要与deployment所定义的selector相同
#service依靠标签选择器来检索提供服务的nodes
5.2 创建资源对象
kubectl apply -f nginx-svc-test.yaml
#创建资源对象
5.3 查看创建的service
kubectl get pod,svc -n luck
#查看创建的service资源
5.4 访问测试
curl 192.168.10.12:30811
curl 192.168.10.13:30811
#验证访问
#或者在浏览器输入nodeIP:nodePort即可访问
6、详解k8s中的port
相关port | 说明 |
---|---|
port | port是k8s集群内部访问service的端口,即通过clusterIP:port可以从Pod所在的Node上访问到service |
nodePort | nodePort是外部访问k8s集群中service的端口,通过nodeIP:nodePort可以从外部访问到某个service |
targetPort | targetPort是Pod的端口,从port或nodePort来的流量经过kube-proxy反向代理负载均衡转发到后端Pod的targetPort上,最后进入容器。 |
containerPort | containerPort是Pod内部容器的端口,targetPort映射到containerPort。 |
7、试运行生成yaml模板后创建实例
7.1 --dry-run:试运行
- kubectl run --dry-run打印相应的API对象而不执行创建
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run
#--dry-run不会实际创建任何资源,而是会输出一个 YAML 或 JSON 格式的资源配置,即并不会真的创建出pod和deployment实例,去掉该参数后即可真正执行命令。
--------------------------------------------------------------------------------------------------------
dryrun-test:是创建的 Pod(或更具体地说是 Deployment,因为使用了 --replicas)的名称。
--image=nginx:指定了 Pod 中容器的镜像。
--port=80:通常用于指定容器内的端口,但注意这个参数在 kubectl run 命令中可能不会直接设置容器的端口,而是需要额外的参数(如 --container-port)来明确指定。不过,在某些版本的 Kubernetes 中,--port 可能被解释为容器端口。
--replicas=3:表示你想要创建一个 Deployment,而不是单个 Pod,并且该 Deployment 将确保有 3 个 Pod 副本在运行。
--dry-run:表示不会实际创建资源,而是输出一个描述这些资源的 YAML 或 JSON 配置。
--------------------------------------------------------------------------------------------------------
kubectl get pod,deploy
#查看资源
7.2 查看生成yaml格式
- 使用–dry-run试运行可不触发生成命令,然后通过-o yaml可实现对其yaml资源配置清单的查看
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
#查看生成的yaml资源配置清单
7.3 查看生成json格式
- 同理,可通过-o json查看该命令产生的json配置清单
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o json
#查看生成的json资源配置清单
7.4 yaml和json的主要区别
-
YAML使用空格缩进,这是Python开发人员熟悉的领域。
-
JavaScript开发人员喜欢JSON,因为它是JavaScript的一个子集,可以直接在JavaScript中解释和编写,同时使用简写方式声明JSON,在使用没有空格的典型变量名时,不需要键中的双引号。
-
有很多解析器在YAML和JSON的所有语言中都能很好地工作。
-
在许多情况下,YAML的空白格式可以更容易查看,因为格式化需要更人性化的方法。
-
如果您的编辑器中没有空格可见或缩进线指示符,那么YAML的空白虽然更紧凑,更容易查看,但可能难以手动编辑。
-
JSON的序列化和反序列化要快得多,因为要检查的功能明显少于YAML,这使得更小更轻的代码能够处理JSON。
-
一个常见的误解是YAML需要较少的标点符号并且比JSON更紧凑,但这完全是错误的。空格是不可见的,所以看起来字符较少,但是如果你计算实际的空格是必要的,以便正确解释YAML以及正确的缩进,你会发现YAML实际上需要比JSON更多的字符。JSON不使用空格来表示层次结构或分组,并且可以通过删除不必要的空格来轻松展平,以实现更紧凑的传输。
7.5 使用yaml格式导出生成模板
kubectl run dryrun-test --image=nginx --port=80 --dry-run -o yaml > nginx.yaml
#使用yaml格式导出生成模板
7.6 删除一些不必要的参数
#编辑yaml配置文件
vim nginx.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
#删除上面一行
labels:
run: dryrun-test
name: dryrun-test
spec:
containers:
- image: nginx
name: dryrun-test
ports:
- containerPort: 80
resources: {}
#删除上面一行
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
#删除上面一行
7.7 使用yaml模板创建实例
kubectl apply -f nginx.yaml
#使用yaml模板创建实例
kubectl get pod,deploy
#显示pod资源信息
8、将现有资源生成yaml模板导出并保存为文件
8.1 将现有的资源生成模板导出
kubectl get svc
#显示svc信息
kubectl get svc nginx-svc -o yaml
#将现有的资源生成模板导出
8.2 保存到文件中
kubectl get svc nginx-svc -o yaml > my-svc.yaml
#输出到my-svc.yaml文件中
9、explain:查看字段帮助信息
- 可一层层的查看相关资源对象的帮助信息
kubectl explain deployment.spec.template.spec.containers
#查看相关资源对象的帮助信息
kubectl explain pods.spec.containers
#查看相关资源对象的帮助信息
10、获取资源配置清单的总结
kubectl run dryrun-test --image=nginx --port=80 --dry-run -o yaml > nginx.yaml
#没有相关资源,使用run命令--dry-run选项
kubectl get svc nginx-svc -o yaml > my-svc.yaml
#已有相关资源,使用get命令导出
二、编写MySQL的yaml文件
1、编写文件
vim mysql.yaml
apiVersion: v1
kind: Namespace
metadata:
name: mysql-server
---
apiVersion: apps/v1
kind: Deployment
#mysql为动态服务器,其pod控制器应当设置为StatefulSet,为便于理解基础,先设置为Deployment
metadata:
labels:
apps: mysql
name: mysql-db
namespace: mysql-server
spec:
replicas: 1
selector:
matchLabels:
apps: mysql
template:
metadata:
labels:
apps: mysql
spec:
containers:
- name: mysql
image: mysql:latest
#使用MySQL的官方镜像
ports:
- containerPort: 3306
env:
#定义环境变量列表
- name: MYSQL_ROOT_PASSWORD
#环境变量的名称
value: password
#设置MySQL的root密码,也就是环境变量的值
#当MySQL容器首次启动时,它会检查数据库是否已经初始化,并且如果没有提供密码相关的环境变量,它会报错并退出
volumeMounts:
#定义如何挂载卷到容器中
- name: mysql-test
#引用的卷的名称
mountPath: /var/lib/mysql
#卷在容器中的挂载路径
volumes:
#定义Pod中使用的卷列表
- name: mysql-test
#卷的名称,与volumeMounts中的name相对应
emptyDir: {}
#一个空目录卷。这种类型的卷在Pod首次被调度到节点上时创建,并在Pod被删除时销毁。它不持久化数据,仅用于临时存储
---
apiVersion: v1
kind: Service
metadata:
name: mysql-service
namespace: mysql-server
labels:
apps: mysql
spec:
type: NodePort
ports:
- port: 3306
targetPort: 3306
selector:
apps: mysql
2、生成资源
kubectl apply -f mysql.yaml
#指定yaml配置文件
kubectl get pod,svc -n mysql-server -owide
#查看详细信息
3、访问验证
- 登录mysql容器
kubectl exec -it mysql-db-557b9b7f5b-vjsnm -n mysql-server bash
#进入mysql容器
root@mysql-db-557b9b7f5b-vjsnm:/# mysql -u root -p'password'
#登录mysql服务
mysql> show databases;
#查看数据库信息