K8S中存在哪些资源

---

什么是资源？

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

集群资源分类（根据实用性范围分类）

• 名称空间级别

  • 工作负载型资源：Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob
  • 服务发现及负载均衡型资源：Service、Ingress
  • 配置与存储资源：Volume（存储卷）、CSI(容器存储接口，可以扩展各种各样的第三方存储卷## 标题)
  • 特殊类型的存储卷：ConfigMap（当配置中心来使用的资源类型）、Secret（保存敏感数据）、DownwardAPI（把外部环境中的信息输出给容器）

• 集群级别

  • Namespace
  • Node
  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

• 元数据型

  • HPA
  • PodTemplate
  • LimitRange

Yaml格式

---

在K8S中，一般使用yaml格式的文件来创建符合我们与其期望的pod，这样的yaml文件我们一般称为资源清单

简单说明

是一个可读性高，用来表达数据序列的格式，YAML的意思其实是：仍是一种标记语言，单位了强调这种语言以数据为中心，而不是以标记语言为重点

基本语法

• 缩进时不允许使用Tab键，只允许使用空格
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
• #标识注释，从这个字符一直到行尾，都会被解释器忽略

YAML支持的数据结构

• 对象：键值对的集合，又称为映射（mapping）、哈希（hashes）、字典（dictionary）
• 数组：一组按次序排列的值，又称为序列（sequence）、列表（list）
• 纯量：单个的，不可再分的值

对象类型：对象的一组键值对，使用冒号表示结构

name: czw
age: 18
1
2

yaml也允许另一种写法，将多有键值对协程一个行内对象

hash: { name: czw, age: 18}
1

数组类型：一组连词线开头的行，构成一个数组

animal
- Cat
- Dog
1
2
3

数组也可以才用行内表示法

animal: [Cat, Dog]
1

复合结构：对象和数组可以结合使用，形成符合结构

languages:
- Java
- Ruby
- Python
websites:
YAML: yaml.org
Ruby: ruby-lang.org
1
2
3
4
5
6
7

纯量：纯量是最基本的、不可再分的值。以下数据都属于纯量

字符串默认不使用引号

str: 这是一行字符串
1

如果字符串志忠包含空格或者特殊字符，需要放在引号之中，并且单引号和双引号都能用

str: '内容： 字符串'
str: "内容： 字符串"
1
2

单引号之中如果还有单引号，必须连续使用两个单引号转义

str: 'labor''s day'
1

字符串可以写成多行，从第二行开始，必须有一个但空格缩进，换行符会被转为空格

Str: 这个是一段
 多行
 字符串
1
2
3

多行字符串可以使用|保留换行符，也可以使用>折叠换行

this: |
  Foo
  Bar
that: >
Foo
Bar
1
2
3
4
5
6

+表示保留文字块末尾的换行(所以说+是默认存在的），-表示删除字符串末尾的换行

s1: |
  Foo
  
s2: |+
  Foo
  
s3: |-
  Foo
1
2
3
4
5
6
7
8

资源清单必须存在的属性

---

主要对象

额外的参数项

---

编写简单资源清单测试（pod模板）

pod.yaml
注意，kind值为Pod，不能小写

apiVersion: v1
kind: Pod
metadata: 
  name: myapp-pod
  namespace: default
  labels:
    app: myapp
spec:
  containers: 
  - name: app
    image: hub.atguigu.com/library/myapp:v1
  - name: test
    image: hub.atguigu.com/library/myapp:v1
1
2
3
4
5
6
7
8
9
10
11
12
13

生成资源

kubectl apply -f pod.yaml
1

查看状态，先进入Running状态，又进入Error状态

出现这个问题的原因也是很正常，咱们在yaml里面写了两个相同的pod所以端口肯定会冲突
查看日志（由于pod中有多个容器，所以添加参数-c），提示端口被占用

kubectl log myapp-pod -c test
1

删除镜像中重复的镜像，重新运行

kubectl delete pod myapp-pod
kubectl get pod
kubectl create -f pod.yaml
kubectl get pod
1
2
3
4

运行结果

访问

kubectl get pod -o wide
curl 10.244.2.13
1
2

容器生命周期

---

容器生命周期图

InitC （Init容器）

初始化容器，不会一直跟随pod的生命周期，数量在大于等于0。Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的Init容器。如果Pod 的 Init容器失败，Kubernetes 会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod 对应的restartPolicy为Never，它不会重新启动

Init容器与普通容器非常像，除了如下两点：

• Init容器总是运行到成功为止
• 每个Init容器必须在下一个Init容器启动之前完成*

initC的作用

• 它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这
  些实用工具的
• 它们可以包含使用工.具和定制化代码来安装，但是不能出现在应用程序镜像中。例如,
  镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、 python 或dig
  这样的工具。
• 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。Init容器使用Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
• 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。例如在pod中发项目，里面包含MySQL与Apache整合PHP的项目，尽管他们有先后调用的顺序，但是MySQL可能启动缓慢，但php项目启动很快，导致服务对外访问的时候无法连接数据库，导致项目无限重启

InitC的应用

master、node1、node2执行指令，安装nslookup指令

yum -y install bind-utils
1

Init容器模板
init-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    # 运行一个myapp-container的pod，pod里面的组容器使用busybox的镜像，运行时输出语句“The app is running”，开始休眠6分钟
    command: ['sh', '-c', 'echo The app is running ! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    # dns会把metadata.name解析成IP，运行一个init-myservice的pod，检测解析是否成功，成功输出
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;' ]
  - name: init-mydb
    image: busybox
    # 检测mydb的svc是否启动成功，成功输出“waiting for mydb”，否则等待两秒后重复
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

删除所有deployment和所有的pod和svc

kubectl delete deployment --all
kubectl delete pod --all
kubectl get svc
kubectl delete svc nginx-deployment
1
2
3
4

myservice服务
myservice.yaml

apiVersion: v1
kind: Service
metadata: 
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
1
2
3
4
5
6
7
8
9

mydb服务
mydb.yaml

kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377
1
2
3
4
5
6
7
8
9

创建pod指令

kubectl create -f init-pod.yaml
kubectl create -f myservice.yaml
kubectl create -f mydb.yaml
1
2
3

等待一段时间后pod就可以被创建了

readiness

就绪检测，pod在running状态但是pod中的服务还不能对外提供服务的状态

//TODO

Liveness

当pod中的nginx成为僵尸进程时，服务依旧在运行但是无法提供服务，此时需要销毁pod或者重启pod

注意：readiness与Liveness没有与Main C左对齐是因为它们可以生命为在容器运行一定时间后进行检测