Kubernetes(K8s)YAML文件详解

目录

  • 一、yaml文件简介
  • 1)yaml的语法规则:
  • 2)在Kubernetes中,只需要知道两种结构类型即可:
  • 二、yaml常见语法
  • 1)apiVersion
  • 2)kind
  • 3)metadata
  • 4)spec
  • 三、port详解
  • 四、yaml简单示例
  • 1)deployment
  • 2)pod
  • 3)service
  • 五、Label与Selector
  • 1)Label
  • 2)Selector
  • 六、kubectl create还是 kubectl replace二者区别

一、yaml文件简介

Kubernetes只支持YAMLJSON格式创建资源对象,JSON格式用于接口之间消息的传递,适用于开发YAML格式用于配置和管理,适用于云平台管理,YAML是一种简洁的非标记性语言。

1)yaml的语法规则:

  • 大小写敏感
  • 使用缩进表示层级关系
  • 缩进时不允许使用Tal键,只允许使用空格
  • 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可
  • ”#” 表示注释,从这个字符一直到行尾,都会被解析器忽略
  • 注:- – – 为可选的分隔符 ,当需要在一个文件中定义多个结构的时候需要使用

2)在Kubernetes中,只需要知道两种结构类型即可:

  • Lists
  • Maps

2.1)YAML Maps
Map顾名思义指的是字典,即一个Key:Value 的键值对信息。例如:

---
apiVersion: v1
kind: Pod

上述内容表示有两个键apiVersion和kind,分别对应的值为v1和Pod。

Maps的value既能够对应字符串也能够对应一个Maps。例如:

---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web

注:上述的YAML文件中,metadata这个KEY对应的值为一个Maps,而嵌套的labels这个KEY的值又是一个Map。实际使用中可视情况进行多层嵌套。

YAML处理器根据行缩进来知道内容之间的关联。上述例子中,使用两个空格作为缩进,但空格的数据量并不重要,只是至少要求一个空格并且所有缩进保持一致的空格数 。例如,name和labels是相同缩进级别,因此YAML处理器知道他们属于同一map;它知道app是lables的值因为app的缩进更大。

2.2)YAML Lists
List即列表,说白了就是数组,例如:

args
 -beijing
 -shanghai
 -shenzhen
 -guangzhou

可以指定任何数量的项在列表中,每个项的定义以破折号(-)开头,并且与父元素之间存在缩进。

当然Lists的子项也可以是Maps,Maps的子项也可以是List,例如:

---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80
    - name: flaskapp-demo
      image: jcdemo/flaskapp
      ports: 8080

如上述文件所示,定义一个containers的List对象,每个子项都由name、image、ports组成,每个ports都有一个KEY为containerPort的Map组成。

二、yaml常见语法

1)apiVersion

查看当前所有可用的API版本

$ kubectl api-versions

1.6版本之前 apiVsersion:extensions/v1beta1
1.6版本到1.9版本之间:apps/v1beta1
1.9版本之后:apps/v1

常用apiversion

只要记住6个常用的apiversion一般就够用了。

  • v1: Kubernetes API的稳定版本,包含很多核心对象:pod、service等。
  • apps/v1: 包含一些通用的应用层的api组合,如:Deployments, RollingUpdates, and ReplicaSets。
  • batch/v1: 包含与批处理和类似作业的任务相关的对象,如:job、cronjob。
  • autoscaling/v1: 允许根据不同的资源使用指标自动调整容器。
  • networking.k8s.io/v1: 用于Ingress。
  • rbac.authorization.k8s.io/v1:用于RBAC。

下面是官方原文链接,有兴趣的同学可以看看,页面是可以选择语言的,但是中文翻译有点问题,建议中文英文对照着看。 https://kubernetes.io/docs/reference/using-api/

2)kind

kind指定这个资源对象的类型,如 pod、deployment、statefulset、job、cronjob

3)metadata

metadata常用的配置项有 name,namespace,即配置其显示的名字与归属的命名空间。

4)spec

一个嵌套字典与列表的配置项,也是主要的配置项,支持的子项非常多,根据资源对象的不同,子项会有不同的配置。

如一个pod的spec配置:

apiVersion: v1 #必选,版本号,例如v1
kind: Pod #必选,Pod 
metadata: #必选,元数据 
  name: nginx #必选,Pod名称 
  labels: #自定义标签 
     app: nginx #自定义标签名字 
spec: #必选,Pod中容器的详细定义 
     containers: #必选,Pod中容器列表,一个pod里会有多个容器 
        - name: nginx #必选,容器名称 
          image: nginx #必选,容器的镜像名称 
          imagePullPolicy: IfNotPresent # [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像 
          ports: #需要暴露的端口库号列表 
          - containerPort: 80 #容器需要监听的端口号 
     restartPolicy: Always # [Always | Never | OnFailure]#Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该Pod

一个service 的 spec 的配置:

apiVersion: v1
kind: Service
metadata:
  name: service-hello
  labels:
  name: service-hello
spec:
  type: NodePort      #这里代表是NodePort类型的,另外还有ingress,LoadBalancer
  ports:
  - port: 80          #这里的端口和clusterIP(kubectl describe service service-hello中的IP的port)对应,即在集群中所有机器上curl 10.98.166.242:80可访问发布的应用服务。
    targetPort: 8080  #端口一定要和container暴露出来的端口对应,nodejs暴露出来的端口是8081,所以这里也应是8081
    protocol: TCP
    nodePort: 31111   # 所有的节点都会开放此端口30000--32767,此端口供外部调用。
  selector:
    run: hello         #这里选择器一定要选择容器的标签,之前写name:kube-node是错的。

这里是将nginx映射到外网,访问地址就是本机ip:31111

三、port详解

  • port:port是k8s集群内部访问service的端口,即通过clusterIP: port可以访问到某个service
  • nodePort:nodePort是外部访问k8s集群中service的端口,通过nodeIP: nodePort可以从外部访问到某个service。
  • targetPort:targetPort是pod的端口,从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上,最后进入容器。
  • containerPort:containerPort是pod内部容器的端口,targetPort映射到containerPort。

四、yaml简单示例

接下来就是看看deployment、pod、service 这三种资源的说明书例子

1)deployment

apiVersion: apps/v1   # 1.9.0 之前的版本使用 apps/v1beta2,可通过命令 kubectl api-versions 查看
kind: Deployment    #指定创建资源的角色/类型
metadata:    #资源的元数据/属性
  name: nginx-deployment    #资源的名字,在同一个namespace中必须唯一
spec:
  replicas: 2    #副本数量2
  selector:      #定义标签选择器
    matchLabels:
      app: web-server
  template:      #这里Pod的定义
    metadata:
      labels:    #Pod的label
        app: web-server
    spec:        # 指定该资源的内容  
      containers:  
      - name: nginx      #容器的名字  
        image: nginx:1.12.1  #容器的镜像地址    
        ports:  
        - containerPort: 80  #容器对外的端口

执行以下命令创建 deployment 资源

$ kubectl create -f nginx.yaml

2)pod

apiVersion: v1
kind: Pod  
metadata:  
  name: pod-redis
  labels:
    name: redis
spec: 
  containers:
  - name: pod-redis
    image: docker.io/redis  
    ports:
    - containerPort: 80 #容器对外的端口

执行以下命令创建 pod 资源

$ kubectl create -f pod-redis.yaml

3)service

apiVersion: v1  
kind: Service  # 指明资源类型是 service
metadata:  
  name: httpd-svc # service 的名字是 httpd-svc
  labels:  
    name: httpd-svc 
spec:  
  ports:  # 将 service 8080 端口映射到 pod 的 80 端口,使用 TCP 协议
  - port: 8080
    targetPort: 80  
    protocol: TCP  
  selector:  
    run: httpd # 指明哪些 label 的 pod 作为 service 的后端

执行以下命令创建 service 资源

$ kubectl create -f httpd-svc.yaml

五、Label与Selector

1)Label

Label是Kubernetes系列中另外一个核心概念。是一组绑定到K8s资源对象上的key/value对。同一个对象的labels属性的key必须唯一。label可以附加到各种资源对象上,如Node,Pod,Service,RC等。

通过给指定的资源对象捆绑一个或多个不用的label来实现多维度的资源分组管理功能,以便于灵活,方便地进行资源分配,调度,配置,部署等管理工作。

示例如下:

  • 版本标签:”release” : “stable” , “release” : “canary”…
  • 环境标签:”environment” : “dev” , “environment” : “production”
  • 架构标签:”tier” : “frontend” , “tier” : “backend” , “tier” : “middleware”
  • 分区标签:”partition” : “customerA” , “partition” : “customerB”…
  • 质量管控标签:”track” : “daily” , “track” : “weekly”

2)Selector

Label selector是Kubernetes核心的分组机制,通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象。符合这个标签的 Pod 会作为这个 Service 的 backend。

apiVersion: v1
kind: Service
metadata:
  name: hello
  labels:
    app: hello
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: hello

六、kubectl create还是 kubectl replace二者区别

kubectl create -f 还是 kubectl replace -f 都可以创建资源,但是有什么区别呢,请细品下面讲解。

kubectl create:

  • kubectl create命令可创建新资源。 因此,如果再次运行该命令,则会抛出错误,因为资源名称在名称空间中应该是唯一的。

kubectl apply:

  • kubectl apply命令将配置应用于资源。 如果资源不在那里,那么它将被创建。 kubectl apply命令可以多次运行,因为它只是应用如下所示的配置。 在这种情况下,配置没有改变。 所以,pod没有改变。
  • 简单来说,如果在单个文件上运行操作以创建资源,则create和apply基本相同。 但是, apply允许您在目录下的多个文件上同时创建和修补。
Kubernetes(K8s)YAML文件详解
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇