k8s安装完后, kubectl这个工具可以很方便地让我们操作k8s。。
但其实一旦用于大规模部署, kubectl 就不那么方便了. 这时我们需要用资源编排文件(Resource Orchestration)来实现组合和批量操作。
在k8s 中, 一般使用yaml格式的资源编排文件来创建我们预期期望的pod
1. 资源编排文件 部分
一般情况下, 我们可以把资源编排文件划分为
- 控制器定义
- 被控制对象
例子:
---
### 控制器定义
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: default
spec:
replicas: 3
selector:
matcheLables:
app: nginx
### 被控制对象
template:
metadata:
lables:
app: ngnix
spec:
contianers:
- name: nginx:
images: nginx: latest
ports: 8010
---
2. 资源编排文件 常用字段
2.0 字段大纲
Parameter Name | Description |
---|---|
apiVersion | api 版本 |
kind | 资源类型 |
metadata | 资源元数据 |
spec | 资源规格 |
replicas | 副本数量 |
selector | 标签选择器 |
template | Pod模板 |
containers | 容器配置 |
2.1 必须存在的属性
Parameter Name | Type | Description |
---|---|---|
version | String | K8S API的版本, 目前基本上是v1, 可以用kubectl api-version来查看 |
kind | String | 种类, 这里是值 yaml文件定义的资源类型和角色, 比如: pod 可用kubectl api-resources 查看所欲kind类型 |
metadata | Object | 元数据对象 |
metadata.name | String | 元数据对象的名字, 这里由我们编写, 例如命名pod的名字 |
metadata.namespace | String | 元数据对象所属的命名空间 |
spec | Object | 详细定义对象 |
spec.container[] | list | 定义对象的容器列表, 是个列表 |
spec.container[].name | String | 定义某个容器的名字 |
2.2 spec 主要对象
Parameter Name | Type | Description |
---|---|---|
spec.container[].image | String | 定义某个容器的所用镜像名称 |
spec.container[].imagePullPolicy | String | 定义拉取镜像的策略. 1.Always: 每次都尝试从远程仓库拉取。 2. Never: 表示只从本地拉取镜像。 3. ifNotPresent: 如果本地有该镜像就本地拉取镜像, 否则从远程拉取镜像. 默认是Always |
spec.container[].command[] | List | 指定容器的启动命令,可以有多个,不指定则使用镜像打包时指定的命令 |
spec.container[].args[] | List | 指定容器的启动命令参数, 可以有多个 |
spec.container[].workingDir | String | 指定容器的工作目录 |
spec.container[].VolumnMounts[] | List | 指定容器的存储卷配置 |
spec.container[].VolumnMounts[].name | String | 指定容器的某个存储卷名称 |
spec.container[].VolumnMounts[].mountPath | String | 指定容器的某个存储卷挂载路径 |
spec.container[].VolumnMounts[].readOnly | String | 指定容器的某个存储卷是否是只读, true of false, 默认是true(只读) |
spec.container[].ports[] | List | 指定容器要用到的端口列表 |
spec.container[].ports[].name | string | 指定容器要端口名字,端口还有名字? |
spec.container[].ports[].containerPort | string | 指定容器用到的端口要监听的容器内部端口(mapping) |
spec.container[].ports[].hostPort | string | 指定容器用到的端口要鉴听的所在主机部端口(mapping),默认与前者相同 |
spec.container[].ports[].protocol | string | 指定端口协议, 支持TCP和UDP, 默认TCP |
spec.container[].env[] | List | 制定环境变量列表 |
spec.container[].env[].name | string | 指定环境变量名称 |
spec.container[].env[].value | string | 指定环境变量的值 |
spec.container[].resource | Object | 指定资源限制和资源请求的值 |
spec.container[].resource.limits | Object | 指定容器运行时资源运行上限 |
spec.container[].resource.cpu | Integer | 指定容器运行时能用到的cpu核心个数 |
spec.container[].resource.memory | String | 指定容器运行时能用到的内存大小, 单位为MB GB |
spec.container[].resource.cpu | Integer | 指定容器运行时能用到的cpu核心个数 |
spec.container[].resource.requests | Object | 指定容器启动和调度室的限制设置 |
spec.container[].resource.requests.cpu | Integer | 容器启动初始化时能用到的cpu core个数 |
spec.container[].resource.requests.memory | Integer | 容器启动初始化时能用到的大小 |
2.3 额外的参数
Parameter Name | Type | Description |
---|---|---|
spec.restartPolicy | String | 定义Pod的重启策略 1. Always: Pod 一旦终止运行,Kubelet就会重启它 2. OnFailure: 只有POD 以非0代码退出时,Kubelet 才会尝试重启 3. Never 无论POD是如何终止运行, 都不会被尝试重启 |
spec.nodeSelector | Object | 定义Node的Label过滤标签, 以key:value 格式指定 |
spec.imagePullSecrets | Object | 定义pull 镜像是用secret的名称, 以name: secretkey格式指定 |
spec.hostNetwork | boolean | 是否使用主机网络模式, 默认是false, 设置true表示使用宿主机网络, 不适用docker 网桥, 同时设置了true则无法在同一台宿主机上启动第二个副本 |
3. 快速编写1个yaml文件
如果从零开始手撕1个yaml文件, 相当困难。
3.1 使用 kubectl create 命令生成yaml文件
例子:
# pod1 是资源名字
kubectl create deployment pod1 --image=nginx -o yaml --dry-run > pod1.yaml
一旦加入 -o yaml 参数, 则kubectl create deployment 命令并不会真正执行, 而是生成1个yaml 文件。让我们可以后续基于这个yaml来创建pod
–dry-run 表示kubectl去尝试去执行这个yaml文件, 但执行完 会清空资源
某个版本后, kubectl建议用–dry-run=client 来代替 --dry-run
然后我们可以基于这个生成的模板再修改
3.2 使用kubectl get 命令从已部署的资源中导出yaml文件
先用
kubectl get deploy
命令查看当前的集群部署了什么东西
gateman@k8smaster:~/yamls$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 13d
gateman@k8smaster:~/yamls$
可以见到里面已经有了1个nginx的部署
然后我们用
kubectl get deploy podname -o yaml > podname.yaml
命令来得到yaml文件
gateman@k8smaster:~/yamls$ kubectl get deploy nginx -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2022-10-22T14:03:45Z"
generation: 1
labels:
app: nginx
name: nginx
namespace: default
resourceVersion: "372980"
uid: b7a0d2f1-a49f-4681-a85c-10dfa9fed809
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: nginx
resources: {
}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {
}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 1
conditions:
- lastTransitionTime: "2022-10-22T14:03:45Z"
lastUpdateTime: "2022-10-22T14:04:03Z"
message: ReplicaSet "nginx-6799fc88d8" has successfully progressed.
reason: NewReplicaSetAvailable
status: "True"
type: Progressing
- lastTransitionTime: "2022-10-25T12:40:15Z"
lastUpdateTime: "2022-10-25T12:40:15Z"
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
observedGeneration: 1
readyReplicas: 1
replicas: 1
updatedReplicas: 1
转载:https://blog.csdn.net/nvd11/article/details/127524844
查看评论