• 云原生K8S------Yaml文件详解


    目录

    一,K8S支持的文件格式

    1,yaml和json的主要区别

    2,YAML语言格式

    二,YAML

    1,查看APL资源版本标签

     2,编写资源配置清单

     2.2 创建资源对象

     2.3 查看创建的pod资源

     3,创建service服务对外提供访问并测试

    3.1 编写nginx-service。yaml文件

     3.2 创建资源对象

    3.3 访问测试

     三,详解K8S中的port

    四,试运行生成yaml模板后创建实例

    1,-dry-run:试运行

     2,生成yaml格式

    3,生成json格式

     4,使用yaml格式导出生成模板

     5,使用yaml模板创建实例

    6,将现有资源生成yaml模板导出并保存为文件

    7,查看字段帮助信息 

    五,总结


     

    一,K8S支持的文件格式

    kubernetes支持yaml和json文件格式管理资源对象

    1. JSON格式:主要用于api接口之间消息的传递
    2. YAML格式:用于配置和管理,YAML是一种简洁的非标记性语言,内容格式人性化,较易读。

    1,yaml和json的主要区别

    1. YAML 使用空格缩进,这是 Python 开发人员熟悉的领域。
    2. JavaScript 开发人员喜欢 JSON,因为它是 JavaScript 的一个子集,可以直接在 JavaScript中解释和编写,同时使用简写方式声明 JSON,在使用没有空格的典型变量名时,不需要键中的双引号。
    3. 有很多解析器在 YAML 和 JSON 的所有语言中都能很好地工作。
    4. 在许多情况下,YAML 的空白格式可以更容易查看,因为格式化需要更人性化的方法。
    5. 如果您的编辑器中没有空格可见或缩进线指示符,那么 YAML 的空白虽然更紧凑,更容易查看,但可能难以手动编辑。
    6. JSON 的序列化和反序列化要快得多,因为要检查的功能明显少于 YAML,这使得更小更轻的代码能够处理 JSON。
    7. 一个常见的误解是 YAML 需要较少的标点符号并且比 JSON更紧凑,但这完全是错误的。空格是不可见的,所以看起来字符较少,但是如果你计算实际的空格是必要的,以便正确解释 YAML以及正确的缩进,你会发现 YAML 实际上需要比 JSON 更多的字符。JSON不使用空格来表示层次结构或分组,并且可以通过删除不必要的空格来轻松展平,以实现更紧凑的传输。
       

    2,YAML语言格式

    1. 大小写敏感
    2. 使用缩进表示层级关系
    3. 不支持TAB键制表符缩进,只使用空格缩进
    4. 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可,通常开头缩进两个空格
    5. 符号字符后缩进一个空格,如冒号,逗号,短横杠等
    6. —表示YANL格式,一个文件的开始,用于分隔文件
    7. #表示注释

    二,YAML

    1,查看APL资源版本标签

    kubectl api-versions
    

     2,编写资源配置清单

    编写nginx-test。yaml 资源配置清单

    1. vim nginx-test.yaml
    2. #指定api版本标签
    3. apiVersion: apps/v1
    4. #定义资源的类型/角色,deployment为副本控制器
    5. #此处资源类型可以是Deployment、Job、Ingress、Service等
    6. kind: Deployment
    7. #定义资源的元数据信息,比如资源的名称、namespace、标签等信息
    8. metadata:
    9. #定义资源的名称,在同一个namespace空间中必须是唯一的
    10. name: nginx-deployment
    11. labels:
    12. app: nginx
    13. #定义deployment资源需要的参数属性,诸如是否在容器失败时重新启动容器的属性
    14. spec:
    15. #定义副本数量
    16. replicas: 3
    17. #定义标签选择器
    18. selector:
    19. #定义匹配标签
    20. matchLabels:
    21. #需与后面的.spec.template.metadata.labels定义的标签保持一致
    22. app: nginx
    23. #定义业务模板,如果有多个副本,所有副本的属性会按照模板的相关配置进行匹配
    24. template:
    25. metadata:
    26. #定义Pod副本将使用的标签,需与前面的.spec.selector.matchLabels定义的标签保持一致
    27. labels:
    28. app: nginx
    29. spec:
    30. #定义容器属性
    31. containers:
    32. #定义一个容器名,一个-name:定义一个容器
    33. - name: nginx
    34. #定义容器使用的镜像以及版本
    35. image: nginx:1.15.4
    36. ports:
    37. #定义容器对外的端口
    38. - containerPort: 80
    39. #------------------------------------------------------------------#
    40. #无注释
    41. apiVersion: apps/v1
    42. kind: Deployment
    43. metadata:
    44. name: nginx-deployment
    45. labels:
    46. app: nginx
    47. spec:
    48. replicas: 3
    49. selector:
    50. matchLabels:
    51. app: nginx
    52. template:
    53. metadata:
    54. labels:
    55. app: nginx
    56. spec:
    57. containers:
    58. - name: nginx
    59. image: nginx:1.15.4
    60. ports:
    61. - containerPort: 80

     2.2 创建资源对象

    kubectl create -f nginx-deployment.yaml --validate=false

     2.3 查看创建的pod资源

    kubectl get pods -o wide

     3,创建service服务对外提供访问并测试

    3.1 编写nginx-service。yaml文件

    1. [root@master ~]# vim nginx-svc-test.yaml
    2. apiVersion: v1
    3. kind: Service
    4. metadata:
    5. name: nginx-svc
    6. labels:
    7. app: nginx
    8. spec:
    9. type: NodePort
    10. ports:
    11. - port: 80
    12. targetPort: 80
    13. selector:
    14. #此处定义的selector要与deployment所定义的selector相同
    15. #service依靠标签选择器来检索提供服务的nodes
    16. app: nginx

     3.2 创建资源对象

    1. kubectl apply -f nginx-service.yaml
    2. kubectl get po,svc

    3.3 访问测试

     

     三,详解K8S中的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

    四,试运行生成yaml模板后创建实例

    1,-dry-run:试运行

    -dry-run:表示试运行,不真正执行命令(测试命令是否正确,并不会真的创建出pod和deployment实例,去掉该参数后即可真正执行命令。

    #kubectl create deployment nginx-nxx --image=nginx:1.21 --replicas=3 --port=80 --dry-run=client

     2,生成yaml格式

    使用 --dry-run 试运行可不触发生成命令,然后通过 -o yaml 可实现对其 yaml 资源配置清单的查看

    kubectl create deployment nginx-nxx --image=nginx:1.21 --replicas=3 --port=80 --dry-run=client -o yaml

    1. [root@master demo]#kubectl apply -f nginxzz.yaml --dry-run=client
    2. deployment.apps/nginx-deployment configured (dry run)
    3. [root@master demo]#kubectl apply -f nginxzz.yaml --dry-run=client -o yaml

    3,生成json格式

    可通过 -o json 查看该命令产生的 json 配置清单

    kubectl create deployment nginx-nxx --image=nginx:1.21 --replicas=3 --port=80 --dry-run=client -o json
    

     4,使用yaml格式导出生成模板

    [root@master demo]#kubectl create deployment nginx-nxx --image=nginx:1.21 --replicas=3 --port=80 --dry-run=client -o yaml >nxx.yaml
    

     

     5,使用yaml模板创建实例

    1. kubectl apply -f nxx.yaml
    2. kubectl get pod,deploy

    6,将现有资源生成yaml模板导出并保存为文件

    1. kubectl get deploy/nginx-nxx -o yaml
    2. kubectl get deploy/nginx-nxx -o yaml > nxx.test.yaml

     

    7,查看字段帮助信息 

    explain 可一层层的查看相关资源对象的帮助信息

    [root@master demo]#kubectl explain deployment.spec.template.spec.containers
    

     

    五,总结

    没有相关资源,使用--dry-run 选项

    kubectl run nxx.test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > nxx.test.yaml
    

    已有相关资源,使用get命令-export选项

    kubectl get deploy dryrun-test --export -o yaml > export-test.yaml
    

  • 相关阅读:
    医疗产品方案|智能蓝牙血压计方案
    用户视角的比特币和以太坊外围技术整理
    Linux学习之MySQL常见面试题目
    前后端分离项目服务器部署
    进程管理命令 动态监控进程 rpm yum
    什么是BFC
    部署Prometheus
    微服务项目:尚融宝(19)(后端搭建:阿里云短信服务整合)
    leetcode 刷题 log day 44
    pytorch实现卷积操作
  • 原文地址:https://blog.csdn.net/m0_54594153/article/details/127721470