文章目录

  • ConfigMap
    • 创建
      • 命令行创建cm
    • 使用
  • Secret
    • Opaque Secret
    • 使用方式环境变量
    • 使用方式volume挂载
  • kubernetes.io/dockerconfigjson
  • kubernetes.io/service-account-token
  • ServiceAccount

ConfigMap

可变配置管理

前面我们学习了一些常用的资源对象的使用,但是单纯依靠这些资源对象,还不足以满足我们的日常需求,一个重要的需求就是应用的配置管理、敏感信息的存储和使用(如:密码、Token 等)、容器运行资源的配置、安全管控、身份认证等等。

对于应用的可变配置在 Kubernetes 中是通过一个 ConfigMap 资源对象来实现的,我们知道许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求,这些配置信息我们肯定不会直接写死到应用程序中去的,比如你一个应用连接一个 redis 服务,下一次想更换一个了的,还得重新去修改代码,重新制作一个镜像,这肯定是不可取的,而 ConfigMap 就给我们提供了向容器中注入配置信息的能力,不仅可以用来保存单个属性,还可以用来保存整个配置文件,比如我们可以用来配置一个 redis 服务的访问地址,也可以用来保存整个 redis 的配置文件。接下来我们就来了解下 ConfigMap 这种资源对象的使用方法。

一般都是用来做配置文件,或者存放些铭感信息密码或者token

创建

ConfigMap 资源对象使用 key-value 形式的键值对来配置数据,这些数据可以在 Pod 里面使用

kind: ConfigMap
apiVersion: v1
metadata:name: cm-demonamespace: default
data:data.1: hellodata.2: worldconfig: |property.1=value-1property.2=value-2property.3=value-3

文件名是config,是key,文件内容是value

其中配置数据在 data 属性下面进行配置,前两个被用来保存单个属性,后面一个被用来保存一个配置文件

create或apply yaml文件即可

命令行创建cm

通过命令行来创建cm也不少:

可以使用kubectl create configmap -h来查看关于创建 ConfigMap 的帮助信息:Examples:# Create a new configmap named my-config based on folder barkubectl create configmap my-config --from-file=path/to/bar# Create a new configmap named my-config with specified keys instead of file basenames on diskkubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt# Create a new configmap named my-config with key1=config1 and key2=config2kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

我们可以看到可以从一个给定的目录来创建一个 ConfigMap 对象,比如我们有一个 testcm 的目录,该目录下面包含一些配置文件,redis 和 mysql 的连接信息,如下:

$ ls testcm
redis.conf
mysql.conf$ cat testcm/redis.conf
host=127.0.0.1
port=6379$ cat testcm/mysql.conf
host=127.0.0.1
port=3306
kubectl create configmap cm-demo1 --from-file=testcm其中 from-file 参数指定在该目录下面的所有文件都会被用在 ConfigMap 里面创建一个键值对,键的名字就是文件名,值就是文件的内容kubectl describe configmap cm-demo1
Name:         cm-demo1
Namespace:    default
Labels:       <none>
Annotations:  <none>Data
====
mysql.conf:
----
host=127.0.0.1
port=3306redis.conf:
----
host=127.0.0.1
port=6379Events:  <none>

如果信息太大,展示不完整,用kubectl get(建议使用它查看)

$ kubectl get configmap cm-demo1 -o yaml
apiVersion: v1
data:mysql.conf: |host=127.0.0.1port=3306redis.conf: |host=127.0.0.1port=6379
kind: ConfigMap
metadata:creationTimestamp: 2018-06-14T16:24:36Zname: cm-demo1namespace: defaultresourceVersion: "3109975"selfLink: /api/v1/namespaces/default/configmaps/cm-demo1uid: 6e0f4d82-6fef-11e8-a101-525400db4df7
除了通过文件目录进行创建,我们也可以使用指定的文件进行创建 ConfigMap,同样的,以上面的配置文件为例,我们创建一个 redis 的配置的一个单独 ConfigMap 对象:$ kubectl create configmap cm-demo2 --from-file=testcm/redis.conf
configmap "cm-demo2" created
$ kubectl get configmap cm-demo2 -o yaml
apiVersion: v1
data:redis.conf: |host=127.0.0.1port=6379
kind: ConfigMap
metadata:creationTimestamp: 2018-06-14T16:34:29Zname: cm-demo2namespace: defaultresourceVersion: "3110758"selfLink: /api/v1/namespaces/default/configmaps/cm-demo2uid: cf59675d-6ff0-11e8-a101-525400db4df7我们可以看到一个关联 redis.conf 文件配置信息的 ConfigMap 对象创建成功了,另外值得注意的是 --from-file 这个参数可以使用多次,比如我们这里使用两次分别指定 redis.conf 和 mysql.conf 文件,就和直接指定整个目录是一样的效果了。通过 --from-literal 参数传递配置信息,同样的,这个参数可以使用多次,格式如下:$ kubectl create configmap cm-demo3 --from-literal=db.host=localhost --from-literal=db.port=3306
configmap "cm-demo3" created
$ kubectl get configmap cm-demo3 -o yaml
apiVersion: v1
data:db.host: localhostdb.port: "3306"
kind: ConfigMap
metadata:creationTimestamp: 2018-06-14T16:43:12Zname: cm-demo3namespace: defaultresourceVersion: "3111447"selfLink: /api/v1/namespaces/default/configmaps/cm-demo3uid: 06eeec7e-6ff2-11e8-a101-525400db4df7

使用

ConfigMap 创建成功了,那么我们应该怎么在 Pod 中来使用呢?我们说 ConfigMap 这些配置数据可以通过很多种方式在 Pod 里使用,主要有以下几种方式:

设置环境变量的值
在容器里设置命令行参数
在数据卷里面挂载配置文件

使用 ConfigMap 来填充我们的环境变量

apiVersion: v1
kind: Pod
metadata:name: testcm1-pod
spec:containers:- name: testcm1image: busyboxcommand: [ "/bin/sh", "-c", "env" ]env:- name: DB_HOSTvalueFrom:configMapKeyRef:name: cm-demo3key: db.host- name: DB_PORTvalueFrom:configMapKeyRef:name: cm-demo3key: db.portenvFrom:- configMapRef:name: cm-demo1
env:
- name:valueFrom:filedRef:filedPath:env:
- name:valueFrom:configMapKeyRef:name:key:

这个 Pod 运行后会输出如下所示的信息:

$ kubectl logs testcm1-pod
......
DB_HOST=localhost
DB_PORT=3306
mysql.conf=host=127.0.0.1
port=3306
redis.conf=host=127.0.0.1
port=6379
......

我们可以看到 DB_HOST 和 DB_PORT 都已经正常输出了,另外的环境变量是因为我们这里直接把 cm-demo1 给注入进来了,所以把他们的整个键值给输出出来了,这也是符合预期的。

另外我们也可以使用 ConfigMap来设置命令行参数,ConfigMap 也可以被用来设置容器中的命令或者参数值,如下 Pod:

apiVersion: v1
kind: Pod
metadata:name: testcm2-pod
spec:containers:- name: testcm2image: busyboxcommand: [ "/bin/sh", "-c", "echo $(DB_HOST) $(DB_PORT)" ]env:- name: DB_HOSTvalueFrom:configMapKeyRef:name: cm-demo3key: db.host- name: DB_PORTvalueFrom:configMapKeyRef:name: cm-demo3key: db.port

运行这个 Pod 后会输出如下信息:

$ kubectl logs testcm2-pod
localhost 3306

另外一种是非常常见的使用 ConfigMap 的方式:通过数据卷使用,在数据卷里面使用 ConfigMap,就是将文件填入数据卷,在这个文件中,键就是文件名,键值就是文件内容

apiVersion: v1
kind: Pod
metadata:name: testcm3-pod
spec:volumes:- name: config-volumeconfigMap:   #configmap类型的volume,包括前面的有hostpath,emptydir,configmapname: cm-demo2containers:- name: testcm3image: busyboxcommand: [ "/bin/sh", "-c", "cat /etc/config/redis.conf" ]volumeMounts:- name: config-volumemountPath: /etc/config

运行这个 Pod 的,查看日志:

$ kubectl logs testcm3-pod
host=127.0.0.1
port=6379

当然我们也可以在 ConfigMap 值被映射的数据卷里去控制路径,如下 Pod 定义:

apiVersion: v1
kind: Pod
metadata:name: testcm4-pod
spec:volumes:- name: config-volumeconfigMap:name: cm-demo1items:- key: mysql.confpath: path/to/msyql.confcontainers:- name: testcm4image: busyboxcommand: [ "/bin/sh","-c","cat /etc/config/path/to/msyql.conf" ]volumeMounts:- name: config-volumemountPath: /etc/config

运行这个Pod的,查看日志:

$ kubectl logs testcm4-pod
host=127.0.0.1
port=3306

另外需要注意的是,当 ConfigMap 以数据卷的形式挂载进 Pod 的时,这时更新 ConfigMap(或删掉重建ConfigMap),Pod 内挂载的配置信息会热更新。这时可以增加一些监测配置文件变更的脚本,然后重加载对应服务就可以实现应用的热更新。

使用注意

只有通过 Kubernetes API 创建的 Pod 才能使用 ConfigMap,其他方式创建的(比如静态
Pod)不能使用;ConfigMap 文件大小限制为 1MB(ETCD 的要求)。

Secret

敏感信息配置管理

前文我们学习 ConfigMap 的时候,我们说 ConfigMap 这个资源对象是 Kubernetes 当中非常重要的一个资源对象,一般情况下 ConfigMap 是用来存储一些非安全的配置信息,如果涉及到一些安全相关的数据的话用 ConfigMap 就非常不妥了,因为 ConfigMap 是明文存储的,这个时候我们就需要用到另外一个资源对象了:Secret,Secret用来保存敏感信息,例如密码、OAuth 令牌和 ssh key 等等,将这些信息放在 Secret 中比放在 Pod 的定义中或者 Docker 镜像中要更加安全和灵活。

Secret 主要使用的有以下三种类型:

Opaque:base64 编码格式的 Secret,用来存储密码、密钥等;但数据也可以通过base64–decode解码得到原始数据,所有加密性很弱。 kubernetes.io/dockerconfigjson:用来存储私有docker registry的认证信息。
kubernetes.io/service-account-token:用于 ServiceAccount,ServiceAccount 创建时 Kubernetes 会默认创建一个对应的 Secret 对象,Pod 如果使用了ServiceAccount,对应的 Secret 会自动挂载到 Pod 目录/run/secrets/kubernetes.io/serviceaccount 中。
bootstrap.kubernetes.io/token:用于节点接入集群的校验的 Secret

Opaque Secret

opaque 不透明的
Opaque 类型的数据是一个 map 类型(字典类型,键值对),要求 value 必须是 base64 编码格式,比如我们来创建一个用户名为 admin,密码为 admin321 的 Secret 对象,首先我们需要先把用户名和密码做 base64 编码

进行base64编码时,如果使用echo要有-n去掉结尾的换行符,base64解码则不用

$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "admin321" | base64
YWRtaW4zMjE=
apiVersion: v1
kind: Secret
metadata:name: mysecret
type: Opaque
data:username: YWRtaW4=password: YWRtaW4zMjE=

apply即可

查看
kubectl get secret一样可以用describe和get -o yaml查看详情

创建好 Secret对象后,有两种方式来使用它:

以环境变量的形式
以Volume的形式挂载

使用方式环境变量

apiVersion: v1
kind: Pod
metadata:name: secret1-pod
spec:containers:- name: secret1image: busyboxcommand: [ "/bin/sh", "-c", "env" ]env:- name: USERNAMEvalueFrom:secretKeyRef:name: mysecretkey: username- name: PASSWORDvalueFrom:secretKeyRef:name: mysecretkey: passwordapply即可,这里用了命令env列出,所以可以用logs列出

使用方式volume挂载

apiVersion: v1
kind: Pod
metadata:name: secret2-pod
spec:containers:- name: secret2image: busyboxcommand: ["/bin/sh", "-c", "ls /etc/secrets"]volumeMounts:- name: secretsmountPath: /etc/secretsvolumes:- name: secretssecret:secretName: mysecret

可以看到 Secret 把两个 key 挂载成了两个对应的文件

在 secretName 下面添加 items 指定 key 和 path,可以用来改变挂载进来后文件的路径,当然是给予挂载的目录,在该目录下的路径,比如目录是/tmp/1,挂载的文件是test,可以改成/tmp/1/2/test

kubernetes.io/dockerconfigjson

除了上面的 Opaque 这种类型外,我们还可以来创建用户 docker registry 认证的 Secret,直接使用`kubectl create 命令创建即可,如下:

$ kubectl create secret docker-registry myregistry --docker-server=DOCKER_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
secret "myregistry" created

除了上面这种方法之外,我们也可以通过指定文件的方式来创建镜像仓库认证信息,需要注意对应的 KEY 和 TYPE:

$ kubectl create secret generic myregistry --from-file=.dockerconfigjson=/root/.docker/config.json --type=kubernetes.io/dockerconfigjson
本来文件名是key,这里用.dockerconfigjson,value是/root/.docker/config.json的内容,就是写私有仓库的登录信息,用户名,仓库地址,密码。email{"auths": {"harbor.k8s.local": {"auth": "YWRtaW46SGFyYm9yMTIzNDU="}}
}
username password的加密编码

创建secret时不指定类型那么就是opaque类型,generic是却缺省的还有一个tls的命令,用来创建tls secret

然后查看 Secret 列表:

$ kubectl get secret
NAME                  TYPE                                  DATA      AGE
default-token-n9w2d   kubernetes.io/service-account-token   3         33d
myregistry            kubernetes.io/dockerconfigjson        1         15s
mysecret              Opaque                                2         34m
$ kubectl get secret myregistry -o yaml
apiVersion: v1
data:.dockerconfigjson: eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0=
kind: Secret
metadata:creationTimestamp: 2018-06-19T16:01:05Zname: myregistrynamespace: defaultresourceVersion: "3696966"selfLink: /api/v1/namespaces/default/secrets/myregistryuid: f91db707-73d9-11e8-a101-525400db4df7
type: kubernetes.io/dockerconfigjson$ echo eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0= | base64 -d
{"auths":{"DOCKER_SERVER":{"username":"DOCKER_USER","password":"DOCKER_PASSWORD","email":"DOCKER_EMAIL","auth":"RE9DS0VSX1VTRVI6RE9DS0VSX1BBU1NXT1JE"}}}
如果我们需要拉取私有仓库中的 Docker 镜像的话就需要使用到上面的 myregistry 这个 Secret:apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: fooimage: 192.168.1.100:5000/test:v1imagePullSecrets:- name: myregistry

ImagePullSecrets 与 Secrets 不同,因为 Secrets 可以挂载到 Pod 中,但是 ImagePullSecrets 只能由 Kubelet 访问。镜像下载也是y由kubelet控制(容器的一切都是由kubelet控制),这里不用挂载secret进去。
我们需要拉取私有仓库镜像 192.168.1.100:5000/test:v1,我们就需要针对该私有仓库来创建一个如上的 Secret,然后在 Pod 中指定 imagePullSecrets。当然你要改成拉取公有的镜像仓库也可以,公有的仓库不用secret。

除了设置 Pod.spec.imagePullSecrets 这种方式来获取私有镜像之外,我们还可以通过在 ServiceAccount 中设置 imagePullSecrets,然后就会自动为使用该 SA 的 Pod 注入 imagePullSecrets 信息:

apiVersion: v1
kind: ServiceAccount
metadata:creationTimestamp: "2019-11-08T12:00:04Z"name: defaultnamespace: defaultresourceVersion: "332"selfLink: /api/v1/namespaces/default/serviceaccounts/defaultuid: cc37a719-c4fe-4ebf-92da-e92c3e24d5d0
secrets:
- name: default-token-5tsh4
imagePullSecrets:
- name: myregistry

kubernetes.io/service-account-token

另外一种 Secret 类型就是 kubernetes.io/service-account-token,用于被 ServiceAccount 引用ServiceAccout 创建时 Kubernetes 会默认创建对应的 Secret。Pod 如果使用了 ServiceAccount,对应的 Secret 会自动挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中(每个ns创建时会默认创建一个ns的default的sa)

$ kubectl run secret-pod3 --image nginx:1.7.9
deployment.apps "secret-pod3" created
$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
...
secret-pod3-78c8c76db8-7zmqm   1/1       Running   0          13s
...
我们可以直接查看这个 Pod 的详细信息:volumeMounts:- mountPath: /var/run/secrets/kubernetes.io/serviceaccountname: default-token-5tsh4readOnly: true......serviceAccount: defaultserviceAccountName: defaultvolumes:- name: default-token-5tsh4secret:defaultMode: 420secretName: default-token-5tsh4
可以看到默认把名为 default(自动创建的)的 ServiceAccount 对应的 Secret 对象通过 Volume 挂载到了容器的 /var/run/secrets/kubernetes.io/serviceaccount 的目录中,对于该目录的作用我们会在后面的安全章节中继续和大家学习。

Secret vs ConfigMap
最后我们来对比下 Secret 和 ConfigMap这两种资源对象的异同点:

相同点
key/value的形式
属于某个特定的命名空间
可以导出到环境变量
可以通过目录/文件形式挂载
通过 volume 挂载的配置信息均可热更新

不同点
Secret 可以被 ServerAccount 关联
Secret 可以存储 docker register 的鉴权信息,用在 ImagePullSecret 参数中,用于拉取私有仓库的镜像
Secret 支持 Base64 加密
Secret 分为 kubernetes.io/service-account-token、kubernetes.io/dockerconfigjson、Opaque 三种类型,而 Configmap 不区分类型

使用注意

同样 Secret 文件大小限制为 1MB(ETCD 的要求);Secret 虽然采用 Base64
编码,但是我们还是可以很方便解码获取到原始信息,所以对于非常重要的数据还是需要慎重考虑,可以考虑使用 Vault 来进行加密管理。

base64其实不应该看成一种加密方式,应该当成编码方式来看待

ServiceAccount

ServiceAccount 主要是用于解决 Pod 在集群中的身份认证问题的。认证使用的授权信息其实就是利用前面我们讲到的一个类型为 kubernetes.io/service-account-token 进行管理的。

介绍
ServiceAccount 是命名空间级别的,每一个命名空间创建的时候就会自动创建一个名为 default 的 ServiceAccount 对象:

$ kubectl create ns kube-test
namespace/kube-test created
$ kubectl get sa -n kube-test
NAME      SECRETS   AGE
default   1         9s
$ kubectl get secret -n kube-test
NAME                  TYPE                                  DATA   AGE
default-token-vn4tr   kubernetes.io/service-account-token   3      2m27s

这个 ServiceAccount 会自动关联到一个 Secret 对象上:

$ kubectl get sa default -n kube-test  -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:creationTimestamp: "2019-11-23T04:19:47Z"name: defaultnamespace: kube-testresourceVersion: "4297522"selfLink: /api/v1/namespaces/kube-test/serviceaccounts/defaultuid: 75b3314b-e949-4f7b-9450-9bcd89c8c972
secrets:
- name: default-token-vn4tr

这个 Secret 对象是 ServiceAccount 控制器自动创建的,我们可以查看这个关联的 Secret 对象信息:

$ kubectl get secret default-token-vn4tr -n kube-test -o yaml
apiVersion: v1
data:ca.crt: LS0tLS...namespace: a3ViZS10ZXN0token: ZXlKaG...
kind: Secret
metadata:annotations:kubernetes.io/service-account.name: defaultkubernetes.io/service-account.uid: 75b3314b-e949-4f7b-9450-9bcd89c8c972creationTimestamp: "2019-11-23T04:19:47Z"name: default-token-vn4trnamespace: kube-testresourceVersion: "4297521"selfLink: /api/v1/namespaces/kube-test/secrets/default-token-vn4truid: e3e60f95-f255-471b-a6c0-600a3c0ee53a
type: kubernetes.io/service-account-token

在 data 区域我们可以看到有3个信息:

ca.crt:用于校验服务端的证书信息
namespace:表示当前管理的命名空间
token:用于 Pod 身份认证的 Token

前面我们也提到了默认情况下当前 namespace 下面的 Pod 会默认使用 default 这个 ServiceAccount,对应的 Secret(token,ca.crt,namespace) 会自动挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中,这样我们就可以在 Pod 里面获取到用于身份认证的信息了。

实现原理
实际上这个自动挂载过程是在 Pod 创建的时候通过 Admisson Controller(准入控制器) 来实现的

Admission Controller(准入控制)是 Kubernetes API Server 用于拦截请求的一种手段。Admission 可以做到对请求的资源对象进行校验,修改,Pod 创建时 Admission Controller 会根据指定的的 ServiceAccount(默认的 default)把对应的 Secret 挂载到容器中的固定目录下 /var/run/secrets/kubernetes.io/serviceaccount/。

然后当我们在 Pod 里面访问集群的时候,就可以默认利用挂载到 Pod 内部的 token 文件来认证 Pod 的身份,ca.crt 则用来校验服务端

代码中我们指定了 ServiceAccount 背后的 Secret 挂载到 Pod 里面的两个文件:token 和 ca.crt,然后通过环境变量获取到 APIServer 的访问地址(前面我们提到过会把 Service 信息通过环境变量的方式注入到 Pod 中,就是downward api的内容,kubernetes会将当前的命名空间的service的信息注入到pod中,这些信息也默认以变量的方式注入到容器中,而pod的某些信息不是自动注入到容器的而是需要手动注入),然后通过 ca.cart 校验服务端是否可信,最后服务端会根据我们提供的 token 文件对 Pod 进行认证。

Pod 身份被认证合法过后,具体具有哪些资源的访问权限,就需要通过后面的 RBAC 来进行声明了。所以我们在学习 Kubernetes 的权限认证的时候需要把整个流程弄清楚,ServiceAccount 是干嘛的?为什么还需要 RBAC?这些都是上下文关联的。

configmap,secret都是有namespace限制的

kubernetes配置管理:cm,sercret,sa相关推荐

  1. CMMI2.0之我见-配置管理CM

    编者按: CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域,笔者将通过系统性的梳理.浅显易懂的文字描述,同时结合笔者的思考和观点,对每个实践域的目标以及所基本涵盖 ...

  2. KCL 与其他 Kubernetes 配置管理工具的异同 - Kustomize 篇 [一个自研编程语言能做什么?(系列 2)]

    在系列上一篇文章 [用一个自己做的编程语言能做什么? (系列文章 1)] KCL - 让 Kubernetes 资源清单管理更容易 - 徐鹏飞Peefy的个人空间 - OSCHINA - 中文开源技术 ...

  3. Kubernetes—配置管理ConfigMap(十三)

    1 ConfigMap介绍 1.1 概述   在部署应用程序时,我们都会涉及到应用的配置,在容器中,如Docker容器中,如果将配置文件打入容器镜像,这种行为等同于写死配置,每次修改完配置,镜像就得重 ...

  4. CC00185.CloudKubernetes——|KuberNetes配置管理.V16|——|configmap.secret热更新.v02|configmap编辑方式|

    一.configmap编辑方式 ### --- 编辑configmap的形式:~~~ 方式一: edit:显示文件内容会很杂乱,不是很标准的显示内容,造成视觉的难理解.若是文件特别小的话,它会把文件内 ...

  5. Kubernetes 1.18学习笔记

    文章目录 一.Kubernetes 概述和架构 1.kubernetes 基本介绍 2.Kubernetes 功能 3.Kubernetes 架构组件 4.Kubernetes 核心概念 5.Kube ...

  6. k8s cm ( ConfigMap ) 学习

    介绍 ka get cmka describe ConfigMap ConfigMap 名称 或 ka describe cm cm名称ka edit cm cm名称 ConfigMap和Secret ...

  7. Kubernetes全套笔记

    Kubernetes学习资料 K8S概述及相关特征 概述 K8s是谷歌在2014年发布的容器化集群管理系统 使用k8s进行容器化应用部署 使用k8s利于应用扩展 k8s目标实施让部署容器化应用更加简洁 ...

  8. 检查集群状态命令_轻松管理Kubernetes集群的7个工具

    Kubernetes正在不断加快在云原生环境的应用,但如何以统一.安全的方式对运行于任何地方的Kubernetes集群进行管理面临着挑战,而有效的管理工具能够大大降低管理的难度. K9s k9s是基于 ...

  9. 使用Kubeadm搭建Kubernetes(1.12.2)集群

    Kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具,伴随Kubernetes每个版本的发布都会同步更新,在2018年将进入GA状态,说明离生产环境中使用的距离越来 ...

  10. 《深入理解 Spring Cloud 与微服务构建》第五章 Kubernetes

    <深入理解 Spring Cloud 与微服务构建>第五章 Kubernetes 文章目录 <深入理解 Spring Cloud 与微服务构建>第五章 Kubernetes 一 ...

最新文章

  1. Python 为什么用 # 号作注释符?
  2. 枚举与常量 java_java – 为什么两个枚举常量可以在同一行中使用?
  3. 泛化性乱弹:从随机噪声、梯度惩罚到虚拟对抗训练
  4. 使用字符缓冲流读取数据
  5. Docker的今生前世,关于Docker的一些见解
  6. HTML的SEO(搜索引擎优化)标准
  7. r语言调用python_python如何调用R
  8. linux ti 电池驱动_全球跨国车企电动汽车平台和电池系统对比
  9. c语言贪吃蛇源代码window32,Win32贪吃蛇源代码。背景非常简单
  10. Mysql多源复制半同步_MySQL多源复制搭建
  11. 数据库的主键Id不是从1开始的
  12. 超级安全!Python 合成多张图片到PDF格式
  13. centos刻录工具_CentOS7.0 U盘刻录工具正式版
  14. c mysql学生管理系统_C++ 简单的学生信息管理系统
  15. UNIX环境高级编程——第十章信号
  16. 萌新之php一句话木马(上传漏洞)
  17. 内存数据库将数据保存在计算机内存,内存数据库
  18. 哪里有免费的ASP空间?
  19. medusa--暴力破解
  20. Python open()方法中的newLine参数

热门文章

  1. java中wgs84转高德_2020-06-11关于WGS84 高德坐标 百度坐标的相互转换
  2. matlab做瀑布图,Matlab画瀑布图,福利叶变换,频谱图代码
  3. 【降维打击】解决加密视频录屏问题
  4. 太上老君的炼丹炉之分布式 Quorum NWR
  5. Ubuntu17.04系统安装必备软件与存在的问题
  6. “蓝凤凰”开网店,卖起了这么多高颜值又神奇的生物
  7. c语言srand函数作用,C语言之rand()和srand()函数
  8. Android反编译锁机文件
  9. python语句中print(type(1j))_Python语句 print(type(1J))的输出结果是:________
  10. 认知升级之第一性原理