k8s之配置资源管理

一,secret

        Secret 是用来保存密码、token、密钥等敏感数据的 k8s 资源,这类数据虽然也可以存放在 Pod 或者镜像中,但是放在 Secret 中是为了更方便的控制如何使用数据,并减少暴露的风险。

 有三种类型:

1,kubernetes.io/service-account-token:由 Kubernetes 自动创建,用来访问 APIServer 的 Secret,Pod 会默认使用这个 Secret 与 APIServer 通信, 并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中;

2,Opaque :base64 编码格式的 Secret,用来存储用户自定义的密码、密钥等,默认的 Secret 类型;

3,kubernetes.io/dockerconfigjson :用来存储私有 docker registry 的认证信息。

Pod 需要先引用才能使用某个 secret,Pod 有 3 种方式来使用 secret:

●作为挂载到一个或多个容器上的卷 中的文件。
●作为容器的环境变量。
●由 kubelet 在为 Pod 拉取镜像时使用。

具体访问Secrets | Kubernetes

二,创建 Secret

echo -n 'zhangsan' > username.txt
echo -n 'abc1234' > password.txt

kubectl create secret generic mysecret --from-file=username.txt --from-file=password.txt

kubectl get secrets
NAME                  TYPE                                  DATA   AGE
default-token-8pqp6   kubernetes.io/service-account-token   3      3d1h
mysecret              Opaque                                2      51s

kubectl describe secret mysecret
Name:         mysecret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password.txt:  7 bytes
username.txt:  8 bytes
//get或describe指令都不会展示secret的实际内容,这是出于对数据的保护的考虑

2,内容用 base64 编码,创建Secret

echo -n zhangsan | base64
emhhbmdzYW4K=

echo -n abc1234 | base64
YWJjMTIzNAo==

vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysecret1
type: Opaque
data:
  username: emhhbmdzYW4K=
  password: YWJjMTIzNAo==

kubectl create -f secret.yaml 

kubectl get secrets
NAME                  TYPE                                  DATA   AGE
default-token-8pqp6   kubernetes.io/service-account-token   3      3d1h
mysecret              Opaque                                2      43m
mysecret1             Opaque                                2      6s

kubectl get secret mysecret1 -o yaml
apiVersion: v1
data:
  password: YWJjMTIzNAo==
  username: emhhbmdzYW4K=
kind: Secret
metadata:
  creationTimestamp: 2021-05-24T09:11:18Z
  name: mysecret1
  namespace: default
  resourceVersion: "45641"
  selfLink: /api/v1/namespaces/default/secrets/mysecret1
  uid: fffb7902-bc6f-11eb-acba-000c29d88bba
type: Opaque

//使用方式 

1、将 Secret 挂载到 Volume 中,以 Volume 的形式挂载到 Pod 的某个目录下

vim secret-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secrets"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: mysecret

kubectl create -f secret-test.yaml

kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
seret-test   1/1     Running   0          16s

kubectl exec -it seret-test bash
 # cd /etc/secrets/
 # ls
password.txt  username.txt
 # vi password.txt 
 # vi username.txt 
vim secret-test1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod1
spec:
  containers:
  - name: nginx
    image: nginx
    env:
      - name: TEST_USER
        valueFrom:
          secretKeyRef:
            name: mysecret1
            key: username
      - name: TEST_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret1
            key: password

kubectl apply -f secret-test1.yaml 

kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
mypod1       1/1     Running   0          77s

kubectl exec -it mypod bash
 # echo $TEST_USER
zhangsan
 # echo $TEST_PASSWORD
abc1234

//ConfigMap

与Secret类似,区别在于ConfigMap保存的是不需要加密配置的信息。
ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制大对象。
应用场景:应用配置

//创建 ConfigMap
1、使用目录创建0000000000000000000000000

mkdir /opt/configmap/
 
vim /opt/configmap/game.properties
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
 
vim /opt/configmap/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

ls /opt/configmap/
game.properties
ui.properties

kubectl create configmap game-config --from-file=/opt/configmap/
//--from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对,键的名字就是文件名,值就是文件的内容

kubectl get cm
NAME          DATA   AGE
game-config   2      10s

kubectl get cm game-config -o yaml
apiVersion: v1
data:
  game.properties: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2021-05-25T06:49:18Z
  name: game-config
  namespace: default
  resourceVersion: "87803"
  selfLink: /api/v1/namespaces/default/configmaps/game-config
  uid: 541b5302-bd25-11eb-acba-000c29d88bba

2、使用文件创建 
只要指定为一个文件就可以从单个文件中创建 ConfigMap
--from-file 这个参数可以使用多次,即可以使用两次分别指定上个实例中的那两个配置文件,效果就跟指定整个目录是一样的

kubectl create configmap game-config-2 --from-file=/opt/configmap/game.properties --from-file=/opt/configmap/ui.properties

kubectl get configmaps game-config-2 -o yaml

kubectl describe cm game-config-2

3、使用字面值创建 
使用文字值创建,利用 --from-literal 参数传递配置信息,该参数可以使用多次,格式如下
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=good

kubectl get configmaps special-config -o yaml
apiVersion: v1
data:
  special.how: very					#key-value 结构
  special.type: good
kind: ConfigMap
metadata:
  creationTimestamp: 2021-05-25T06:59:37Z
  name: special-config
  namespace: default
  resourceVersion: "88610"
  selfLink: /api/v1/namespaces/default/configmaps/special-config
  uid: c4f45936-bd26-11eb-acba-000c29d88bba


kubectl delete cm --all
kubectl delete pod --all

//Pod 中使用 ConfigMap 

1、使用 ConfigMap 来替代环境变量

vim env.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: good
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO


kubectl create -f env.yaml 

kubectl get cm
NAME             DATA   AGE
env-config       1      6s
special-config   2      6s

//Pod的创建
vim test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    command: [ "/bin/sh", "-c", "env" ]
    env:
      - name: SPECIAL_HOW_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.how
      - name: SPECIAL_TYPE_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.type
    envFrom:
      - configMapRef:
          name: env-config
  restartPolicy: Never


kubectl create -f test-pod.yaml

kubectl get pods
NAME         READY   STATUS      RESTARTS   AGE
pod-test     0/1     Completed   0          33s

kubectl logs pod-test
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.0.0.1:443
HOSTNAME=pod-test
SHLVL=1
SPECIAL_HOW_KEY=very			#赋值变量 SPECIAL_HOW_KEY 的值为 special-config 的 special.how: very
HOME=/root
SPECIAL_TYPE_KEY=good			#赋值变量 SPECIAL_TYPE_KEY 的值为 special-config 的 special.type: good
KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
log_level=INFO					#引入 env-config 的变量 log_level: INFO
KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.0.0.1
PWD=/

2、用 ConfigMap 设置命令行参数 

vim test-pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod2
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    command: 
	- /bin/sh
	- -c
	- echo "$(SPECIAL_HOW_KEY) $(SPECIAL_TYPE_KEY)"
    env:
      - name: SPECIAL_HOW_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.how
      - name: SPECIAL_TYPE_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.type
    envFrom:
      - configMapRef:
          name: env-config
  restartPolicy: Never


kubectl create -f test-pod2.yaml

kubectl get pods
NAME        READY   STATUS      RESTARTS   AGE
test-pod2   0/1     Completed   0          34s

kubectl logs test-pod2
very good

3、通过数据卷插件使用ConfigMap 
在数据卷里面使用 ConfigMap,就是将文件填入数据卷,在这个文件中,键就是文件名,键值就是文件内容

vim test-pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod3
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    command: [ "/bin/sh", "-c", "sleep 36000" ]
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never


kubectl create -f test-pod3.yaml 

kubectl get pods
NAME        READY   STATUS      RESTARTS   AGE
test-pod3   1/1     Running     0          5s

kubectl exec -it test-pod3 sh
 # cd /etc/config/
 # ls
special.how   special.type
 # vi special.how 
 # vi special.type 


//ConfigMap 的热更新 
vim test-pod4.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: log-config
  namespace: default
data:
  log_level: INFO
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: log-config


kubectl apply -f test-pod5.yaml

kubectl get pods 
NAME                        READY   STATUS    RESTARTS   AGE
my-nginx-76b6489f44-6dwxh   1/1     Running   0          46s

kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level
INFO

kubectl edit configmap log-config
apiVersion: v1
data:
  log_level: DEBUG		#INFO 修改成 DEBUG
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"log_level":"DEBUG"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"log-config","namespace":"default"}}			#INFO 修改成 DEBUG
  creationTimestamp: 2021-05-25T07:59:18Z
  name: log-config
  namespace: default
  resourceVersion: "93616"
  selfLink: /api/v1/namespaces/default/configmaps/log-config
  uid: 1b8115de-bd2f-11eb-acba-000c29d88bba
  
//等大概10秒左右,使用该 ConfigMap 挂载的 Volume 中的数据同步更新 
kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level
DEBUG

//ConfigMap 更新后滚动更新 Pod
更新 ConfigMap 目前并不会触发相关 Pod 的滚动更新,可以通过在 .spec.template.metadata.annotations 中添加 version/config ,每次通过修改 version/config 来触发滚动更新

kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20210525" }}}}}'

kubectl get pods 
NAME                        READY   STATUS              RESTARTS   AGE
my-nginx-665dd4dc8c-j4k9t   0/1     ContainerCreating   0          4s
my-nginx-76b6489f44-6dwxh   0/1     Terminating         0          10m

kubectl get pods 
NAME                        READY   STATUS    RESTARTS   AGE
my-nginx-665dd4dc8c-j4k9t   1/1     Running   0          74s


PS:更新 ConfigMap 后:
●使用该 ConfigMap 挂载的 Env 不会同步更新。
●使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间(实测大概10秒)才能同步更新。


<think>嗯,用户想了解Kubernetes集群节点的资源配置最佳实践和要求。首先,我需要回忆一下K8s的官方文档和相关实践经验。记得K8s对节点的资源有一定的建议,但具体数值可能因版本而异。比如,控制平面节点和工作节点的需求不同,控制平面需要更高的CPU和内存来处理调度和API请求。 接下来,用户提到的CPU、内存、存储,每个部分都需要详细说明。CPU方面,控制节点至少需要2核,生产环境可能需要4核以上,而工作节点根据负载调整。内存的话,控制节点至少2GB,生产可能4GB以上,工作节点同样需要根据应用需求来定。存储方面,系统盘、容器运行时、持久化卷这些分区要考虑,还有IOPS的要求。 然后,最佳实践部分,比如资源预留、监控、水平扩展、存储选择、标签管理、污点容忍这些点都要覆盖。用户可能想知道如何优化节点配置,避免资源不足或浪费。另外,引用中的资料提到通过Java查询资源使用情况,说明用户可能对监控工具也有兴趣,可以提到Prometheus或者kubectl top这样的工具。 还要注意用户的真实需求,他们可能在部署集群时遇到资源配置的问题,或者想优化现有集群。需要强调一致性、监控的重要性,以及根据应用负载动态调整的策略。可能还需要解释节点资源不足会导致Pod被驱逐,影响服务稳定性,所以预留资源很关键。 最后,相关问题部分要引导用户深入思考,比如如何监控资源、处理资源不足、优化存储性能,以及自动扩缩容的机制。确保回答结构清晰,分点明确,引用相关的参考资料来增强可信度。需要检查是否有遗漏的重要点,比如节点操作系统、内核版本的影响,或者网络带宽的要求,但根据引用内容,用户主要关注CPU、内存、存储,所以可以集中在这些方面。</think>### Kubernetes集群节点资源配置要求与最佳实践 #### 一、基础资源配置要求 1. **控制平面节点(Master节点)** - **CPU**:至少2核(推荐4核以上),用于处理API请求、调度、控制器等核心组件[^2] - **内存**:最低2GB(生产环境建议4GB以上),需支撑`kube-apiserver`、`etcd`等高消耗组件 - **存储**:系统盘建议50GB以上(需考虑`etcd`数据增长),IOPS不低于500[^3] 2. **工作节点(Worker节点)** - **CPU**:根据负载动态调整,建议预留至少1核供系统/K8s组件使用 - **内存**:总量需满足`Pod需求 + 系统预留(至少1GB)`,避免因OOM(内存溢出)导致Pod驱逐 - **存储**: - 容器运行时存储(如Docker):推荐100GB以上,支持镜像分层 - 持久化卷(PV):独立分区,根据业务需求配置(如SSD优化IO密集型应用) #### 二、最佳实践 1. **资源预留策略** - 通过`kubelet`配置`--system-reserved`和`--kube-reserved`参数,为系统/K8s组件保留资源 - 示例:预留10% CPU和15%内存防止资源争抢 ```yaml kubeletArguments: system-reserved: ["cpu=500m,memory=1Gi"] ``` 2. **监控与调优** - 使用`kubectl top nodes`或`Prometheus`监控实时资源利用率[^1] - 通过`Vertical Pod Autoscaler(VPA)`自动调整Pod资源请求 3. **水平扩展原则** - 单节点资源上限建议: - CPU不超过64核(避免调度粒度问题) - 内存不超过256GB(防止垃圾回收延迟) 4. **存储配置建议** - 使用本地SSD或高性能云盘(如AWS EBS gp3) - 分离`/var/lib/kubelet`(Pod卷)和`/var/lib/docker`(镜像存储)的存储路径 #### 三、特殊场景要求 1. **有状态应用(如数据库)** - 配置`Local PersistentVolume`并绑定NUMA节点,减少跨CPU访问延迟 - 内存分配需包含缓存需求(如Redis建议预留30%额外内存) 2. **边缘计算场景** - 最小化节点配置(如1核2GB内存)时,需关闭非核心组件(如`kube-proxy`替换为`Cilium`) #### 四、配置验证方法 ```bash # 查看节点资源容量与分配 kubectl describe nodes | grep -A 10 "Capacity" # 输出示例: # Capacity: # cpu: 8 # memory: 16302084Ki # Allocatable: # cpu: 7800m # memory: 14462244Ki ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值