06--kubernetes.pod管理与投射数据卷
前言：上一章记录了摆设k8s常用的两个方式，这一章就简单一些，整理一下k8s资源对象的设置和管理命令。1、集群状态查抄
前天搭建的环境，然后关机了两天今天开启后第一时间需要查抄集群环境是否正常
# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready master 2d17h v1.19.1
k8s-node1 Ready <none> 2d17h v1.19.1
k8s-node2 Ready <none> 2d17h v1.19.1
# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-f9fd979d6-f8rxv 1/1 Running 1 2d17h
coredns-f9fd979d6-frrvc 1/1 Running 1 2d17h
etcd-k8s-master1 1/1 Running 1 2d17h
kube-apiserver-k8s-master1 1/1 Running 1 2d17h
kube-controller-manager-k8s-master1 1/1 Running 1 2d17h
kube-flannel-ds-c576q 1/1 Running 1 2d17h
kube-flannel-ds-hxkww 1/1 Running 2 2d17h
kube-flannel-ds-nm9b2 1/1 Running 2 2d17h
kube-proxy-96cnh 1/1 Running 1 2d17h
kube-proxy-j5gbf 1/1 Running 1 2d17h
kube-proxy-pz2l2 1/1 Running 1 2d17h
kube-scheduler-k8s-master1 1/1 Running 1 2d17h 集群状态正常继续今天的操纵
常用查抄命令
查看service的信息：
# kubectl get service
在不同的namespace里面查看service：
# kubectl get service -n kube-system
-n:namespace名称空间
查看所有名称空间内的pod：
# kubectl get pods --all-namespaces
同时查看多种资源对象的信息：
# kubectl get pod,service -n kube-system
查看主节点：
# kubectl cluster-info
api查询：（写yaml要用）
# kubectl api-versions
也可以查看pod的信息
# kubectl describe node k8s-node1 2、命名空间管理
在 Kubernetes（K8s）中，Namespace（命名空间）就像是一个虚拟的隔间，用于将集群中的资源举行逻辑上的分区。通过创建不同的 Namespace，可以有效地管理和隔离资源，实现更高效的资源管理和权限控制。
Namespace 的作用可以形象地比喻为以下几种场景：
[*] 资源隔离：想象一下一个大型办公楼，每个部分都有自己的独立办公室。不同的部分（Namespace）在自己的办公室（Namespace）里工作，互不干扰。如许，不同部分的资源（如服务、Pod）就不会相互碰撞或冲突，保持清晰和有序。
[*] 资源管理：在办公楼中，全部财政部分的文件、设备和职员都会集在一个区域。类似地，将相干的资源（如应用程序、数据库）放在同一个 Namespace 中，使管理和监控变得更加简单和高效。
[*] 权限控制：在办公楼中，门禁系统可以限制哪些人可以进入哪些区域。通过 Kubernetes 的 RBAC（基于角色的访问控制），你可以设置不同的权限，让只有特定角色的人能够访问或管理特定的 Namespace，就像门禁系统控制访问一样。
[*] 环境隔离：办公楼的不同楼层可能被筹划成不同的用途：一层用于开发，二层用于测试，三层用于生产。类似地，Kubernetes 中可以创建不同的 Namespace 来分别摆设开发、测试和生产环境，确保各个环境之间相互隔离，提拔安全性和稳固性。
检察命名空间
# kubectl get namespace
NAME STATUS AGE
default Active 2d17h
kube-flannel Active 2d17h
kube-node-lease Active 2d17h
kube-public Active 2d17h
kube-system Active 2d17h
# kubectl get ns
NAME STATUS AGE
default Active 2d17h
kube-flannel Active 2d17h
kube-node-lease Active 2d17h
kube-public Active 2d17h
kube-system Active 2d17h 创建命名空间
使用yaml文件创建ns
# mkdir namespace.yaml.d
# cd namespace.yaml.d/
# vim namespace1.yaml
# cat namespace1.yaml
---
apiVersion: v1
kind: Namespace #设定创建资源对象类型
metadata: #元数据
name: ns-example #ns名字
labels:
this_ns_name: name_is_ns-example #标签
创建ns
# kubectl apply -f namespace1.yaml
namespace/ns-example created
查看ns
# kubectl get ns
NAME STATUS AGE
default Active 2d18h
kube-flannel Active 2d17h
kube-node-lease Active 2d18h
kube-public Active 2d18h
kube-system Active 2d18h
ns-example Active 15s
# kubectl get ns ns-example
NAME STATUS AGE
ns-example Active 46s
# kubectl describe namespace ns-example
Name: ns-example
Labels: this_ns_name=name_is_ns-example
Annotations:<none>
Status: Active
No resource quota.
No LimitRange resource.
删除ns
# kubectl delete -f namespace1.yaml
# kubectl delete namespace ns-example 一个yaml/yml内可以写两个资源对象
# vim namespace2.yml
# cat namespace2.yml
---
apiVersion: v1
kind: Namespace
metadata:
name: ns-example
labels:
this_ns_name: name_is_ns-example
---
apiVersion: v1
kind: Namespace
metadata:
name: ns-example2
labels:
this_ns_name2: name_is_ns-example
# kubectl apply -f namespace2.yml
namespace/ns-example created
namespace/ns-example2 created
# kubectl get ns
NAME STATUS AGE
default Active 2d18h
kube-flannel Active 2d18h
kube-node-lease Active 2d18h
kube-public Active 2d18h
kube-system Active 2d18h
ns-example Active 6s
ns-example2 Active 6s 3、pod管理
3.1、创建pod
任务：发布第一个容器化应用
[*]制作镜像：作为应用开发者，你首先需要制作容器镜像。
[*]组织镜像：将镜像按 Kubernetes 的规范整理，并提交上去。
Kubernetes 项目能"认识"的方式：
Kubernetes 不保举直接利用命令行运行容器，而是利用 YAML 或 JSON 设置文件来定义和管理容器。你需要将容器的定义、参数和设置记录在 YAML 文件中，然后利用以下指令运行：
# kubectl create -f 配置文件
好处：
[*]文件记录了 Kubernetes 运行了什么，便于后续检察。
利用 YAML 创建 Pod：
YAML 文件在 Kubernetes 中对应 API 对象。填写字段并提交，Kubernetes 会根据定义创建容器或其他 API 资源。
编写yaml
# vim pod1.yml
# cat pod1.yml
---
apiVersion: v1
kind: Pod
metadata:
name: websit
labels:
this-pod-name: this-is-websit
spec:
containers:
- name: name-of-websit-nginx
image: linuxserver/nginx
ports:
- containerPort: 80
#############注意事项#########
自定义字段命名规则（ DNS-1123 标签）：
必须只包含小写字母（a-z）、数字（0-9）和连字符（-）。
必须以字母或数字开头和结尾。
不能包含大写字母或其他字符。
创建pod
# kubectl apply -f pod1.yml
pod/websit created
# kubectl get pod
NAME READY STATUS RESTARTS AGE
websit 1/1 Running 0 9s
这里有一个需要了解的点：
pod的准备状况指的是Pod是否准备就绪以接收请求，Pod的准备状况取决于容器，即全部容器都准备就绪了，Pod才准备就绪。这时间kubernetes的代理服务才会添加Pod作为后端，而一旦Pod的准备状况变为false(至少一个容器的准备状况为false),kubernetes会将Pod从代理服务的分发后端移除，即不会分发请求给该Pod。
一个pod刚被创建的时间是不会被调度的，由于没有任何节点被选择用来运行这个pod。调度的过程发生在创建完成之后，但是这个过程一样寻常很快，所以通常看不到pod是处于unscheduler状态的除非创建的过程遇到了问题。
pod被调度之后，分配到指定的节点上运行，这时间，如果该节点没有所需要的image，那么将会主动从默认的Docker Hub上pull指定的image，一切就绪之后，看到pod是处于running状态了
3.2、pod管理
检察pod
# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
websit 1/1 Running 0 4m5s 10.244.1.2 k8s-node1 <none> <none>
#在k8s看来创建了一个pod，在node1上使用docker ps可以看到新建的容器
#这里能看到pod的ip，可以尝试访问 检察pod的具体信息
# kubectl describe pod websit -n 命名空间 https://i-blog.csdnimg.cn/direct/47671e5634c44cee97f2c1f7fb070610.png
也可以利用yaml导出
# kubectl get pod websit -o yaml -n default https://i-blog.csdnimg.cn/direct/46f74ec46316469191fdc0ad6440c45f.png
进入pod
# kubectl exec -it websit /bin/sh 删除pod
# kubectl delete pod website
# kubectl delete -f pod1.yml
批量删除用法
# kubectl delete pod --all
# kubectl delete pod pod名1 pod名2 增补：
kubectl create 和 kubectl apply 是两个用于管理 Kubernetes 资源的命令，但它们在处理资源的方式上有一些关键区别。
kubectl create
功能：用于创建新的资源对象。
用法：kubectl create -f <file.yaml>
行为：
只适用于创建资源。它不会对已经存在的资源进行更新。
如果你需要更新资源，你必须首先删除现有资源，然后重新创建。例如，如果你修改了 YAML 文件中的配置，你需要先使用 kubectl delete -f <file.yaml> 删除现有的资源，然后使用 kubectl create -f <file.yaml> 重新创建。
kubectl apply
功能：用于创建或更新资源对象。
用法：kubectl apply -f <file.yaml>
行为：
创建：如果资源不存在，apply 会创建它。
更新：如果资源已经存在，apply 会自动检测到 YAML 文件中的更改，并更新现有资源。这意味着你可以修改 YAML 文件，然后再次运行 kubectl apply -f <file.yaml>，Kubernetes 会处理更新，无需删除资源。
pod的hosts解析
临时创建，删除容器后重新创建失效
操纵方式：进入pod内部编辑hosts文件
永久创建：修改yaml/yml文件
操纵方式如下
# kubectl delete -f pod1.yml
pod "websit" deleted
# vim pod1.yml
# cat pod1.yml
---
apiVersion: v1
kind: Pod
metadata:
name: websit
labels:
this-pod-name: this-is-websit
spec:
containers:
- name: name-of-websit-nginx
image: linuxserver/nginx
ports:
- containerPort: 80
hostAliases:
- ip: "192.168.188.101"
hostnames:
- "k8s-master"
- "su-zhu-ji"
- "www.master.com"
- ip: "192.168.188.102"
hostnames:
- "k8s-node1"
- "node-node-1"
- "www.node1.com" 根据此文件创建pod，完成后进入容器，效果如下
# kubectl apply -f pod1.yml
pod/websit created
# kubectl exec -it websit /bin/sh
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@websit:/# cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.1.5 websit
# Entries added by HostAliases.
192.168.188.101 k8s-master su-zhu-ji www.master.com
192.168.188.102 k8s-node1 node-node-1 www.node1.com
root@websit:/# ping www.master.com
PING www.master.com (192.168.188.101): 56 data bytes
64 bytes from 192.168.188.101: seq=0 ttl=63 time=0.304 ms
64 bytes from 192.168.188.101: seq=1 ttl=63 time=0.387 ms
64 bytes from 192.168.188.101: seq=2 ttl=63 time=0.269 ms
^C
--- www.master.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.269/0.320/0.387 ms
root@websit:/# 3.3、pod生命周期
常见状态：
[*]Pending：此状态表示Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并生存在 Etcd 当中（准备状态）。但这个 Pod 里有些容器由于某种原因而不能被顺利创建。比如，调度不乐成。
[*]Running：此状态表示Pod 已经调度乐成，跟一个具体的节点绑定。它包罗的容器都已经创建乐成，而且至少有一个正在运行中。（只有这个状态是正常的）
[*]Succeeded：此状态表示 Pod 里的全部容器都正常运行完毕，而且已经退出了。这种环境在运行一次性任务时最为常见。
[*]Failed：此状态表示 Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如检察 Pod 的 Events 和日记。
[*]Unknown：这是一个异常状态(未知状态)，表示 Pod 的状态不能一连地被 kubelet 汇报给 kube-apiserver这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题
其他状态：
CrashLoopBackOff： 容器退出，kubelet正在将它重启
InvalidImageName： 无法解析镜像名称
ImageInspectError： 无法校验镜像
ErrImageNeverPull： 策略克制拉取镜像
ImagePullBackOff： 正在重试拉取
RegistryUnavailable： 毗连不到镜像中心
ErrImagePull： 通用的拉取镜像出错
CreateContainerConfigError： 不能创建kubelet利用的容器设置
CreateContainerError： 创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError： 启动容器失败
PostStartHookError： 执行hook报错
ContainersNotInitialized： 容器没有初始化完毕
ContainersNotReady： 容器没有准备完毕
ContainerCreating：容器创建中
PodInitializing：pod 初始化中
DockerDaemonNotReady：docker还没有完全启动
NetworkPluginNotReady： 网络插件还没有完全启动
4、投射数据卷 Projected Volume
Projected Volume 是 Kubernetes v1.11 之后引入的新特性，类似于 Docker 中的映射卷（docker run -v）。
在 Kubernetes 中，有几种特殊的 Volume 不是为了存放容器数据，也不是用来举行容器和宿主机之间的数据互换，而是为了为容器提供预先定义好的数据。从容器的角度来看，这些 Volume 里的信息仿佛是被 Kubernetes "投射"（Project）进入容器当中的。
Kubernetes 支持的 Projected Volume 包罗四种类型（这些在k8s中都被看做资源对象）：
[*]Secret
[*]ConfigMap
[*]Downward API
[*]ServiceAccount
4.1、secret
secret介绍：
[*]secret用来生存小片敏感数据的k8s资源对象，例如暗码，token，或者秘钥。这类数据固然也可以存放在Pod或者镜像中，但是放在Secret中是为了更方便的控制怎样利用数据，并减少袒露的风险。
[*]用户可以创建自己的secret，系统也会有自己的secret。
[*]Pod需要先引用才能利用某个secret
pod利用secre的方式：
[*]內建的Secrets:：由ServiceAccount创建的API证书附加的秘钥k8s主动天生的用来访问apiserver的Secret，全部Pod会默认利用这个Secret与apiserver通信
https://i-blog.csdnimg.cn/direct/fd58918dad6643bba8c5e10982edfed6.png
[*]创建自己的Secret：利用kubectl create secret命令或yaml文件创建Secret
4.1.1、创建secret
命令创建secret：
# echo -n 'admin' > username.txt
# echo -n 'Liumuquan@123' > password.txt
# kubectl create secret generic db-user-pass --from-file=username.txt --from-file=password.txt
secret/db-user-pass created
#kubectl get secret
NAME TYPE DATA AGE
db-user-pass Opaque 2 3s
default-token-l87r2 kubernetes.io/service-account-token 3 5d17h
查看详细信息
# kubectl describe secret db-user-pass
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations:<none>
Type:Opaque
Data
====
password.txt:13 bytes
username.txt:5 bytes
# kubectl get secret db-user-pass -o yaml
apiVersion: v1
data:
password.txt: TGl1bXVxdWFuQDEyMw==
username.txt: YWRtaW4=
kind: Secret
metadata:
creationTimestamp: "2024-08-20T10:15:04Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:password.txt: {}
f:username.txt: {}
f:type: {}
manager: kubectl-create
operation: Update
time: "2024-08-20T10:15:04Z"
name: db-user-pass
namespace: default
resourceVersion: "70826"
selfLink: /api/v1/namespaces/default/secrets/db-user-pass
uid: fddaf0fd-96ac-461c-88df-f301a8dcbd08
type: Opaque
对data选项举行解码
# echo TGl1bXVxdWFuQDEyMw== | base64 --decode
Liumuquan@123 yaml创建secret：
明文显示容易袒露，先转码，再写入文件
# echo -n "admin" | base64
YWRtaW4=
# echo -n "123456" | base64
MTIzNDU2
# mkdir secret.yaml.d
# cd secret.yaml.d/
# vim secret1.yaml
# cat secret1.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MTIzNDU2
# kubectl apply -f secret1.yaml
secret/mysecret created
检察secret
# kubectl get secrets
NAME TYPE DATA AGE
db-user-pass Opaque 2 22m
default-token-l87r2 kubernetes.io/service-account-token 3 5d17h
mysecret Opaque 2 10s
# kubectl get secret mysecret -o yaml -n default
apiVersion: v1
data:
password: MTIzNDU2
username: YWRtaW4=
kind: Secret
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"password":"MTIzNDU2","username":"YWRtaW4="},"kind":"Secret","metadata":{"annotations":{},"name":"mysecret","namespace":"default"},"type":"Opaque"}
creationTimestamp: "2024-08-20T10:37:34Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:password: {}
f:username: {}
f:metadata:
f:annotations:
.: {}
f:kubectl.kubernetes.io/last-applied-configuration: {}
f:type: {}
manager: kubectl-client-side-apply
operation: Update
time: "2024-08-20T10:37:34Z"
name: mysecret
namespace: default
resourceVersion: "74069"
selfLink: /api/v1/namespaces/default/secrets/mysecret
uid: a66ffa02-f40f-4b1b-ab47-efb35c9bc829
type: Opaque
4.1.2、引用secret
1）卷挂载方式引用
创建pod文件，并以卷挂载格式引用secret
# vim pod_use_secret.yaml
# cat pod_use_secret.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: testredis
image: daocloud.io/library/redis
volumeMounts: #挂载一个卷
- name: foo #这个名字需要与定义的卷的名字一致
mountPath: "/etc/foo"#挂载到容器里哪个目录下，随便写
readOnly: true
volumes: #数据卷的定义
- name: foo #卷的名字这个名字自定义
secret: #卷是直接使用的secret。
secretName: mysecret #调用刚才定义的secret
创建pod并进入pod检察挂载的目次
# kubectl apply -f pod_use_secret.yaml
pod/mypod created
# kubectl get pod
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 10s
websit 1/1 Running 0 105m
# kubectl exec -it mypod /bin/sh
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@mypod:/# ls /etc/foo
passwordusername
root@mypod:/# cat /etc/foo/username
admin 这种方式会将secret中全部key全部引用
映射secret key
删除刚创建的pod，创建pod文件如下
# cat pod_use_secret.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: testnginx
image: linuxserver/nginx
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
items: #定义一个items
- key: username #将那个key重新定义到那个目录下
path: my-group/my-username#相对路径，相对于/etc/foo的路径
创建pod并进入pod检察挂载的目次
# kubectl apply -f pod_use_secret.yaml
pod/mypod created
# kubectl get pod
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 10s
# kubectl exec -it mypod /bin/sh
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@mypod:/# ls /etc/foo
my-group
root@mypod:/# ls /etc/foo/my-group/
my-username
root@mypod:/# cat /etc/foo/my-group/my-username
admin 修改secret的值，然后重新设置secret
# echo -n "Administrator" | base64
QWRtaW5pc3RyYXRvcg==
# vim /root/secret.yaml.d/secret1.yaml
# cat /root/secret.yaml.d/secret1.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: QWRtaW5pc3RyYXRvcg==
password: MTIzNDU2
# kubectl apply -f /root/secret.yaml.d/secret1.yaml
secret/mysecret configured
secret主动更新
等待一段时间进入pod内部
# kubectl exec -it mypod /bin/sh
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@mypod:/# cat /etc/foo/my-group/my-username
Administrator 卷挂载方式是可以主动更新的，后面演示的环境变量方式是无法主动更新的
2）环境变量方式引用
以mysql的用户名和暗码为例，先创建secert和pod文件
# echo -n "root" | base64
cm9vdA==
# echo -n "Liumuquan@123" | base64
TGl1bXVxdWFuQDEyMw==
# cat pod_mysql_secert.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: mysql-user-pass
type: Opaque
data:
username: cm9vdA==
password: TGl1bXVxdWFuQDEyMw==
---
apiVersion: v1
kind: Pod
metadata:
name: mysql
spec:
containers:
- name: mysql
image: docker pull registry.cn-chengdu.aliyuncs.com/liumuquan_app/mysql:5.7
env:
- name: MYSQL_ROOT_PASSWORD#创建新的环境变量名称
valueFrom:
secretKeyRef: #调用的key是什么
name: mysql-user-pass#变量的值来自于mysecret
key: password #username里面的 根据yaml文件创建镜像
# kubectl apply -f pod_mysql_secert.yaml 验证暗码是否设置乐成
# kubectl exec -it mysql /bin/bash
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
bash-4.2# mysql -uroot -p'Liumuquan@123'
mysql: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.44 MySQL Community Server (GPL)
Copyright (c) 2000, 2023, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
修改yaml后应用文件，并不会更新暗码。
4.1.3、私有仓库secret应用
以阿里云私有仓库为例
# kubectl create secret docker-registry myregistrykey --docker-server=registry.cn-chengdu.aliyuncs.com --docker-username=liumuquan --docker-password=XXXX密码XXXX secret引用
https://i-blog.csdnimg.cn/direct/09d218ef47da48478942a5a42b67da84.png
4.2、ConfigMap
ConfigMap 与 Secret 类似，用来存储设置文件的kubernetes资源对象，全部的设置内容都存储在etcd中。ConfigMap 生存的是不需要加密的、应用所需的设置信息。
ConfigMap 的用法几乎与 Secret 完全类似：可以利用 kubectl create configmap 从文件或者目次创建 ConfigMap，也可以直接编写 ConfigMap 对象的 YAML 文件。
创建ConfigMap有四种方式（也可以说是两种）
[*]方式1：通过直接在命令行中指定configmap参数创建，即--from-literal
[*]方式2：通过指定文件创建，即将一个设置文件创建为一个ConfigMap，--from-file=<文件>
[*]方式3：通过指定目次创建，即将一个目次下的全部设置文件创建为一个ConfigMap，--from-file=<目次>
[*]方式4：事先写好尺度的 configmap的yaml文件，然后kubectl create -f 创建
4.2.1、创建configmap
1)命令行--from-literal创建
# kubectl create configmap test-configmap --from-literal=user=liumuquan --from-literal=pass=mypassword@123
configmap/test-configmap created
# kubectl get configmap
NAME DATA AGE
test-configmap 2 14s
# kubectl get cm
NAME DATA AGE
test-configmap 2 19s
2)指定文件创建
# vim mysql_configmapm_test
# cat mysql_configmapm_test
key.1 = value-1
key.2 = value-2
key.3 = value-3
key.4 = value-4
!include /home/wing/mysql/etc/mysqld.cnf
port = 3306
socket = /home/wing/mysql/tmp/mysql.sock
pid-file = /wing/mysql/mysql/var/mysql.pid
basedir = /home/mysql/mysql
datadir = /wing/mysql/mysql/var
# kubectl create configmap test-configmap2 --from-file=mysql_configmapm_test
configmap/test-configmap2 created
可以指定多个文件 效果如下：
https://i-blog.csdnimg.cn/direct/ccd02ee607234e12bea92fb1a824c2b6.png
3)指定目次创建
# mkdir configmap_test
# cd configmap_test/
# pwd
/root/configmap.d/configmap_test
# vim configmap_test1
# cat configmap_test1
aaa
bbb
ccc
ddd
a=d
# vim configmap_test2
# cat configmap_test2
eee
fff
h=p
# cd ..
# kubectl create configmap test-configmap3 --from-file=configmap_test
configmap/test-configmap3 created 效果如下：
https://i-blog.csdnimg.cn/direct/e7e3eb8a6e3844cf91df10ca49ea4079.png
这里内容格式为key:value,对应为文件名：文件内容
4)yaml文件创建
# vim configmap4.yaml
# cat configmap4.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: test-configmap4
namespace: default
data:
key1_cache_host: memcached-gcxt
key2_cache_port: "11211"
key3_cache_prefix: gcxt
my.cnf: |
log-bin = mysql-bin
haha = hehe
# kubectl apply -f configmap4.yaml
configmap/test-configmap4 created 效果如下：
https://i-blog.csdnimg.cn/direct/6b72d884303647c28c574d6127c7973b.png
4.2.2、引用configmap
利用ConfigMap有三种方式，一种是通过环境变量的方式，直接通报pod，另一种是通过在pod的命令行下运行的方式，第三种（最常用的）是利用volume的方式挂载入到pod内
利用卷挂载这里有一个需要注意的地方，就是subPath的利用：
在 Linux 中，将目次 A 挂载到目次 B 时，目次 B 中原有的文件会被目次 A 下的文件覆盖。在 Kubernetes 中，可以利用 subPath 将 ConfigMap 挂载到容器中某个目次的文件中，从而制止覆盖该目次下的其他文件。
利用 subPath 可以将 ConfigMap 或 Secret 挂载为容器中某个目次的文件，而不会覆盖挂载目次下的现有文件。然而，利用 subPath 参数后，设置文件不支持热更新。
卷挂载利用方式如下：
先做一份nginx的设置文件出来
# cat /etc/nginx/nginx.conf > configmap_nginx 创建configmap
# kubectl create cm cm-nginx --from-file=configmap_nginx 创建pod文件并引用configmap
# cd /root/pod.yaml.d/
# vim nginx-cm-pod.yaml
# cat nginx-cm-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: nginx-cm-test
spec:
containers:
- name: nginx
image: registry.cn-chengdu.aliyuncs.com/liumuquan_app/nginx:1.20.1
volumeMounts:
- name: nginx
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf #只覆盖这一个文件，不影响该路径其他文件
volumes:
- name: nginx
configMap:
name: cm-nginx
items:
- key: configmap_nginx #这个值来自于-o yaml查看
path: nginx.conf #挂载到pod内产生的文件名
创建pod
# kubectl apply -f nginx-cm-pod.yaml
pod/nginx-cm-test created
# kubectl get pod
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 1 25h
mysql 1/1 Running 0 5h52m
nginx-cm-test 1/1 Running 0 3s
这个cm是利用命令行方式创建的，修改方式有所不同
# kubectl edit configmap cm-nginx
纵然颠末上面方式修改文件，已经创建的pod内并不会随之更新
4.2.3、ConfigMap 的热更新
[*]利用 ConfigMap 挂载的环境变量 (Env) 不会同步更新。
[*]利用 ConfigMap 挂载的卷 (Volume) 中的数据需要一些时间（大约 10 秒）才能同步更新。请注意：
[*]只有通过 YAML 文件创建的 ConfigMap 才支持热更新。
[*]不能利用 subPath 参数。
附注：当 ConfigMap 作为数据卷挂载到 Pod 中时，更新或重新创建 ConfigMap 后，Pod 内部的设置会热更新。但如果 ConfigMap 用作环境变量，环境变量不会主动更新，由于它们在容器启动时被注入，启动后 Kubernetes 不会改变环境变量的值。此外，同一 namespace 中的 Pod 的环境变量是累加的
以下为操纵方式以nginx搭建反向代理为例：
yaml文件如下
# vim nginx-pod.yaml
# cat nginx-pod.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap-yaml
data:
server1.conf: |-
upstream tomcatserver1 {
server 192.168.15.55:8081;
}
server {
listen 80;
server_name 8081.max.com;
location / {
proxy_pass http://tomcatserver1;
index index.html index.htm;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
---
apiVersion: v1
kind: Pod
metadata:
name: configmap-pod
spec:
containers:
- name: nginx
image: registry.cn-chengdu.aliyuncs.com/liumuquan_app/nginx:1.20.1
ports:
- containerPort: 80
volumeMounts:
- mountPath: /etc/nginx/conf.d
name: conf-name
volumes:
- name: conf-name
configMap:
name: configmap-yaml
items:
- key: server1.conf
path: server1.conf 创建cm和pod
# kubectl apply -f nginx-pod.yaml
configmap/configmap-yaml created
pod/configmap-pod created
# kubectl get cm
NAME DATA AGE
cm-nginx 1 46m
configmap-yaml 1 17s
# kubectl get pod
NAME READY STATUS RESTARTS AGE
configmap-pod 1/1 Running 0 21s
mypod 1/1 Running 1 25h
mysql 1/1 Running 0 6h13m
nginx-cm-test 1/1 Running 0 21m
进入刚创建的pod内部检察设置
# kubectl exec -it configmap-pod /bin/sh
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
# ls /etc/nginx/conf.d/
server1.conf
# cat /etc/nginx/conf.d/server1.conf
upstream tomcatserver1 {
server 192.168.15.55:8081;
}
server {
listen 80;
server_name 8081.max.com;
location / {
proxy_pass http://tomcatserver1;
index index.html index.htm;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}#
出去修改cm内容，查抄热更新
# vim nginx-pod.yaml
# kubectl apply nginx-pod.yaml
error: must specify one of -f and -k
# kubectl apply -f nginx-pod.yaml
configmap/configmap-yaml configured
pod/configmap-pod configured
# 此处需要等待一段时间，热更新速度较慢
# kubectl exec -it configmap-pod /bin/bash
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@configmap-pod:/# cat /etc/nginx/conf.d/server1.conf
upstream tomcatserver1 {
server 111.111.111.111:1111;
}
server {
listen 2222;
server_name 3333.max.com;
location / {
proxy_pass http://tomcatserver1;
index index.html index.htm;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}root@configmap-pod:/#
内部ip和端口已经被修改，此时无需重启nginx，配置自动载入 4.3、Downward API
Downward API 用于在容器中获取 POD 的根本信息，kubernetes支持 Downward API提供了两种方式用于将 POD 的信息注入到容器内部，无需提前创建：
[*]环境变量：用于单个变量，可以将 POD 信息和容器信息直接注入容器内部。
[*]Volume挂载：将 POD 信息天生为文件，直接挂载到容器内部中去。
环境变量的方式：
通过Downward API来将 POD 的 IP、名称以及所对应的 namespace 注入到容器的环境变量中去，然后在容器中打印全部的环境变量来举行验证
利用fieldRef获取 POD 的根本信息，示例如下：
# vim test-env-pod.yml
# cat test-env-pod.yml
---
apiVersion: v1
kind: Pod
metadata:
name: test-env-pod
namespace: kube-system
spec:
containers:
- name: test-env-pod
image: registry.cn-chengdu.aliyuncs.com/liumuquan_app/nginx:1.20.1
env:
- name: POD_NAME #第一个环境变量的名字
valueFrom: #使用valueFrom方式设置
fieldRef: #关联一个字段metadata.name(元数据的字段)
fieldPath: metadata.name#这个字段从当前运行的pod详细信息查看
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
这个podIP可以通过-o yaml查看
创建pod，进入pod检察设置的环境变量
# kubectl apply -f test-env-pod.yml
# kubectl get pod -n kube-system | grep test
test-env-pod 1/1 Running 0 4m45s
# kubectl exec -it test-env-pod -n kube-system /bin/bash
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@test-env-pod:/# echo $POD_NAME
test-env-pod
root@test-env-pod:/# echo $POD_NAMESPACE
kube-system
root@test-env-pod:/# echo $POD_IP
10.244.1.9
Volume挂载
通过Downward API将 POD 的 Label、Annotation 等信息通过 Volume 挂载到容器的某个文件中去，然后在容器中打印出该文件的值来验证
操纵如下：
# vim test-volume-pod.yaml
# cat test-volume-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: test-volume-pod
namespace: kube-system
labels:
k8s-app: test-volume
node-env: test
spec:
containers:
- name: test-volume-pod-container
image: registry.cn-chengdu.aliyuncs.com/liumuquan_app/nginx:1.20.1
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
创建pod，进入pod检察设置的环境变量
# kubectl apply -f test-volume-pod.yaml
pod/test-volume-pod created
# kubectl get pod -n kube-system | grep test-volume-pod
test-volume-pod 1/1 Running 0 32s
# kubectl exec -it test-volume-pod -n kube-system /bin/bash
kubectl exec is DEPRECATED and will be removed in a future version. Use kubectl exec -- instead.
root@test-volume-pod:/# cat /etc/podinfo/labels
k8s-app="test-volume"
node-env="test"root 在实际应用中，如果你的应用有获取 POD 的根本信息的需求，就可以利用Downward API来获取根本信息，然后编写一个启动脚本或者利用initContainer将 POD 的信息注入到容器中去，然后在自己的应用中就可以正常的处理相干逻辑了。
现在 Downward API 支持的字段（常用部分）：
1. 使用 fieldRef 可以声明使用:
spec.nodeName - 宿主机名字
status.hostIP - 宿主机 IP
metadata.name - Pod 的名字
metadata.namespace - Pod 的 Namespace
status.podIP - Pod 的 IP
spec.serviceAccountName - Pod 的 Service Account 的名字
metadata.uid - Pod 的 UID
metadata.labels['<KEY>'] - 指定 <KEY> 的 Label 值
metadata.annotations['<KEY>'] - 指定 <KEY> 的 Annotation 值
metadata.labels - Pod 的所有 Label
metadata.annotations - Pod 的所有 Annotation Secret、ConfigMap，以及 Downward API 这三种 Projected Volume 定义的信息，大多还可以通过环境变量的方式出现在容器里。但是，通过环境变量获取这些信息的方式，不具备主动更新的本事。一样寻常环境下，发起利用 Volume 文件的方式获取这些信息（根据资源对象用途判断）。
4.4、ServiceAccount
ServiceAccount是一种 Kubernetes 资源，用于提供身份给 Pod。ServiceAccount 允许 Pod 访问 Kubernetes API 服务器，通常是为了举行 API 操纵或与 Kubernetes 集群交互。ServiceAccount 通常与角色（Role）和角色绑定（RoleBinding）结合利用，以控制 Pod 访问 Kubernetes API 的权限。
利用场景：
[*]为 Pod 提供访问 Kubernetes API 的权限。
[*]定义 Pod 访问集群资源的权限和方式。
这一部分先临时做一个了解，后面会在用到的地方举行具体表明
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]