不久前,我使用kube建立了一个kubernetes集群(我想,我还不完全确定,因为它确实是在一段时间前),最近我使用coreOS及其工具建立了另一个kubernetes集群。它们都生成kubeconfig文件,并且这些文件分别为它们各自完美地工作。虽然,有一些不同之处,这也是为什么这篇文章。我想要正确地理解这些差异。这是两个文件-
1.> 1更早生成(最有可能使用kube)
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: CERTIFICATE_AUTH_DATA
server: https://our.kube.server.1
name: aws_kubernetes
contexts:
- context:
cluster: aws_kubernetes
user: aws_kubernetes
name: aws_kubernetes
current-context: aws_kubernetes
kind: Config
preferences: {}
users:
- name: aws_kubernetes
user:
client-certificate-data: SECRET_CERTIFICATE
client-key-data: SECRET_CLIENT_KEY
token: SECRET_TOKEN
- name: aws_kubernetes-basic-auth
user:
password: PASSWORD
username: USERNAME2.>第二次使用coreOS工具生成
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority: path/to/ca.pem
server: https://our.kube-server.2
name: kube-aws-cluster-cluster
contexts:
- context:
cluster: kube-aws-cluster-cluster
namespace: default
user: kube-aws-
cluster-admin
name: kube-aws-cluster-context
users:
- name: kube-aws-cluster-admin
user:
client-certificate: path/to/admin.pem
client-key: path/to/admin-key.pem
current-context: kube-aws-cluster-context正如您所看到的,在这两个版本之间,键的名称和它们的值是不同的;例如- certificate-authority-data vs certificate-authority,其中一个是字符串,另一个是.pem文件的相对路径。
我在想-
1.>是可互换的密钥的名称,可以是证书颁发机构,也可以是证书颁发机构,反之亦然。
2.>是预先定义的值类型吗?我的意思是,如果我复制.pem文件的内容并将其粘贴到例如证书颁发机构,kubectl能够授权吗?
如果我能想到这一点,那就太好了。如果我的问题有任何混乱之处,我很抱歉。如果是这样的话,请问我,我会尽量说清楚。
提前感谢
我做了一些实验,我知道它们是不可互换的。我现在有个不同的问题。更直接的是-
在这两个文件中,哪一个是kubeconfig文件的standard或latest版本?
发布于 2016-11-22 16:36:52
*-data字段内联引用文件的内容,base64 64编码。这允许kubeconfig文件是独立的,并且能够被移动/复制/分发,而无需在磁盘上携带引用的文件。这两种格式都是有效的,这取决于您的用例。
https://stackoverflow.com/questions/40742574
复制相似问题