Skip to content

G
gitlab-k8s

徐晓伟工作室 / gitlab-k8s

通知 2
Star 0
Fork 0
G
gitlab-k8s

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

提交 4da8fd55 编写于 作者: 徐晓伟's avatar 徐晓伟
浏览文件
操作

📝 卷

上级 b1287d7e
隐藏空白更改
内联 并排
Showing with 906 addition and 0 deletion
README.md
浏览文件 @ 4da8fd55
......@@ -88,8 +88,30 @@
##### [kubernetes（k8s）Dashboard 安装](k8s/ui/dashboard-install.md)
#### Volumes 挂载卷/储存卷
##### [挂载卷/储存卷 介绍](k8s/volumes/volumes-intro.md)
##### 将资源对象映射为储存卷
###### [ConfigMap](k8s/volumes/resource-mapping/configmap.md)
###### [Secret](k8s/volumes/resource-mapping/secret.md)
###### [Downward API](k8s/volumes/resource-mapping/downward-api.md)
###### [Projected Volume 投射卷](k8s/volumes/resource-mapping/projected-volume.md)
##### Node 本地储存卷
###### [EmptyDir 空目录](k8s/volumes/local/empty-dir.md)
###### [HostPath 宿主机路径](k8s/volumes/local/host-path.md)
#### Kubernetes（k8s） PV
##### [Persistent Volume 持久卷（未完成）](k8s/pv/persistent-volume.md)
##### [CentOS 7 中安装 NFS](k8s/pv/centos-7-nfs-install.md)
#### Kubernetes（k8s） CSI
......
k8s/pv/persistent-volume.md 0 → 100644
浏览文件 @ 4da8fd55
# 持久卷（Persistent Volume）（未完成）
## 说明
1. [持久卷](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/)
2. 持久卷（PersistentVolume，PV）：
1. 是集群中的一块存储，可以由管理员事先制备（它与储存提供商的具体实现直接相关），或者使用
[存储类（Storage Class）](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/) 来动态制备
2. 持久卷是集群资源，就像节点也是集群资源一样
3. PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期
4. 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
3. 持久卷申领（PersistentVolumeClaim，PVC）：
1. 表达的是用户对存储的请求。概念上与 Pod 类似
2. Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源
3. Pod 可以请求特定数量的资源（CPU 和内存）
4. 同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或
ReadWriteMany 模式之一来挂载，参见
[访问模式](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/#access-modes)
4. 尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源， 常见的情况是针对不同的问题用户需要的是具有不同属性（如，性能）的
PersistentVolume 卷。 集群管理员需要能够提供不同性质的 PersistentVolume， 并且这些 PV
卷之间的差别不仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。 为了满足这类需求，就有了
**存储类（StorageClass）** 资源。
## 配置
k8s/volumes/local/empty-dir.md 0 → 100644
浏览文件 @ 4da8fd55
# EmptyDir 空目录
## 说明
1. [EmptyDir](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#emptydir)
2. 与 Pod 同生命周期的 Node 临时储存
3. 在 Pod 被调度到 Node 时进行创建，在初始状态下目录是空的。
4. 与 Pod 具有相同的生命周期，当 Pod 被销毁时，Node 上相应的目录也会被删除
5. 同一个 Pod 可以有多个容器，多个容器都可以挂载这种 Volume
6. 由于 EmptyDir 类型的储存卷的临时性特点，通常在以下场景中使用
1. 基于磁盘进行合并排序操作时需要的暂存空间
2. 长时间计算任务的中间检查点文件
3. 为某个Web服务提供的临时网站内容文件
7. 以下以 Nginx 的 配置文件为例
## 配置
1. 创建 EmptyDir
```shell
cat > test-emptydir-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: test-emptydir-pod
spec:
containers:
- name: nginx
image: nginx:1.25.0
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
EOF
cat test-emptydir-pod.yaml
kubectl apply -f test-emptydir-pod.yaml
kubectl get pod
```
2. 测试效果
1. 方法1：进入 pod 内部
1. 进入 pod 内部 `kubectl exec -it test-emptydir-pod bash`，查看文件：
1. `ls /cache`
2. 方法2：直接使用命令查看
1. `kubectl exec -it test-emptydir-pod -- ls /cache`
k8s/volumes/local/host-path.md 0 → 100644
浏览文件 @ 4da8fd55
# HostPath 宿主机路径
## 说明
1. [HostPath](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath)
2. 用于将 Node 文件系统的目录或文件挂载到容器内部使用
3. 适合的场景
1. 容器应用的关键数据需要持久化到宿主机上
2. 需要使用Docker中的某些内部数据，可以将主机的 `/var/lib/docker` 目录挂载到容器内
3. 监控系统，例如 cAdvisor 需要采集宿主机 `/sys` 目录下的内容
4. Pod 的启动/运行依赖于宿主机上的某个目录或文件
1. 容器需要与宿主机使用相同的时区（挂载 `/etc/localtime`）
2. 容器需要与宿主机使用相同的本地 DNS（挂载 `/etc/hosts`，如：自建 GitLab 时，GitLab 使用的是域名，无 DNS
记录，宿主机自定义了 `hosts`可以访问，而新建的容器无法访问 GitLab 的域名）
4. 注意事项
1. 如果有多个 Node 节点时，多个 Node 节点上需要被挂载的文件（夹）不同时，会导致多个 Pod 结果不同（例如：多个 Node
节点上的时区/`hosts`不同，可能会导致多个Pod的时区/`hosts`不同）
2. 基于储存资源情况的调度策略，无法计算 HostPath 目录下的磁盘空间，无法计入 Node 的可用资源范围内，可能出现与预期不同的调度结果
3. 如果路径不存在，kubectl 会自动创建目录或文件，owner（所有者）是 root（超级管理员），这意味着容器中的用户（User）不是 root
则无法进行写操作，除非容器时以特权模式（Privileged）运行，或者修改 HostPath 的权限以支持非 root 用户可写
4. HostPath 设置的宿主机目录或文件，不会跟着 Pod 的销毁而删除，只能人为删除
5. 以下以 Nginx 的 配置文件为例
## 配置
1. 创建 hostPath，挂载 `/etc/localtime`
```shell
cat > host-path-volume-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: host-path-volume-pod
spec:
containers:
- name: nginx
# https://hub.docker.com/_/nginx
# Nginx 版本
image: nginx:1.25.0
ports:
# 容器开放的端口号
- containerPort: 80
volumeMounts:
# 挂载主机的时区文件
- name: time-zone
mountPath: /etc/localtime
# https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/
# 配置挂载的数据卷
volumes:
# 挂载主机的时区文件
- name: time-zone
hostPath:
path: /etc/localtime
EOF
cat host-path-volume-pod.yaml
kubectl apply -f host-path-volume-pod.yaml
kubectl get pod
```
测试时间
```shell
# 如果没有 volume 相关的配置，默认为 格林尼治标准时间（0 时区），与北京时间相差 8 小时
# 如果挂载了宿主机的 /etc/localtime 文件，时间输出与宿主机时间相同，为北京时间（以宿主机是东8区北京时间为例）
kubectl exec -it host-path-volume-pod date
```
2. 创建 hostPath，指定 `type: Directory`
```shell
cat > host-path-directory-volume-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: host-path-directory-volume-pod
spec:
containers:
- name: nginx
# https://hub.docker.com/_/nginx
# Nginx 版本
image: nginx:1.25.0
volumeMounts:
- mountPath: /host-data
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /data
# 可选配置
# Directory 表示 目录必须存在，否则 pod 无法创建
type: Directory
EOF
cat host-path-directory-volume-pod.yaml
kubectl apply -f host-path-directory-volume-pod.yaml
kubectl get pod
```
3. 创建 hostPath，指定 `type: FileOrCreate/DirectoryOrCreate`
对于 type 为 `FileOrCreate` 模式的情况，需要注意的是
1. 如果挂载文件有上层目录，则系统不会自动创建上层目录，当上层目录不存在时，Pod 将启动失败
2. 可以将上层目录也设置为一个 hostPath 类型的 Volume，并且设置 type 为 `DirectoryOrCreate`，确保目录不存在时，系统将该目录自动创建出来
```shell
cat > host-path-file-or-create-volume-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: host-path-file-or-create-volume-pod
spec:
containers:
- name: nginx
# https://hub.docker.com/_/nginx
# Nginx 版本
image: nginx:1.25.0
volumeMounts:
- mountPath: /var/local/aaa
name: mydir
- mountPath: /var/local/aaa/1.txt
name: myfile
volumes:
- name: mydir
hostPath:
path: /var/local/aaa # 文件 1.txt 的上层目录
type: DirectoryOrCreate # 确保该目录存在
- name: myfile
hostPath:
path: /var/local/aaa/1.txt
type: FileOrCreate # 确保该文件存在
EOF
cat host-path-file-or-create-volume-pod.yaml
kubectl apply -f host-path-file-or-create-volume-pod.yaml
kubectl get pod
```
k8s/volumes/resource-mapping/configmap.md 0 → 100644
浏览文件 @ 4da8fd55
# ConfigMap
## 说明
1. [ConfigMap](https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/)
2. ConfigMap 主要保存应用程序所需的配置文件，并且通过 Volume 形式挂载到容器内的文件系统中，供容器内的应用程序读取。
3. 以下以 Nginx 的 配置文件为例
## 配置
1. 创建 ConfigMap：nginx-default-config-map.yaml
默认是不生成日志文件 `/var/log/nginx/host.access.log`
```shell
cat > nginx-default-config-map.yaml << EOF
# https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/
# 查看 描述 ：kubectl -n xuxiaowei-cloud describe configmap nginx-default-config-map
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-default-config-map
# 命名空间
# namespace: xuxiaowei-cloud
data:
# 此配置文件的作用：仅仅是为了增加日志
default.conf: |
server {
listen 80;
listen [::]:80;
server_name localhost;
# 此配置文件的作用：仅仅是为了增加日志
access_log /var/log/nginx/host.access.log main;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
EOF
cat nginx-default-config-map.yaml
kubectl apply -f nginx-default-config-map.yaml
kubectl get configmap
```
2. 使用 ConfigMap：nginx-deployment.yaml
```shell
cat > nginx-deployment.yaml << EOF
# https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
# 创建 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
# Deployment 名称
name: nginx-deployment
# 命名空间
# namespace: xuxiaowei-cloud
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
# https://hub.docker.com/_/nginx
# Nginx 版本
image: nginx:1.25.0
ports:
# 容器开放的端口号
- containerPort: 80
volumeMounts:
# 挂载主机的时区文件
- name: time-zone
mountPath: /etc/localtime
# 引用 ConfigMap 创建配置文件
- name: nginx-default-config-volume
# 挂载到容器的目录
# 用于配置 Nginx
mountPath: /etc/nginx/conf.d/
# https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/
# 配置挂载的数据卷
volumes:
# 挂载主机的时区文件
- name: time-zone
hostPath:
path: /etc/localtime
# 引用 ConfigMap 创建配置文件
- name: nginx-default-config-volume
configMap:
name: nginx-default-config-map
items:
- key: default.conf
path: default.conf
---
# https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/
# 创建 Service
apiVersion: v1
kind: Service
metadata:
# Service 名称
name: nginx-service
# 命名空间
# namespace: xuxiaowei-cloud
spec:
ports:
# NodePort：集群外部对 Service 访问使用的端口（默认范围：30000~32767）
# port：Service 内部的端口号
# targetPort：暴露的 Deployment 中容器的端口号
# protocol：端口协议，TCP 或 UDP
# name：仅在存在多个配置时需要填写，如果填写，必须使用字符串（数字需要添加引号）
- nodePort: 30080
port: 80
protocol: TCP
targetPort: 80
selector:
# 将 Service 和 Deployment 关联起来
app: nginx
# NodePort 会将该 Service 暴露到整个集群中的节点上，让外部客户端可以通过节点 IP + NodePort 的方式来访问该 Service
# 还有 ClusterIP 和 LoadBalancer 类型，具体可参考文档
type: NodePort
EOF
cat nginx-deployment.yaml
kubectl apply -f nginx-deployment.yaml
kubectl get pod
kubectl get svc
```
3. 测试效果
1. 访问 http://k8s宿主机IP:30080，观察是否返回 Nginx 默认页面（触发日志生成）
2. 查看日志文件
1. 方法1：进入 pod 内部 `kubectl exec -it nginx的pod名称 bash`，查看日志
1. `tail -f /var/log/nginx/host.access.log`
2. 方法2：直接使用命令查看日志
1. `kubectl exec -it nginx的pod名称 -- tail -f /var/log/nginx/host.access.log`
k8s/volumes/resource-mapping/downward-api.md 0 → 100644
浏览文件 @ 4da8fd55
# Downward API
## 说明
1. [Downward API](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/downward-api/)
2. 通过 Downward API 可以将 Pod 或 Container 的某些元数据信息（例如：Pod 名称、Pod IP、Node
IP、Label、Annotation、容器资源限制等）以文件的形式挂载到容器内，供容器内的应用使用。
3. 以下示例将 Pod 的标签通过 Downward API 挂载为容器内文件。
## 配置
1. 创建 Downward API
```shell
cat > downwardapi.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-downwardapi-volume-example
labels:
zone: us-est-coast
cluster: test-cluster1
rack: rack-22
annotations:
build: two
builder: john-doe
spec:
containers:
- name: client-container
image: busybox
command: [ "sh", "-c" ]
args:
# 循环查看 /etc/podinfo/labels、/etc/podinfo/annotations 文件
- while true; do
if [[ -e /etc/podinfo/labels ]]; then
echo -en '\n\n'; cat /etc/podinfo/labels; fi;
if [[ -e /etc/podinfo/annotations ]]; then
echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
sleep 5;
done;
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
# Downward API 配置
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
EOF
cat downwardapi.yaml
kubectl apply -f downwardapi.yaml
kubectl get pod
```
2. 测试效果
1. 方法1：进入 pod 内部 `kubectl exec -it kubernetes-downwardapi-volume-example sh`，查看文件
1. `cat /etc/podinfo/annotations`
2. `cat /etc/podinfo/labels`
2. 方法2：直接使用命令查看文件
1. `kubectl exec -it kubernetes-downwardapi-volume-example -- cat /etc/podinfo/annotations`
2. `kubectl exec -it kubernetes-downwardapi-volume-example -- cat /etc/podinfo/labels`
3. 方法3：由于启动是一直循环使用 `cat` 查看文件，所以可以通过日志查看
1. `kubectl logs -f kubernetes-downwardapi-volume-example`
k8s/volumes/resource-mapping/projected-volume.md 0 → 100644
浏览文件 @ 4da8fd55
# Projected Volume 投射卷
## 说明
1. [投射卷](https://kubernetes.io/zh-cn/docs/concepts/storage/projected-volumes/)
2. 如果想把配置文件（ConfigMap）和秘钥文件（Secret）放在容器内的同一目录下，通过多个 Volume 是**无法实现**的
3. Projected Volume 投射卷是一种特殊的储存卷类型，用于将一个或多个资源对象（ConfigMap、Secret、Downward API）一次性挂载到容器的同一目录下
4. ServiceAccountToken 通常用于容器内应用访问 API Server 鉴权的场景
5. 以下以 Nginx 为例
## 配置 Projected Volume 中的 ConfigMap、Secret、Downward API
1. 创建 Projected Volume
```shell
cat > projected.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
name: projected-mysecret-1
type: Opaque
data:
# xuxiaowei 计算 Base64 为 eHV4aWFvd2Vp
username: eHV4aWFvd2Vp
---
apiVersion: v1
kind: Secret
metadata:
name: projected-mysecret-2
type: Opaque
data:
# xuxiaowei.com.cn 计算 Base64 为 eHV4aWFvd2VpLmNvbS5jbg==
password: eHV4aWFvd2VpLmNvbS5jbg==
---
# https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/
# 查看 描述 ：kubectl -n xuxiaowei-cloud describe configmap nginx-default-config-map
apiVersion: v1
kind: ConfigMap
metadata:
name: projected-myconfigmap
data:
my-config: |
server {
listen 80;
listen [::]:80;
server_name localhost;
access_log /var/log/nginx/host.access.log main;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
---
apiVersion: v1
kind: Pod
metadata:
name: projected-volume-test-1
labels:
zone: us-est-coast
cluster: test-cluster1
rack: rack-22
annotations:
build: two
builder: john-doe
spec:
containers:
- name: container-test
image: nginx:1.25.0
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: projected-mysecret-1
items:
- key: username
path: my-group/my-username
- downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "cpu_limit"
resourceFieldRef:
containerName: container-test
resource: limits.cpu
- configMap:
name: projected-myconfigmap
items:
- key: my-config
path: my-group/my-config
---
apiVersion: v1
kind: Pod
metadata:
name: projected-volume-test-2
spec:
containers:
- name: container-test
image: nginx:1.25.0
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: projected-mysecret-1
items:
- key: username
path: my-group/my-username
- secret:
name: projected-mysecret-2
items:
- key: password
path: my-group/my-password
mode: 511
EOF
cat projected.yaml
kubectl apply -f projected.yaml
kubectl get configmap
kubectl get secret
kubectl get pod
```
2. 测试效果
1. 方法1：进入 pod 内部
1. 进入 pod 内部 `kubectl exec -it projected-volume-test-1 bash`，查看文件：
1. `cat /projected-volume/cpu_limit`
2. `cat /projected-volume/my-group/my-config`
3. `cat /projected-volume/my-group/my-username`
4. `cat /projected-volume/labels`
2. 进入 pod 内部 `kubectl exec -it projected-volume-test-2 bash`，查看文件：
1. `cat /projected-volume/my-group/my-username`
2. `cat /projected-volume/my-group/my-password`
2. 方法2：直接使用命令查看
1. `kubectl exec -it projected-volume-test-1 -- cat /projected-volume/cpu_limit`
2. `kubectl exec -it projected-volume-test-1 -- cat /projected-volume/my-group/my-config`
3. `kubectl exec -it projected-volume-test-1 -- cat /projected-volume/my-group/username`
4. `kubectl exec -it projected-volume-test-1 -- cat /projected-volume/labels`
5. `kubectl exec -it projected-volume-test-2 -- cat /projected-volume/my-group/username`
6. `kubectl exec -it projected-volume-test-2 -- cat /projected-volume/my-group/password`
## 配置 Projected Volume 中的 ServiceAccountToken
1. 创建 Projected Volume
```shell
cat > projected-volume-service-account-token.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: projected-volume-service-account-token
spec:
containers:
- name: nginx
# https://hub.docker.com/_/nginx
# Nginx 版本
image: nginx:1.25.0
ports:
# 容器开放的端口号
- containerPort: 80
volumeMounts:
# 挂载主机的时区文件
- name: time-zone
mountPath: /etc/localtime
- name: token-vol
mountPath: "/service-account"
readOnly: true
# https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/
# 配置挂载的数据卷
volumes:
# 挂载主机的时区文件
- name: time-zone
hostPath:
path: /etc/localtime
- name: token-vol
projected:
sources:
- serviceAccountToken:
# 预期受众的名称
audience: api
# 过期时间，默认 1h，最少 10min，管理员可以通过 kube-apiserver 启动参数 --service-account-max-token-expiration 限制令牌的最长有效期
expirationSeconds: 3600
path: token
EOF
cat projected-volume-service-account-token.yaml
kubectl apply -f projected-volume-service-account-token.yaml
kubectl get pod
```
2. 测试效果
1. 方法1：进入 pod 内部 `kubectl exec -it projected-volume-service-account-token bash`，查看文件
1. `cat /service-account/token`
2. 方法2：直接使用命令查看文件
1. `kubectl exec -it projected-volume-service-account-token -- cat /service-account/token`
k8s/volumes/resource-mapping/secret.md 0 → 100644
浏览文件 @ 4da8fd55
# Secret
## 说明
1. [Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/)
2. 与 ConfigMap 的用法类似，在 Pod 的 YAML 中可以将 Secret 设置为一个 Volume，然后在容器内通过 volumeMounts 将 Secret 类型的
Volume 挂载到指定目录下
3. 以下以 Nginx 为例
## 配置
1. 创建 Secret：my-secret.yaml
```shell
cat > my-secret.yaml << EOF
# https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/
# 创建 Secret
apiVersion: v1
kind: Secret
metadata:
# Secret 名称
# 注意：此处为冗余写法（相同命名空间、相同名称只会存在一个 Secret）
name: my-secret
# 命名空间
# namespace: xuxiaowei-cloud
# Secret 类型 Opaque 用于存储任何基于字节数组的数据
type: Opaque
data:
# password：Secret 名称为 "my-secret"，主键为 "password" 的值
# 这里的值是经过 base64 编码处理的 MySQL root 用户密码，需要解码才能使用
# xuxiaowei.com.cn 计算 base64 之后为 eHV4aWFvd2VpLmNvbS5jbg==
password: eHV4aWFvd2VpLmNvbS5jbg==
EOF
cat my-secret.yaml
kubectl apply -f my-secret.yaml
kubectl get secret
```
2. 使用 Secret：nginx-deployment-secret.yaml
```shell
cat > nginx-deployment-secret.yaml << EOF
# https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
# 创建 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
# Deployment 名称
name: nginx-deployment-secret
# 命名空间
# namespace: xuxiaowei-cloud
spec:
selector:
matchLabels:
app: nginx-secret
replicas: 1
template:
metadata:
labels:
app: nginx-secret
spec:
containers:
- name: nginx
# https://hub.docker.com/_/nginx
# Nginx 版本
image: nginx:1.25.0
ports:
# 容器开放的端口号
- containerPort: 80
volumeMounts:
# 挂载主机的时区文件
- name: time-zone
mountPath: /etc/localtime
# 引用 Secret 创建文件
- name: foo
mountPath: /etc/foo
# https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/
# 配置挂载的数据卷
volumes:
# 挂载主机的时区文件
- name: time-zone
hostPath:
path: /etc/localtime
# 引用 Secret 创建文件
- name: foo
secret:
secretName: my-secret
---
# https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/
# 创建 Service
apiVersion: v1
kind: Service
metadata:
# Service 名称
name: nginx-service-secret
# 命名空间
# namespace: xuxiaowei-cloud
spec:
ports:
# NodePort：集群外部对 Service 访问使用的端口（默认范围：30000~32767）
# port：Service 内部的端口号
# targetPort：暴露的 Deployment 中容器的端口号
# protocol：端口协议，TCP 或 UDP
# name：仅在存在多个配置时需要填写，如果填写，必须使用字符串（数字需要添加引号）
- nodePort: 30081
port: 80
protocol: TCP
targetPort: 80
selector:
# 将 Service 和 Deployment 关联起来
app: nginx-secret
# NodePort 会将该 Service 暴露到整个集群中的节点上，让外部客户端可以通过节点 IP + NodePort 的方式来访问该 Service
# 还有 ClusterIP 和 LoadBalancer 类型，具体可参考文档
type: NodePort
EOF
cat nginx-deployment-secret.yaml
kubectl apply -f nginx-deployment-secret.yaml
kubectl get pod
kubectl get svc
```
3. 测试效果
1. 方法1：进入 pod 内部 `kubectl exec -it nginx的pod名称 bash`，查看 Secret
1. `cat /etc/foo/password`
2. 方法2：直接使用命令查看日志
1. `kubectl exec -it nginx的pod名称 -- cat /etc/foo/password`
k8s/volumes/volumes-intro.md 0 → 100644
浏览文件 @ 4da8fd55
# kubernetes（k8s） 挂载卷/储存卷 介绍
1. [卷](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/)
1. 为了解决容器内文件（数据）的持久化
2. 为了解决多容器文件（数据）共享
2. 卷类型
1. 更新时间：2023-06-26
2. alpha：内测版
3. beta：公测
4. stable：正式版、稳定版
5. deprecated：已过时
6. removed：已移除
| 卷名称 | 卷说明 | removed | deprecated | alpha | beta | stable |
|---------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|---------|------------|-------|------|--------|
| awsElasticBlockStore |
| | 1.17 |
| | |
| AWS EBS CSI migration complete | awsElasticBlockStore CSI 迁移结束 | |
| 1.17 | | |
| AWS EBS CSI migration | awsElasticBlockStore CSI 迁移 | | |
| | 1.25 |
| azureDisk | | | 1.19 | | | |
| azureDisk CSI migration complete | azureDisk CSI 迁移结束 | | | 1.21 | | |
| azureDisk CSI migration | azureDisk CSI 迁移 | | | | | 1.24 |
| azureFile | | | 1.21 | | | |
| azureFile CSI migration complete | azureFile CSI 迁移结束 | | | 1.21 | | |
| azureFile CSI migration | azureFile CSI 迁移 | | | | | 1.26 |
| cephfs | | | | | | √ |
| cinder | | | 1.18 | | | |
| OpenStack CSI migration | cinder 迁移 | | | | | 1.24 |
| configMap | | | | | | √ |
| emptyDir | | | | | | √ |
| fc (光纤通道) | | | | | | √ |
| gcePersistentDisk | | | 1.17 | | | |
| GCE CSI migration complete | gcePersistentDisk CSI 迁移结束 | | | 1.21 | | |
| GCE CSI migration | gcePersistentDisk CSI 迁移 | | | | | 1.25 |
| gitRepo | | | √ | | | |
| glusterfs | | √ | | | | |
| hostPath | | | | | | √ |
| iscsi | | | | | | √ |
| local | | | | | | √ |
| nfs | nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 | | | | | √ |
| persistentVolumeClaim | | | | | | √ |
| portworxVolume | | | 1.25 | | | |
| Portworx CSI migration | | | | | 1.25 | |
| projected | | | | | | √ |
| rbd | | | | | | √ |
| RBD CSI migration | | |
| 1.23 | | |
| secret | | | | | | √ |
| vsphereVolume | | | √ | | | |
| vSphere CSI migration complete | | | | | 1.19 | |
| vSphere CSI migration | | | | |
| 1.26 |
| Using subPath | | | | | | √ |
| Using subPath with expanded environment variables | | | | | | 1.17 |
| Resources | | | | | | √ |
| Out-of-tree volume plugins | | | | | | √ |
| csi | | | | | | √ |
| flexVolume | | | 1.23 | | | |
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或