kubernetes 中的资源

标签(空格分隔): kubernetes系列


一:kubernetes 中的资源清单
二:kubernetes yaml 格式清单


一. kubernetes 中的资源清单

1.1 k8s 中资源

K8s 中所有的内容都抽象为资源, 资源实例化之后,叫做对象

资源:(适用范围来分配的)

   名称空间级别:
     kubeadmin k8s kube-system 

     kubectl get pod -n default 

   集群级别 : role 

   元数据级别:HPA

名称空间级别:

工作负载型资源( workload ): Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、 CronJob ( ReplicationController 在 v1.11 版本被废弃 ) 

服务发现及负载均衡型资源( ServiceDiscovery LoadBalance ): Service、Ingress、... 

配置与存储型资源: Volume( 存储卷 )、CSI(容器存储接口,可以扩展各种各样的第三方存储卷 ) 

特殊类型的存储卷:ConfigMap( 当配置中心来使用的资源类型 )、Secret(保存敏感数据)、 DownwardAPI(把外部环境中的信息输出给容器)

集群级资源:
Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding

元数据型资源:

HPA、PodTemplate、LimitRange

二:k8s 中的资源清单yaml格式

在 k8s 中,一般使用 yaml 格式的文件来创建符合我们预期期望的 pod ,这样的 yaml 文件我们一般 称为资源清单
简单说明

是一个可读性高,用来表达数据序列的格式。YAML的意思其实是:仍是一种标记语言,但为了强调这种语言以数
据做为中心,而不是以标记语言为重点
基本语法

缩进时不允许使用Tab键,只允许使用空格

缩进的空格数目不重要,只要相同层级的元素左侧对齐即可
 标识注释,从这个字符一直到行尾,都会被解释器忽略
YAML 支持的数据结构

对象:键值对的集合,又称为映射(mapping)/ 哈希(hashes) / 字典(dictionary)
数组:一组按次序排列的值,又称为序列(sequence) / 列表 (list)
纯量(scalars):单个的、不可再分的值 
对象类型:对象的一组键值对,使用冒号结构表示

name: Steve 
age: 18
Yaml 也允许另一种写法,将所有键值对写成一个行内对象
 hash: { name: Steve, age: 18 }
数组类型:一组连词线开头的行,构成一个数组
 animal 
  - Cat 
  - Dog 
数组也可以采用行内表示法

animal: [Cat, Dog]
复合结构:对象和数组可以结合使用,形成复合结构
1 languages: 
2 - Ruby 
3 - Perl 
4 - Python 
5 websites: 
6 YAML: yaml.org 
7 Ruby: ruby-lang.org 
8 Python: python.org 
9 Perl: use.perl.org
纯量:纯量是最基本的、不可再分的值。以下数据类型都属于纯量

1 字符串 布尔值 整数 浮点数 Null 
2 时间 日期 数值直接以字面量的形式表示 number: 12.30 
布尔值用true和false表示 
isSet: true 
null用 ~ 表示 
parent: ~ 
时间采用 ISO8601 格式 
iso8601: 2001-12-14t21:59:43.10-05:00 
日期采用复合 iso8601 格式的年、月、日表示 
date: 1976-07-31 
YAML 允许使用两个感叹号,强制转换数据类型 
e: !!str 123 
f: !!str true
字符串
字符串默认不使用引号表示
str: 这是一行字符串
如果字符串之中包含空格或特殊字符,需要放在引号之中

str: '内容: 字符串'
单引号和双引号都可以使用,双引号不会对特殊字符转义

s1: '内容\n字符串'
s2: "内容\n字符串"
单引号之中如果还有单引号,必须连续使用两个单引号转义
str: 'labor''s day'
字符串可以写成多行,从第二行开始,必须有一个单空格缩进。换行符会被转为 空格
str: 这是一段 
   多行
   字符串
多行字符串可以使用|保留换行符,也可以使用>折叠换行
this: | 
Foo 
Bar 
that: > 
Foo 
Bar

+ 表示保留文字块末尾的换行,- 表示删除字符串末尾的换行
s1: | 
  Foo 
s2: |+ 
  Foo 
s3: |- 
  Foo

三:常用的字段

3.1 必须存在的属性

kubernetes 中的资源_第1张图片

3.2 主要类型对象

kubernetes 中的资源_第2张图片

kubernetes 中的资源_第3张图片

3.3 额外的参数项

kubernetes 中的资源_第4张图片

排查方法:
vim pod.yaml
---

apiVersion: v1 
kind : Pod 
metadata:
  name: myapp-pod
  labels:
    app: myapp
    version: v1 
spec:
  containers:
   - name: app
     image: node04.flyfish/library/myapp:v1
   - name: test
     image: node04.flyfish/library/myapp:v1
---
kubectl apply -f pod.yaml

kubernetes 中的资源_第5张图片

kubectl describe pod myapp-pod

kubernetes 中的资源_第6张图片

kubernetes 中的资源_第7张图片

kubernetes 中的资源_第8张图片

明显运行的第二test 容器没有运行报错
kubectl logs myapp-pod -c test

kubernetes 中的资源_第9张图片

端口被站用告警
删掉这个pod 
kubectl delete pod myapp-pod

kubernetes 中的资源_第10张图片

---
apiVersion: v1 
kind : Pod 
metadata:
  name: myapp-pod
  labels:
    app: myapp
    version: v1 
spec:
  containers:
   - name: app
     image: node04.flyfish/library/myapp:v1

----

删掉下面两行

kubectl create -f pod.yaml

kubernetes 中的资源_第11张图片

image_1e25ibu66jm11ekr19i4f4e1m262.png-82.7kB

kubernetes 中的资源_第12张图片


四:容器生命周期

4.1: pod的生命周期

kubernetes 中的资源_第13张图片

Pod 能够具有多个容器,应用运行在容器里面,但是它也可能有一个或多个先于应用容器启动的 Init
容器
Init 容器与普通的容器非常像,除了如下两点:
Ø Init 容器总是运行到成功完成为止
Ø 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成
如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止。然而,
如果 Pod 对应的 restartPolicy 为 Never,它不会重新启动

4.1.1 容器的initc

因为 Init 容器具有与应用程序容器分离的单独镜像,所以它们的启动相关代码具有如下优势:
Ø 它们可以包含并运行实用工具,但是出于安全考虑,是不建议在应用程序容器镜像中包含这
些实用工具的
Ø 它们可以包含使用工具和定制化代码来安装,但是不能出现在应用程序镜像中。例如,创建
镜像没必要 FROM 另一个镜像,只需要在安装过程中使用类似 sed、 awk、 python 或 dig
这样的工具。
Ø 应用程序镜像可以分离出创建和部署的角色,而没有必要联合它们构建一个单独的镜像。
Ø Init 容器使用 Linux Namespace,所以相对应用程序容器来说具有不同的文件系统视图。因
此,它们能够具有访问 Secret 的权限,而应用程序容器则不能。
Ø 它们必须在应用程序容器启动之前运行完成,而应用程序容器是并行运行的,所以 Init 容
器能够提供了一种简单的阻塞或延迟应用容器的启动的方法,直到满足了一组先决条件。
init-pod.yaml
-----------------------
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
 containers:
 - name: myapp-container
   image: busybox
   command: ['sh', '-c', 'echo The app is running! && sleep 3600']
 initContainers:
 - name: init-myservice
   image: busybox
   command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2;
done;']
 - name: init-mydb
   image: busybox
   command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

---

kubectl apply -f init-pod.yaml

kubernetes 中的资源_第14张图片

vim myservice.yaml

---
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

----
kubectl apply -f myservice.yaml

kubernetes 中的资源_第15张图片

vim myservice2.yaml

---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
 ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
----

kubectl apply -f myservice2.yaml

kubernetes 中的资源_第16张图片

kubernetes 中的资源_第17张图片

1. 在 Pod 启动过程中,Init 容器会按顺序在网络和数据卷初始化之后启动(pase)。每个容器必须在下一个
容器启动之前成功退出

2. 如果由于运行时或失败退出,将导致容器启动失败,它会根据 Pod 的 restartPolicy 指定的策略
进行重试。然而,如果 Pod 的 restartPolicy 设置为 Always,Init 容器失败时会使用RestartPolicy 策略

3. 在所有的 Init 容器没有成功之前,Pod 将不会变成 Ready 状态。Init 容器的端口将不会在Service 中进行聚集。 正在初始化中的 Pod 处于 Pending 状态,但应该会将 Initializing 状态设置为 true

4. 如果 Pod 重启,所有 Init 容器必须重新执行

5.  对 Init 容器 spec的修改被限制在容器image字段,修改其他字段都不会生效。更改 Init容器的 image 字段,等价于重启该 Pod

6. Init 容器具有应用容器的所有字段。除了 readinessProbe,因为 Init 容器无法定义不同于完成
(completion)的就绪(readiness)之外的其他状态。这会在验证过程中强制执行

7. 在 Pod 中的每个 app 和 Init 容器的名称必须唯一;与任何其它容器共享同一个名称,会在验证
时抛出错误

4.1.2 容器的探针

探针是由 kubelet 对容器执行的定期诊断。要执行诊断,kubelet 调用由容器实现的 Handler。有三种类型的处理程序:
1.ExecAction:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

2. TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。

3. HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTP Get请求。如果响应的
状态码大于等于200 且小于 400,则诊断被认为是成功的
每次探测都将获得以下三种结果之一:
   成功:容器通过了诊断。
   失败:容器未通过诊断。
   未知:诊断失败,因此不会采取任何行动

探针的两种方案:

livenessProbe:指示容器是否正在运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将
受到其 重启策略 的影响。如果容器不提供存活探针,则默认状态为 Success

readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败,端点控制器将从与 Pod 匹配的
所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容
器不提供就绪探针,则默认状态为 Success

Pod hook (钩子)是由 Kubernetes  管理的 kubelet  发起的,当容器中的进程启动前或者容器中的进
程终止之前运行,这是包含在容器的生命周期之中。可以同时为 Pod  中的所有容器都配置 hook
Hook  的类型包括两种:
   exec :执行一段命令
   HTTP :发送 HTTP 请求

PodSpec  中有一个 restartPolicy  字段,可能的值为 Always 、 OnFailure  和 Never 。默认为
Always 。 restartPolicy  适用于 Pod  中的所有容器。 restartPolicy  仅指通过同一节点上的
kubelet  重新启动容器。失败的容器由 kubelet  以五分钟为上限的指数退避延迟( 10 秒, 20 秒, 40
秒 ... )重新启动,并在成功执行十分钟后重置。如 Pod  文档 中所述,一旦绑定到一个节点, Pod  将
永远不会重新绑定到另一个节点。

Pod  的 status  字段是一个 PodStatus 对象, PodStatus 中有一个 phase  字段。
Pod  的相位( phase )是 Pod  在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod  的综合汇
总,也不是为了做为综合状态机
Pod  相位的数量和含义是严格指定的。除了本文档中列举的状态外,不应该再假定 Pod  有其他的
phase 

挂起( Pending ): Pod  已被 Kubernetes  系统接受,但有一个或者多个容器镜像尚未创建。等待时间
包括调度 Pod  的时间和通过网络下载镜像的时间,这可能需要花点时间

运行中( Running ):该 Pod  已经绑定到了一个节点上, Pod  中所有的容器都已被创建。至少有一个容
器正在运行,或者正处于启动或重启状态

成功( Succeeded ): Pod  中的所有容器都被成功终止,并且不会再重启

失败( Failed ): Pod  中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容
器以非 0  状态退出或者被系统终止

未知( Unknown ):因为某些原因无法取得 Pod  的状态,通常是因为与 Pod 

readinessProbe-httpget.yaml

---
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: wangyanglinux/myapp:v1
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
---
kubectl apply -f readinessProbe-httpget.yaml 

kubernetes 中的资源_第18张图片

kubernetes 中的资源_第19张图片

进入pod 的命令

kubectl exec readiness-httpget-pod -it -- /bin/sh

kubernetes 中的资源_第20张图片

kubernetes 中的资源_第21张图片

kubernetes 中的资源_第22张图片

image_1e2ne2c9816bltsb12fh14mueu51g.png-42.1kB


vim livenessProbe-exec.yaml 
----
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
    - name: liveness-exec-container
      image: busybox
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]
      livenessProbe:
        exec:
          command: ["test","-e","/tmp/live"]
        initialDelaySeconds: 1
        periodSeconds: 3

----
kubectl apply -f livenessProbe-exec.yaml

kubernetes 中的资源_第23张图片

kubernetes 中的资源_第24张图片

kubernetes 中的资源_第25张图片


vim live-httpd.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: wangyanglinux/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
---  

kubectl apply -f live-httpd.yaml 

kubernetes 中的资源_第26张图片

kubernetes 中的资源_第27张图片

kubernetes 中的资源_第28张图片

image_1e2ngbmp230l1um81etg2ku1ts658.png-113kB


vim live-tcp.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: wangyanglinux/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3
---

kubectl apply -f live-tcp.yaml

kubernetes 中的资源_第29张图片


4.1.3 启动、退出动作

vim stop-start.yaml

---
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: wangyanglinux/myapp:v1
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler > /usr/share/message"]
---
kubectl apply -f stop-start.yaml

kubernetes 中的资源_第30张图片

kubernetes 中的资源_第31张图片

kubernetes 中的资源_第32张图片

kubernetes 中的资源_第33张图片


pod 的分类:
  自主式pod: pod 的退出,此类型的pod 将不会被创建
  控制器类管理的pod: 在控制器的生命周期里面,始终要维持pod 的副本数目