(四)kubernetes 资源编排(YAML)

YAML 是一种简洁的非标记语言。
语法格式:
? 缩进表示层级关系
? 不支持制表符“tab”缩进,使用空格缩进
? 通常开头缩进 2 个空格
? 字符后缩进 1 个空格,如冒号、逗号等
?
“---” 表示YAML格式,一个文件的开始
? “#”注释

k8s yaml

# yaml格式的pod定义文件完整内容:
apiVersion: v1       #必选,版本号,例如v1
kind: Pod       #必选,Pod
metadata:       #必选,元数据
  name: string       #必选,Pod名称
  namespace: string    #必选,Pod所属的命名空间
  labels:      #自定义标签
    - name: string     #自定义标签名字
  annotations:       #自定义注释列表
    - name: string
spec:         #必选,Pod中容器的详细定义
  containers:      #必选,Pod中容器列表
  - name: string     #必选,容器名称
    image: string    #必选,容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像
    command: [string]    #容器的启动命令列表,如不指定,使用打包时使用的启动命令
    args: [string]     #容器的启动命令参数列表
    workingDir: string     #容器的工作目录
    volumeMounts:    #挂载到容器内部的存储卷配置
    - name: string     #引用pod定义的共享存储卷的名称,需用volumes[]部分定义的的卷名
      mountPath: string    #存储卷在容器内mount的绝对路径,应少于512字符
      readOnly: boolean    #是否为只读模式
    ports:       #需要暴露的端口库号列表
    - name: string     #端口号名称
      containerPort: int   #容器需要监听的端口号
      hostPort: int    #容器所在主机需要监听的端口号,默认与Container相同
      protocol: string     #端口协议,支持TCP和UDP,默认TCP
    env:       #容器运行前需设置的环境变量列表
    - name: string     #环境变量名称
      value: string    #环境变量的值
    resources:       #资源限制和请求的设置
      limits:      #资源限制的设置
        cpu: string    #Cpu的限制,单位为core数,将用于docker run --cpu-shares参数
        memory: string     #内存限制,单位可以为Mib/Gib,将用于docker run --memory参数
      requests:      #资源请求的设置
        cpu: string    #Cpu请求,容器启动的初始可用数量
        memory: string     #内存清楚,容器启动的初始可用数量
    livenessProbe:     #对Pod内个容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可
      exec:      #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式需要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0  #容器启动完成后首次探测的时间,单位为秒
       timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间,单位秒,默认1秒
       periodSeconds: 0    #对容器监控检查的定期探测时间设置,单位秒,默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged:false
    restartPolicy: [Always | Never | OnFailure]#Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该Pod
    nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上,以key:value的格式指定
    imagePullSecrets:    #Pull镜像时使用的secret名称,以key:secretkey格式指定
    - name: string
    hostNetwork:false      #是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
    volumes:       #在该pod上定义共享存储卷列表
    - name: string     #共享存储卷名称 (volumes类型有很多种)
      emptyDir: {}     #类型为emtyDir的存储卷,与Pod同生命周期的一个临时目录。为空值
      hostPath: string     #类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
        path: string     #Pod所在宿主机的目录,将被用于同期中mount的目录
      secret:      #类型为secret的存储卷,挂载集群与定义的secre对象到容器内部
        scretname: string
        items:
        - key: string
          path: string
      configMap:     #类型为configMap的存储卷,挂载预定义的configMap对象到容器内部
        name: string
        items:
        - key: string
          path: string

示例部署:
deployment yml(一个redis的deployment配置文件)

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: redis-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: default.Deployment.redis_server
    spec:
      containers:
      - name: redis
        image: redis:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 6379
      volumes:
        - name: data
          emptyDir: {}

service yaml

kind: Service
apiVersion: v1
metadata:
  name: redis
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 6379
    targetPort: 6379
    nodePort: 30379
    name: test
  selector:
    app: default.Deployment.redis_server        

secret yml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  username: xxx
  password: yyy

# 敏感数据必须是base64编码后的结果,如上面的username和password
# 创建secret用 kubectl apply -f xxx.yml命令

pod读取secret yml

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args:
      - /bin/sh
      - -c
      - sleep 10; touch /tmp/healthy; sleep 30000
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
# k8s会在 /etc/foo 下创建文件,每个数据创建一个文件,文件名是数据的key
# 即 会存在 username 和 password两个文件,内容就是其内容的明文存储
# volume方式支持动态更新

pod也可以使用环境变量方式读取secret数据,但不支持动态更新

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args:
      - /bin/sh
      - -c
      - sleep 10; touch /tmp/healthy; sleep 30000
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password

configMap yml
和secret大致相似

piVersion: v1
kind: ConfigMap
metadata:
  name: myconfigMap
data:
  config1: xxx
  config2: yyy
    #调用方式和secret相似,对应类型换成configMap就OK了

另外还可以通过模版生成
? 用run命令生成
kubectl run --image=nginx my-deploy -o yaml --dry-run > my-deploy.yaml
? 用get命令导出
kubectl get my-deploy/nginx -o=yaml --export > my-deploy.yaml
? Pod容器的字段拼写忘记了
kubectl explain pods.spec.containers

原文地址:https://blog.51cto.com/1014810/2476388

时间: 2024-08-30 18:10:09

(四)kubernetes 资源编排(YAML)的相关文章

Kubernetes之二workload资源编排

资源配置清单用编排yaml的方式来编排Docker,采用RTETful的接口风格,主要的资源对象如下图 自主式Pod资源(不受控制器控制) 资源的清单格式: 一级字段:apiVersion(group/version), kind, metadata(name,namespace,labels,annotations, ...), spec, status(只读) Pod资源: spec.containers <[]object> - name <string> image <

Kubernetes服务编排的利器——Helm

博文大纲:一.Helm简介二.Helm组件及相关术语1)Helm2)Tiller3)Chart4)Repoistory5)Release三.Helm工作原理四.部署Helm1)安装Helm客户端2)安装Tiller server3)配置Helm仓库4)测试Helm是否可 一.Helm简介 很多人都使用过Ubuntu下的ap-get或者CentOS下的yum, 这两者都是Linux系统下的包管理工具.采用apt-get/yum,应用开发者可以管理应用包之间的依赖关系,发布应用:用户则可以以简单的方

技术培训 | 资源编排,人人都可以成为架构师

今天和大家分享的话题是如何利用青云资源编排服务快速创建批量资源组合.规划和构建系统,同时谈谈资源编排如何帮助我们复制一整套IT环境,以及如何实现跨区做相同架构资源的拷贝. 资源编排到底是什么呢? 大家知道云服务本质上是做 IT 架构软件化和 IT 平台智能化的工作. 传统方式我们构建一个系统,不管是做医疗.教育还是金融.媒体等等,最上层需要部署自身的业务代码: 中间层是业务依赖的专业软件.平台中间件.服务组件等: 下层是部署的硬件系统,包括计算节点.存储资源.网络,然后安装操作系统等等. 中下两

服务器太多了不好管?UCloud基于Terraform的资源编排工具详解

背景 随着用户在 UCloud 上资源用量的指数增长,传统 API/SDK 手动编写脚本的资源管理方式已经无法满足其需要.为此,UCloud 研发团队基于 Terraform 编写了一套自己的资源编排工具,帮助用户降低云上资源的管理成本,为其提供安全可靠.高度一致的产品使用体验,尽可能消除迁移上云时的风险. Terraform 代表了业界前沿的技术和标准,我们基于此,并配合 UCloud CLI 等工具,编写了新一代 UCloud 资源编排工具,进一步拓展 Terraform 的功能,实现基础设

4、kubernetes资源清单快速入门190625

一.资源清单概念 资源/对象的类型 工作负载型资源:Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, Cronjob, ... 服务发现及均衡性资源:Service, Ingress, ... 配置与存储型资源:Volume, CSI, ConfigMap, DownwardAPI 集群级资源:Namespace, Node, Role, ClusterRole, RoleBinding, ClusterRoleBinding 元

深入理解 Kubernetes 资源限制:CPU

原文地址:https://www.yangcs.net/posts/understanding-resource-limits-in-kubernetes-cpu-time/ 在关于 Kubernetes 资源限制的系列文章的第一篇文章中,我讨论了如何使用 ResourceRequirements 对象来设置 Pod 中容器的内存资源限制,以及如何通过容器运行时和 linux control group(cgroup)来实现这些限制.我还谈到了 Requests 和 Limits 之间的区别,其

IaC云资源编排-Terraform

Terraform 2019/10/14 Chenxin 整理 转自: https://cloud.tencent.com/developer/article/1469162 IaC与资源编排 IaC(Infrastructure as Code)这一理念随着云技术的普及以及多云时代的到来而被广泛接受和认可,特别是众多生态工具产品的涌现使得IaC由概念逐渐成为现实. 1.与传统的"ClickOps"管理模式相比,IaC主要可以在以下3方面优势: 提高资源部署的速度和效率 所有的云服务都

资源编排之自动化运维

资源编排ROS 资源编排(Resource Orchestration)是一种简单易用的云计算资源管理和自动化运维服务.用户通过模板描述多个云计算资源的依赖关系.配置等,并自动完成所有资源的创建和配置,以达到自动化部署.运维等目的.编排模板同时也是一种标准化的资源和应用交付方式,并且可以随时编辑修改,使基础设施即代码(Infrastructure as Code)成为可能. https://www.aliyun.com/product/ros?spm=5176.100239.blogrighta

深入理解Kubernetes资源限制:CPU

写在前面在上一篇关于Kubernetes资源限制的文章我们讨论了如何通过ResourceRequirements设置Pod中容器内存限制,以及容器运行时是如何利用Linux Cgroups实现这些限制的.也分析了requests是用来通知调度器Pod所需资源需求和limits是在宿主机遇到内存压力时帮助内核限制资源二者的区别. 在本文中,我会继续深入探讨CPU时间的requests和limits.你是否阅读过第一篇文章并不会影响本文的学习,但是我建议你两篇文章都读一读,从而得到工程师或者集群管理