k8s 各类yaml文件

最新推荐文章于 2023-10-19 14:15:02 发布
最新推荐文章于 2023-10-19 14:15:02 发布
阅读量590 收藏 1
点赞数
分类专栏： 虚拟机
原文链接：https://www.kubernetes.org.cn/1885.html
版权

k8s 各类yaml文件

目录

deployment.yaml文件详解

Pod yaml文件详解

Service yaml文件详解

ingress.yaml详解

deployment.yaml文件详解

 

  1. apiVersion: extensions/v1beta1 #接口版本

  2. kind: Deployment #接口类型

  3. metadata:

  4. name: cango-demo #Deployment名称

  5. namespace: cango-prd #命名空间

  6. labels:

  7. app: cango-demo #标签

  8. spec:

  9. replicas: 3

  10. strategy:

  11. rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间

  12. maxSurge: 1 #滚动升级时会先启动1个pod

  13. maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数

  14. template:

  15. metadata:

  16. labels:

  17. app: cango-demo #模板名称必填

  18. sepc: #定义容器模板，该模板可以包含多个容器

  19. containers:

  20. - name: cango-demo #镜像名称

  21. image: swr.cn-east-2.myhuaweicloud.com/cango-prd/cango-demo:0.0.1-SNAPSHOT #镜像地址

  22. command: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ] #启动命令

  23. args: #启动参数

  24. - '-storage.local.retention=$(STORAGE_RETENTION)'

  25. - '-storage.local.memory-chunks=$(STORAGE_MEMORY_CHUNKS)'

  26. - '-config.file=/etc/prometheus/prometheus.yml'

  27. - '-alertmanager.url=http://alertmanager:9093/alertmanager'

  28. - '-web.external-url=$(EXTERNAL_URL)'

  29. #如果command和args均没有写，那么用Docker默认的配置。

  30. #如果command写了，但args没有写，那么Docker默认的配置会被忽略而且仅仅执行.yaml文件的command（不带任何参数的）。

  31. #如果command没写，但args写了，那么Docker默认配置的ENTRYPOINT的命令行会被执行，但是调用的参数是.yaml中的args。

  32. #如果如果command和args都写了，那么Docker默认的配置被忽略，使用.yaml的配置。

  33. imagePullPolicy: IfNotPresent #如果不存在则拉取

  34. livenessProbe: #表示container是否处于live状态。如果LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success，如果container没有提供LivenessProbe，则也认为是Success；

  35. httpGet:

  36. path: /health #如果没有心跳检测接口就为/

  37. port: 8080

  38. scheme: HTTP

  39. initialDelaySeconds: 60 ##启动后延时多久开始运行检测

  40. timeoutSeconds: 5

  41. successThreshold: 1

  42. failureThreshold: 5

  43. readinessProbe:

  44. httpGet:

  45. path: /health #如果没有心跳检测接口就为/

  46. port: 8080

  47. scheme: HTTP

  48. initialDelaySeconds: 30 ##启动后延时多久开始运行检测

  49. timeoutSeconds: 5

  50. successThreshold: 1

  51. failureThreshold: 5

  52. resources: ##CPU内存限制

  53. requests:

  54. cpu: 2

  55. memory: 2048Mi

  56. limits:

  57. cpu: 2

  58. memory: 2048Mi

  59. env: ##通过环境变量的方式，直接传递pod=自定义Linux OS环境变量

  60. - name: LOCAL_KEY #本地Key

  61. value: value

  62. - name: CONFIG_MAP_KEY #局策略可使用configMap的配置Key，

  63. valueFrom:

  64. configMapKeyRef:

  65. name: special-config #configmap中找到name为special-config

  66. key: special.type #找到name为special-config里data下的key

  67. ports:

  68. - name: http

  69. containerPort: 8080 #对service暴露端口

  70. volumeMounts: #挂载volumes中定义的磁盘

  71. - name: log-cache

  72. mount: /tmp/log

  73. - name: sdb #普通用法，该卷跟随容器销毁，挂载一个目录

  74. mountPath: /data/media

  75. - name: nfs-client-root #直接挂载硬盘方法，如挂载下面的nfs目录到/mnt/nfs

  76. mountPath: /mnt/nfs

  77. - name: example-volume-config #高级用法第1种，将ConfigMap的log-script,backup-script分别挂载到/etc/config目录下的一个相对路径path/to/...下，如果存在同名文件，直接覆盖。

  78. mountPath: /etc/config

  79. - name: rbd-pvc #高级用法第2中，挂载PVC(PresistentVolumeClaim)

  80.  

  81. #使用volume将ConfigMap作为文件或目录直接挂载，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容，

  82. volumes: # 定义磁盘给上面volumeMounts挂载

  83. - name: log-cache

  84. emptyDir: {}

  85. - name: sdb #挂载宿主机上面的目录

  86. hostPath:

  87. path: /any/path/it/will/be/replaced

  88. - name: example-volume-config # 供ConfigMap文件内容到指定路径使用

  89. configMap:

  90. name: example-volume-config #ConfigMap中名称

  91. items:

  92. - key: log-script #ConfigMap中的Key

  93. path: path/to/log-script #指定目录下的一个相对路径path/to/log-script

  94. - key: backup-script #ConfigMap中的Key

  95. path: path/to/backup-script #指定目录下的一个相对路径path/to/backup-script

  96. - name: nfs-client-root #供挂载NFS存储类型

  97. nfs:

  98. server: 10.42.0.55 #NFS服务器地址

  99. path: /opt/public #showmount -e 看一下路径

  100. - name: rbd-pvc #挂载PVC磁盘

  101. persistentVolumeClaim:

  102. claimName: rbd-pvc1 #挂载已经申请的pvc磁盘

Pod yaml文件详解

 

  1. # yaml格式的pod定义文件完整内容：

  2. apiVersion: v1       #必选，版本号，例如v1

  3. kind: Pod       #必选，Pod

  4. metadata:       #必选，元数据

  5.   name: string       #必选，Pod名称

  6.   namespace: string    #必选，Pod所属的命名空间

  7.   labels:      #自定义标签

  8.     - name: string     #自定义标签名字

  9.   annotations:       #自定义注释列表

  10.     - name: string

  11. spec:         #必选，Pod中容器的详细定义

  12.   containers:      #必选，Pod中容器列表

  13.   - name: string     #必选，容器名称

  14.     image: string    #必选，容器的镜像名称

  15.     imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像

  16.     command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令

  17.     args: [string]     #容器的启动命令参数列表

  18.     workingDir: string     #容器的工作目录

  19.     volumeMounts:    #挂载到容器内部的存储卷配置

  20.     - name: string     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名

  21.       mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符

  22.       readOnly: boolean    #是否为只读模式

  23.     ports:       #需要暴露的端口库号列表

  24.     - name: string     #端口号名称

  25.       containerPort: int   #容器需要监听的端口号

  26.       hostPort: int    #容器所在主机需要监听的端口号，默认与Container相同

  27.       protocol: string     #端口协议，支持TCP和UDP，默认TCP

  28.     env:       #容器运行前需设置的环境变量列表

  29.     - name: string     #环境变量名称

  30.       value: string    #环境变量的值

  31.     resources:       #资源限制和请求的设置

  32.       limits:      #资源限制的设置

  33.         cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数

  34.         memory: string     #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数

  35.       requests:      #资源请求的设置

  36.         cpu: string    #Cpu请求，容器启动的初始可用数量

  37.         memory: string     #内存清楚，容器启动的初始可用数量

  38.     livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可

  39.       exec:      #对Pod容器内检查方式设置为exec方式

  40.         command: [string]  #exec方式需要制定的命令或脚本

  41.       httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port

  42.         path: string

  43.         port: number

  44.         host: string

  45.         scheme: string

  46.         HttpHeaders:

  47.         - name: string

  48.           value: string

  49.       tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式

  50.          port: number

  51.        initialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒

  52.        timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒

  53.        periodSeconds: 0    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次

  54.        successThreshold: 0

  55.        failureThreshold: 0

  56.        securityContext:

  57.          privileged:false

  58.     restartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod

  59.     nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定

  60.     imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定

  61.     - name: string

  62.     hostNetwork:false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络

  63.     volumes:       #在该pod上定义共享存储卷列表

  64.     - name: string     #共享存储卷名称 （volumes类型有很多种）

  65.       emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值

  66.       hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录

  67.         path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录

  68.       secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部

  69.         scretname: string  

  70.         items:     

  71.         - key: string

  72.           path: string

  73.       configMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部

  74.         name: string

  75.         items:

  76.         - key: string

  77.           path: string

Service yaml文件详解

 

  1. apiVersion: v1

  2. kind: Service

  3. matadata: #元数据

  4. name: string #service的名称

  5. namespace: string #命名空间

  6. labels: #自定义标签属性列表

  7. - name: string

  8. annotations: #自定义注解属性列表

  9. - name: string

  10. spec: #详细描述

  11. selector: [] #label selector配置，将选择具有label标签的Pod作为管理

  12. #范围

  13. type: string #service的类型，指定service的访问方式，默认为

  14. #clusterIp

  15. clusterIP: string #虚拟服务地址

  16. sessionAffinity: string #是否支持session

  17. ports: #service需要暴露的端口列表

  18. - name: string #端口名称

  19. protocol: string #端口协议，支持TCP和UDP，默认TCP

  20. port: int #服务监听的端口号

  21. targetPort: int #需要转发到后端Pod的端口号

  22. nodePort: int #当type = NodePort时，指定映射到物理机的端口号

  23. status: #当spce.type=LoadBalancer时，设置外部负载均衡器的地址

  24. loadBalancer: #外部负载均衡器

  25. ingress: #外部负载均衡器

  26. ip: string #外部负载均衡器的Ip地址值

  27. hostname: string #外部负载均衡器的主机名

 

è¿éåå¾çæè¿°

目前kubernetes提供了两种负载分发策略：RoundRobin和SessionAffinity

RoundRobin：轮询模式，即轮询将请求转发到后端的各个Pod上

SessionAffinity：基于客户端IP地址进行会话保持的模式，第一次客户端访问后端某个Pod，之后的请求都转发到这个Pod上

默认是RoundRobin模式

在某些场景中，开发人员希望自己控制负载均衡的策略，不使用Service提供的默认负载，kubernetes通过Headless Service的概念来实现。不给Service设置ClusterIP（无入口IP地址）：
 

 

  1. apiVersion: v1

  2. kind: Service

  3. metadata:

  4. name: nginx

  5. labels:

  6. app: nginx

  7. spec:

  8. ports:

  9. - port: 80

  10. clusterIP: None

  11. selector:

  12. app: nginx

 有时候，一个容器应用提供多个端口服务：

 

  1. apiVersion: v1

  2. kind: Service

  3. metadata:

  4. name: webapp

  5. spec:

  6. ports:

  7. - port: 8080

  8. targetPort: 8080

  9. name: web

  10. - port: 8005

  11. targetPort: 8005

  12. name: management

  13. selector:

  14. app: webapp

为不同的应用分配各自的端口。

另一个例子是两个端口使用了不同的4层协议，即TCP或UDP

 

  1. apiVersion: v1

  2. kind: Service

  3. metadata:

  4. name: kube-dns

  5. namespace: kube-system

  6. labels:

  7. k8s-app: kube-dns

  8. kubernetes.io/cluster-service: "true"

  9. kubernetes.io/name: "KubeDNS"

  10. spec:

  11. selector:

  12. k8s-app: kube-dns

  13. clusterIP: 169.169.0.100

  14. ports:

  15. - name: dns

  16. port: 53

  17. protocol: UDP

  18. - name: dns-tcp

  19. port: 53

  20. protocol: TCP

集群外部访问Pod或Service
为了让外部客户端可以访问这些服务，可以将Pod或者Service的端口号映射到宿主主机，使得客户端应用能够通过物理机访问容器应用。

将容器应用的端口号映射到物理机
通过设置容器级别的hostPort，将容器应用的端口号映射到物理机上：
pod-hostport.yaml：
 

 

  1. apiVersion: v1

  2. kind: Pod

  3. metadata:

  4. name: webapp

  5. labels:

  6. app: webapp

  7. spec:

  8. containers:

  9. - name: webapp

  10. image: tomcat

  11. ports:

  12. - containerPort: 8080

  13. hostPort:8081

创建这个Pod：

kubectl create -f pod-hostnetwork.yaml

通过物理机的IP地址和8080端口访问Pod的容器服务：

curl 10.0.11.151:8080

将Service的端口号映射到物理机

通过设置nodePort映射到物理机，同时设置Service的类型为NodePort：

webapp-svc-nodeport.yaml：

 

  1. apiVersion: v1

  2. kind: Service

  3. metadata:

  4. name: webapp

  5. spec:

  6. type: NodePort

  7. ports:

  8. - port: 8080

  9. targetPort: 8080

  10. nodePort: 8081

  11. selector:

  12. app: webapp

创建这个Service：

kubectl create -f webapp-svc-nodeport.yaml

通过物理机的IP和端口访问：

curl 10.0.11.151:8081

ingress.yaml详解

通常情况下，service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。从概念上讲，可能像下面这样：

 

  1. internet

  2. |

  3. ------------

  4. [ Services ]

Ingress是授权入站连接到达集群服务的规则集合。

 

  1. internet

  2. |

  3. [ Ingress ]

  4. --|-----|--

  5. [ Services ]

你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现Ingress，通常使用负载平衡器，它还可以配置边界路由和其他前端，这有助于以HA方式处理流量。

 

Ingress Resource

最简化的Ingress配置：

 

  1. apiVersion: extensions/v1beta1

  2. kind: Ingress

  3. metadata:

  4. name: test-ingress

  5. spec: # Ingress spec 中包含配置一个loadbalancer或proxy server

  6. rules: # 的所有信息。最重要的是，它包含了一个匹配所有入站请求的规

  7. - http: # 则列表。目前ingress只支持http规则。

  8. paths:

  9. - path: /testpath # 每条http规则包含以下信息：一个host配置项（比如

  10. # for.bar.com，在这个例子中默认是*），path列表（比

  11. # 如：/testpath），每个path都关联一个backend(比如

  12. # test:80)。在loadbalancer将流量转发到backend之前，所有的

  13. # 入站请求都要先匹配host和path。

  14. backend:

  15. serviceName: test # backend是一个service:port的组合。Ingress的流量被转发到

  16. servicePort: 80 # 它所匹配的backend

Ingress类型

Kubernetes中已经存在一些概念可以暴露单个service，但是你仍然可以通过Ingress来实现，通过指定一个没有rule的默认backend的方式。

ingress.yaml定义文件：

 

  1. apiVersion: extensions/v1beta1

  2. kind: Ingress

  3. metadata:

  4. name: test-ingress

  5. spec:

  6. backend:

  7. serviceName: testsvc

  8. servicePort: 80

使用kubectl create -f命令创建，然后查看ingress：

 

  1. $ kubectl get ing

  2. NAME RULE BACKEND ADDRESS

  3. test-ingress - testsvc:80 107.178.254.228

107.178.254.228就是Ingress controller为了实现Ingress而分配的IP地址。RULE列表示所有发送给该IP的流量都被转发到了BACKEND所列的Kubernetes service上。

简单展开

如前面描述的那样，kubernete pod中的IP只在集群网络内部可见，我们需要在边界设置一个东西，让它能够接收ingress的流量并将它们转发到正确的端点上。这个东西一般是高可用的loadbalancer。使用Ingress能够允许你将loadbalancer的个数降低到最少，例如，假如你想要创建这样的一个设置：

 

  1. foo.bar.com -> 178.91.123.132 -> / foo s1:80

  2. / bar s2:80

你需要一个这样的ingress：

 

  1. apiVersion: extensions/v1beta1

  2. kind: Ingress

  3. metadata:

  4. name: test

  5. spec:

  6. rules:

  7. - host: foo.bar.com

  8. http:

  9. paths:

  10. - path: /foo

  11. backend:

  12. serviceName: s1

  13. servicePort: 80

  14. - path: /bar

  15. backend:

  16. serviceName: s2

  17. servicePort: 80

使用kubectl create -f创建完ingress后：

 

  1. $ kubectl get ing

  2. NAME RULE BACKEND ADDRESS

  3. test -

  4. foo.bar.com

  5. /foo s1:80

  6. /bar s2:80

只要服务（s1，s2）存在，Ingress controller就会将提供一个满足该Ingress的特定loadbalancer实现。 这一步完成后，您将在Ingress的最后一列看到loadbalancer的地址。

基于名称的虚拟主机

Name-based的虚拟主机在同一个IP地址下拥有多个主机名。

 

  1. foo.bar.com --| |-> foo.bar.com s1:80

  2. | 178.91.123.132 |

  3. bar.foo.com --| |-> bar.foo.com s2:80

下面这个ingress说明基于Host header的后端loadbalancer的路由请求：

 

  1. apiVersion: extensions/v1beta1

  2. kind: Ingress

  3. metadata:

  4. name: test

  5. spec:

  6. rules:

  7. - host: foo.bar.com

  8. http:

  9. paths:

  10. - backend:

  11. serviceName: s1

  12. servicePort: 80

  13. - host: bar.foo.com

  14. http:

  15. paths:

  16. - backend:

  17. serviceName: s2

  18. servicePort: 80

默认backend：一个没有rule的ingress，如前面章节中所示，所有流量都将发送到一个默认backend。你可以用该技巧通知loadbalancer如何找到你网站的404页面，通过制定一些列rule和一个默认backend的方式。如果请求header中的host不能跟ingress中的host匹配，并且/或请求的URL不能与任何一个path匹配，则流量将路由到你的默认backend。

 

 

一见永恒-明哥
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
K8s中yaml文件详解（超详细）
06-07
K8s中yaml文件详解（超详细）
查看k8s中Pod里容器的数量和名称
CBeann的博客
10-03 3万+
查看Pod里容器的名称 初始化一个包含两个容器的Pod（tomcat和nginx），其中文件名为ini-pod.yaml apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-tomcat image: tomcat - name: myapp-nginx image: nginx kubectl create -
K8S YML配置详解
justlpf的专栏
08-11 931
Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace，是 Kubernetes 调度的基本单位。Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。k8s中的apiVersion版本,可以使用命令kubectl api-versions查看，这里列举三个常见的。Kubernetes 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。
K8S在一个Pod中创建多个容器
IChen.的博客
06-03 2838
YAML文件内容（把tomcat和mysql放到同一个Pod中） apiVersion: v1 kind: Pod metadata: name: my-app labels: name: my-app spec: containers: - name: tomcat image: tomcat:1.0 ports: - containerPort: 8080 - name: mysql image: mysql:5.7 ports:
Kubernetes之yaml文件详解(汇总-详细）
热门推荐
BigData_Mining的博客
03-13 4万+
一、YAML基础 YAML是专门用来写配置文件的语言，非常简洁和强大，使用比json更方便。它实质上是一种通用的数据串行化格式。 YAML语法规则： 大小写敏感 使用缩进表示层级关系 缩进时不允许使用Tal键，只允许使用空格 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可 ”#” 表示注释，从这个字符一直到行尾，都会被解析器忽略　　 在Kubernetes中，只需要知道两种结构类型即可： ...
calico flannel k8s 安装yaml文件
03-05
calico flannel k8s 安装yaml文件
k8s 创建mysql的 全套yaml文件
04-13
k8s 创建mysql的 全套yaml文件
k8s dashboard yaml文件
01-12
k8s dashboard yaml文件
nacos-k8s-yaml.zip
09-01
k8s部署nacos集群的yaml文件，持久化支持nfs部署.创建nfs的存储类型与pvc等yaml文件
【云原生之k8s】Yaml文件详解
qq_45088125的博客
08-01 2511
kubernetes支持YAML和JSON文件格式管理资源对象
在 Amazon EKS 上使用 k8s Snapshot 备份和恢复 EBS PV 卷
亚马逊云科技专栏
06-09 1050
云端容器平台如 Amazon EKS 非常适合来运行无状态的应用程序以增强其弹性，但某些场景下我们仍然需要使用 PV 来运行有状态的服务并提供固化存储，如某些中间件应用或其他需要使用轻量化数据库的应用。这些应用通常不支持多副本，且对读写延迟和性能要求较高，因此选择正确的底层存储非常重要。开源社区提供了标准的容器存储接口 (CSI)，这是一种将任意块和文件存储系统暴露给 K......
云原生 | Kubernetes - 卷快照
Trollz的博客
01-18 535
Cloud Native | Kubernetes - Volume Snapshot
K8S中 yaml 文件详解
kele_baba
08-23 1万+
K8S中 yaml 文件详解一、K8S中的 yaml 文件二、写一个 yaml 文件，通过声明式创建pod创建 Deployment 资源 - kind: Deployment创建 Service 资源 - kind-Service导出 yaml 格式方式例子：deployment.yaml 文件详解例子：Service yaml 文件详解 一、K8S中的 yaml 文件 Kubernetes 支持 YAML 和 JSON格式 管理资源对象 JSON 格式：主要用于 api 接口之间消息的传递 YAML
k8s篇-应用持久化存储2（存储快照与拓扑调度）
qq_19676401的博客
11-05 1682
一、存储快照 快照功能：能对线上的数据进行快速的复制、迁移等，及对重要数据误操作之后进行快速恢复。K8s中通过CSI Snapshotter controller来实现存储快照的功能。 Snapshot原理：创建snapshot过程，与pvc&pv设计类似 PVC -------> StorageClass -------------> PV VolumeSnapshot -------> VolumeSnapshotClass ------&gt
K8S之yaml文件详解
最新发布
迪之的博客
10-19 2024
文章目录一、概述二、YAML文件优点三、YAML与 JSON 和 XML 的关系四、YAML 文件的结构五、YAML 在 Kubernetes 中的使用六、YAML文件模板生成/导出一、概述只支持YAML和JSON格式创建资源对象JSON格式用于接口之间消息的传递，格式用于配置和管理YAML是专门用来写配置文件的语言，非常简洁和强大，使用比json更方便。它实质上是一种通用的数据串行化格式。二、YAML文件优点。
K8s中yaml文件详解
qq_36864672的博客
02-23 4756
YAML是专门用来写配置文件的语言，非常简洁和强大，使用比json更方便。它实质上是一种通用的数据串行化格式。
K8S：Yaml文件详解
m0_71493671的博客
09-13 3290
详解k8s中的port：●portport 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service●nodePortnodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个 service。
​K8s中yaml文件详解（超详细）​
Java后端技术栈
09-20 1714
上述例子中，使用两个空格作为缩进，但空格的数据量并不重要，只是至少要求一个空格并且所有缩进保持一致的空格数。除了上述的基本属性外，还能够指定复杂的属性，包括容器启动运行的命令、使用的参数、工作目录以及每次实例化是否拉取新的副本。注：上述的YAML文件中，metadata这个KEY对应的值为一个Maps，而嵌套的labels这个KEY的值又是一个Map。上述例子只是一个简单的最小定义：一个名字（front-end）、基于nginx的镜像，以及容器将会监听的指定端口号（80）。YAML对用户更加友好。
k8s的yaml文件
10-19
Kubernetes的YAML文件是用来定义Kubernetes对象的配置文件，其中包含了该对象的各种属性和规则。例如，可以使用YAML文件来定义一个Deployment对象，指定该Deployment需要运行的Pod数量、容器镜像、容器端口等信息。 ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值