云原生知识星球
0%

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题描述

我一直在创建类型为deploy的pod，但我看到一些文档使用的type是pod，更具体地说是多容器pod的文档：

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

但是要创建pod，我可以使用deployment类型：

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

我注意到pod文档说：

create命令可用于直接创建pod，也可以通过Deployment创建pod或pods。强烈建议您使用deployment来创建pod。它会监视失败的pod，并根据需要启动新的pod以维持指定的数量。如果您不希望deployment监视您的pod（例如，您的pod正在编写非持久性数据，或者您的pod的生命非常短暂），则可以直接创建一个pod。

注意：我们建议使用“deployment”来创建pods。

但是这引出了一个问题：kind类型为pod有什么好处？你能以某种方式参考deployment中的pod吗？我没有看到办法。看起来使用pod获得的是一些额外的元数据，但没有任何deployment选项，如副本或重启策略。没有持久数据的pod有什么用，可以在重启后保存下来？我想我也可以创建一个deployment的多容器pod。

高票回答

Pod和Deployment都是Kubernetes API中的完整对象。Deployment通过ReplicaSet管理创建Pod。它归结为Deployment将使用模板中的规范创建Pod。您不太可能需要直接为生产用例创建Pod。

原文链接

What is the difference between a pod and a deployment?

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题描述

我试图删除一个有12个pod的ReplicationController，但是发现一些pod卡在了Terminating状态。

我的Kubernetes集群安装在Ubuntu虚拟机上，包括一个master节点和三个worker节点。

这个问题可能是什么原因？

1
2
3
4
5
6
NAME        READY     STATUS        RESTARTS   AGE
pod-186o2   1/1       Terminating   0          2h
pod-4b6qc   1/1       Terminating   0          2h
pod-8xl86   1/1       Terminating   0          1h
pod-d6htc   1/1       Terminating   0          1h
pod-vlzov   1/1       Terminating   0          1h

高票回答

您可以使用以下命令强制删除POD。

1
kubectl delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>

原文链接

Pods stuck in Terminating status

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题描述

虽然分析了Docker，Google Cloud和Kubernetes，但还没有清楚地理解它们， 在我看来这些产品是重叠但不兼容的。

例如，需要重新编写docker-compose文件，以便可以将应用程序部署到Kubernetes。

有人可以从较高层次描述Docker，Docker-Compose，Docker Cloud和Kubernetes重叠的位置以及哪一个依赖于另一个吗？

高票回答

Docker :

Docker是一种容器技术，可以让您对应用程序进行容器化。Docker是使用其他技术的核心。

Docker Compose:

允许配置和启动多个docker容器。当你想要启动多个docker容器并且不想使用docker run分别启动每个Docker容器时，可以使用Docker compose启动。

Docker Swarm:

Docker swarm用于在多个主机上运行和连接容器。Docker swarm是一个容器集群管理和编排工具。它管理在多个主机上运行的容器，并执行缩放，在崩溃时启动新容器，网络容器……

Docker swarm是生产环境中的docker。它是嵌入在Docker引擎中的本机docker编排工具。名为stack file的docker swarm文件与docker compose文件非常相似。

Kubernetes:

由Google开发的容器编排工具。Kubernetes的目标与Docker swarm的目标非常相似。

Docker Cloud:

一种付费的企业级docker服务，允许您在云服务器或本地服务器上构建和运行容器。它提供了一个Web UI和一个中央控制面板来运行和管理容器，同时在用户友好的Web界面中提供所有docker功能。

Update:

Docker Clou“部分”功能停止使用

1
Docker Cloud上提供应用程序，节点和群集集群管理的服务将于5月21日关闭......自动构建和注册表存储服务将不会受到影响并将继续可用

原文链接

What’s the difference between docker compose and kubernetes?

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题描述

Apache的Mesos和Google的Kubernetes有什么区别？我知道两者都是服务器集群管理软件。有没有人可以详细说明主要区别在哪里？ - 什么时候会优先采用哪种框架？

高票回答

Kubernetes是一个开源项目，为虚拟机或“裸金属”场景带来“谷歌风格”的集群管理功能。它适用于现代操作系统环境（如CoreOS或Red Hat Atomic），可管理轻量级计算“节点”。它是用Golang编写的，具有轻量级，模块化，可移植性和可扩展性。我们（Kubernetes团队）正在与许多不同的技术公司（包括策划Mesos开源项目的Mesosphere）合作，将Kubernetes建立为与计算集群交互的标准方式。我们的想法是根据我们在Google的经验，重现我们看到人们需要构建群集应用程序的模式。其中一些概念包括：

  • pods - 将容器组合在一起的方法
  • replication controllers - 一种处理容器生命周期的方法
  • labels - 查找和查询容器的方法
  • services - 一组执行共同功能的容器。

因此，仅使用Kubernetes，您就会拥有一些简单，易于启动，可移植和可扩展的功能。在群集上运行应用程序，而无需担心单个计算机。在这种情况下，群集就像VM一样是一种灵活的资源。它是一个逻辑计算单元，可以快速轻松地开启，使用，调整大小，关闭。

使用Mesos，在基本视觉方面存在相当多的重叠，但产品在其生命周期中处于完全不同的点并且具有不同的优点。Mesos是一个分布式系统内核，它将许多不同的机器拼接成逻辑计算机。它诞生于一个拥有大量物理资源来创建大型静态计算集群的世界。最棒的是，许多现代可扩展的数据处理应用程序在Mesos（Hadoop，Kafka，Spark）上运行良好，这很好，因为您可以在同一个基本资源池上运行它们，以及新的容器打包应用程序。它比Kubernetes项目更重，但由于像Mesosphere这样的人的工作，它变得更容易和更容易管理。

现在真正有趣的是，Mesos目前正在适配添加大量Kubernetes概念并支持Kubernetes API。因此，它将成为获取Kubernetes应用程序更多功能的门户（高可用性主，更高级的调度语义，扩展到大量节点的能力），如果您需要它们，并且非常适合运行生产工作负载（Kubernetes仍处于alpha状态）。

当被问到时，我倾向于说：

  1. 如果您不熟悉集群的世界，Kubernetes是一个很好的起点；它是最快，最简单，最轻松的方式来启动并开始尝试面向集群的开发。它提供了非常高的可移植性，因为它得到了许多不同提供商（Microsoft，IBM，Red Hat，CoreOs，MesoSphere，VMWare等）的支持。
  2. 如果您有现有的工作负载（Hadoop，Spark，Kafka等），Mesos会为您提供一个框架，让您可以将这些工作负载相互交错，并混合使用包括Kubernetes应用程序在内的一些新工具。
  3. 如果您需要Kubernetes框架中社区尚未实现的功能，Mesos会为您提供一个类似方案。

原文链接

What’s the difference between Apache’s Mesos and Google’s Kubernetes

发表于 更新于 分类于 阅读时长 ≈ 2 分钟

用于将Microsoft Word .doc文档转换为任何其他支持格式（如.txt .rtf .pdf）的简单实用程序。

也可用于将.txt，.rtf转换为.doc或.pdf格式。

注：主机上必须安装Microsoft Word。

特点

  1. 将Doc / RTF / Text文件转换为任何Word SaveAs类型Doc / Text / RTF / PDF
  2. 单个文件转换
  3. 多个/目录文件转换
  4. 转换后删除
  5. 每次转换时可调用Webhook

举例

单个文件转换

将Microsoft Word文档转换为文本

1
docto -f C:\Directory\MyFile.doc -O "C:\Output Directory\MyTextFile.txt" -T wdFormatText

将Microsoft Word文档转换为PDF（需要支持此功能的Microsoft Word版本）

1
docto -f C:\Directory\MyFile.doc -O "C:\Output Directory\MyTextFile.pdf" -T wdFormatPDF

多文件和文件夹转换

将目录及其子目录中的所有Microsoft Word文档转换为PDF

1
docto -f "C:\Dir with Spaces\FilesToConvert\" -O "C:\DirToOutput" -T wdFormatPDF  -OX .pdf

转换后删除原始文件（-R）

1
docto -f "C:\Dir with Spaces\FilesToConvert\" -O "C:\DirToOutput" -T wdFormatPDF  -OX .pdf -R

Webhooks

添加Webhook以在每次转换时触发（-W）

1
docto -f "C:\Dir with Spaces\FilesToConvert\" -O "C:\DirToOutput" -T wdFormatPDF  -OX .pdf  -W http://toflidium.com/webhooks/docto/webhook_test.php

Webhook是一个可以在每次转换时调用的URL，使您能够在转换文件时从外部响应。

命令行支持参数列表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
参数标记不区分大小写。大小写可以混合使用。
  -H  查看各参数使用方法
      --help -?
  -F  输入文件或目录
      --inputfile
  -FX 如果输入为目录，指定源文档的扩展名。默认“.doc”（包括“.docx”）
      --inputextension
  -O  输出文件或目录以存放转换后的文档
      --outputfile
  -OX 如果-F为目录，指定转换后的文档扩展名。请包含'.'，如'.pdf'
      --outputextension
  -T  格式（类型），可以使用数字或wdSaveFormat常量表示，参考：http://msdn.microsoft.com/en-us/library/microsoft.office.interop.word.wdsaveformat.aspx
      --format
  -TF 强制转换格式
      --forceformat
  -L  日志级别，1 ERRORS, 2 STANDARD, 5 CHATTY, 10 VERBOSE，默认值为2
      --loglevel
  -C  兼容模式整数值，参考：https://msdn.microsoft.com/en-us/library/office/ff192388.aspx
      --compatability
  -M  忽略__MACOSX\目录下的所有文件，默认为True
      --ignoremacos
  -G  写日志文件到指定目录
      --writelogfile
  -GL 日志文件名称，默认为'DocTo.Log'
      --logfilename
  -Q  以安静模式输出日志
      --quiet
  -R  转换成功后移除源文件，默认为false
      --deletefiles
  -W  Webhook钩子，通过URL调用响应事件
  -HW Webhook帮助
  -X  暂停COM错误：默认为True。如果您在某些文件未转换时遇到问题，请将此设置为false以忽略错误并继续批处理作业
      --halterror
  -V  版本号

错误码:
200 : 指定的文件格式无效
201 : 输入参数不足。如输入文件，输出文件和类型为必选参数
202 : 转换错误
203 : 未知的转换命令
220 : Word或COM错误
221 : Word未安装

兼容模式：
wdCurrent   : 65535 等效于最新版本的Microsoft Word
wdWord2003  : 11    Word 2010将设置为与Word 2003最兼容的模式。在此模式下禁用Word 2010新增功能
wdWord2007  : 12    Word 2010将设置为与Word 2007最兼容的模式。在此模式下禁用Word 2010新增功能
wdWord2010  : 14    Word 2013将设置为与Word 2010最兼容的模式。在此模式下禁用Word 2013新增功能 
wdWord2013  : 15    默认值。支持所有Word 2013功能

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题描述

我在文档中理解的是kubectl apply = kubectl create + kubectl replace。参考

我的理解是，如果我想在集群中创建新的k8s资源，我应该使用kubectl create操作。现在，如果我想更新现场k8s资源中的内容，我应该使用kubectl replace操作。

如果我想做两个操作（创建一个新的k8s资源以及更新实时k8s资源）然后我应该使用kubectl replace操作。

我的问题是为什么在集群中执行相同任务有三个操作？这些操作的使用场景是什么？他们的区别是什么？

目前我正在使用kubectl create操作在集群中创建新资源。谢谢

高票回答

这是两种不同的方法。kubectl create就是我们所说的Imperative Management（命令式管理）。在这种方法中，您可以告诉Kubernetes API您要创建，替换或删除的内容，而不是您希望K8s群集是什么样的。

kubectl apply是Declarative Management （声明式管理）的一部分，即使您对对象应用其他更改，也可以保留应用于活动对象（即通过比例）的更改。

您可以在Kubernetes Object Management中阅读有关命令式和声明式管理的更多信息。

原文链接

kubectl apply vs kubectl create?

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题描述

我有几个Docker镜像，我想用minikube。我不想使用先上传然后下载镜像的方式，而是想直接使用本地镜像。我该怎么做呢？

我试过的方法：

  1. 我尝试运行这些命令（分别删除minikube的实例并重新开始）

    1
    2
    kubectl run hdfs --image=fluxcapacitor/hdfs:latest --port=8989
    kubectl run hdfs --image=fluxcapacitor/hdfs:latest --port=8989 imagePullPolicy=Never

    输出：

    1
    2
    NAME                    READY     STATUS              RESTARTS   AGE
    hdfs-2425930030-q0sdl   0/1       ContainerCreating   0          10m

    它只是陷入某种状态但从未达到就绪状态。

  2. 我尝试创建一个registry，然后将镜像放入其中，但这也无效。我可能做错了但我找不到正确的指令来完成这项任务。

请提供在本地kubernetes实例中使用本地docker镜像的说明。

操作系统：ubuntu 16.04

Docker：Docker版本1.13.1，build 092cba3

Kubernetes：

1
2
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.3", GitCommit:"029c3a408176b55c30846f0faedf56aae5992e9b", GitTreeState:"clean", BuildDate:"2017-02-15T06:40:50Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}

如果有人可以帮助我找到一个使用docker-compose来做这个的解决方案，那就太棒了。谢谢。

高票回答

正如README描述的那样，您可以使用eval $（minikube docker-env）重用Minikube中的Docker守护进程。

因此，要使用本地镜像而不先上传镜像，您可以按照以下步骤操作：

  1. 用eval $（minikube docker-env）设置环境变量
  2. 使用Minikube的Docker守护程序构建镜像（例如docker build -t my-image）
  3. 在pod规范中设置镜像，如构建tag（例如my-image）
  4. 将imagePullPolicy设置为Never，否则Kubernetes将尝试下载镜像

重要说明：您必须在要使用的每个终端上运行eval $（minikube docker-env），因为它只为当前shell会话设置环境变量。

原文链接

How to use local docker images with Minikube?

发表于 更新于 分类于 阅读时长 ≈ 2 分钟

Kubernetes集群证书的使用寿命为一年。如果Kubernetes集群证书在Kubernetes master节点上过期，则kubelet服务将失败。使用kubectl命令，例如kubectel get pod或kubectl exec -it container_name bash，将导致类似的消息：

1
Unable to connect to the server: x509: certificate has expired or is not yet valid

处理方法：重新生成新证书并更新worker节点。

注意：

  1. 执行以下操作前，请先备份相关文件
  2. 请勿替换CA证书，原因可参考issue（个人验证发现，是因为kubelet证书未删除导致，删除后重启kubelet问题解决）

  1. 在/root目录下创建一个配置文件kubeadm.yaml，其中advertiseAddress设置为Kubernetes主节点的IP地址（或集群虚IP）。例如：

    1
    2
    3
    4
    5
    apiVersion: kubeadm.k8s.io/v1alpha1
    kind: MasterConfiguration
    api:
      advertiseAddress: 10.165.80.110
    kubernetesVersion: v1.10.11

  2. 删除现有证书和密钥文件：

    1
    2
    3
    4
    5
    6
    rm -rf /etc/kubernetes/pki/apiserver.key
    rm -rf /etc/kubernetes/pki/apiserver.crt
    rm -rf /etc/kubernetes/pki/apiserver-kubelet-client.crt
    rm -rf /etc/kubernetes/pki/apiserver-kubelet-client.key
    rm -rf /etc/kubernetes/pki/front-proxy-client.crt
    rm -rf /etc/kubernetes/pki/front-proxy-client.key

  3. 创建新证书：

    1
    2
    3
    kubeadm --config /root/kubeadm.yaml alpha phase certs apiserver
    kubeadm --config /root/kubeadm.yaml alpha phase certs apiserver-kubelet-client
    kubeadm --config /root/kubeadm.yaml alpha phase certs front-proxy-client

  4. 删除旧的配置文件：

    1
    2
    3
    4
    5
    rm -rf /etc/kubernetes/admin.conf
    rm -rf /etc/kubernetes/kubelet.conf
    rm -rf /etc/kubernetes/controller-manager.conf
    rm -rf /etc/kubernetes/scheduler.conf 
    rm -rf /var/lib/kubelet/pki/kubelet*

  5. 生成新配置文件：

    1
    kubeadm --config /root/kubeadm.yaml alpha phase kubeconfig all

  6. 确保你的 kubectl 服务正在使用正确的配置文件（根据实际环境配置该环境变量）：

    1
    2
    cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    export KUBECONFIG=.kube/config

  7. 重启Kubernetes主节点。

  8. 服务器重新启动后，检查以确保kubelet服务正在运行：

    1
    systemctl status kubelet

  9. 要重新加入工作节点，您需要一个集群令牌。

    对于Kubernetes 1.7，预设了集群令牌。对于Kubernetes1.7之后的版本，您必须创建新令牌，因为在安装时生成的令牌具有有限的生命周期：

    1
    kubeadm token create

  10. SSH进入每个worker节点并将它们重新连接到Kubernetes主节点。

  11. 将工作节点加入Kubernetes集群：

    1
    kubeadm join --token=cluster_token master_ip:6443

    其中：

    • cluster_token：在步骤9中创建的令牌
    • master_ip：Kubernetes主节点的IP地址（或集群虚IP地址）

    注意：
    某些版本的kubeadm使用–print-join-command命令行参数。在这些情况下， kubeadm输出重新连接Kubernetes master所需的kubeadm join命令。如果发生这种情况，请在每个工作节点上输入此命令（复制和粘贴）。

  12. 确认kubelet服务正在运行，并且worker节点和Kubernetes master之间正常通信。

  13. 等几分钟。然后从Kubernetes主节点运行以下命令以确认worker节点是否可用：

    1
    kubectl get nodes

发表于 更新于 分类于 阅读时长 ≈ 3 分钟

FEATURE STATE: Kubernetes v1.15 stable

kubeadm生成的客户端证书将在1年后过期。本页介绍如何使用kubeadm管理证书续订。

开始之前

熟悉Kubernetes中的PKI证书和要求以及证书最佳实践。

检查证书过期时间

check-expiration命令可用于检查证书过期时间。

1
kubeadm alpha certs check-expiration

输出类似于：

1
2
3
4
5
6
7
8
9
10
11
CERTIFICATE                EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
admin.conf                 May 15, 2020 13:03 UTC   364d            false
apiserver                  May 15, 2020 13:00 UTC   364d            false
apiserver-etcd-client      May 15, 2020 13:00 UTC   364d            false
apiserver-kubelet-client   May 15, 2020 13:00 UTC   364d            false
controller-manager.conf    May 15, 2020 13:03 UTC   364d            false
etcd-healthcheck-client    May 15, 2020 13:00 UTC   364d            false
etcd-peer                  May 15, 2020 13:00 UTC   364d            false
etcd-server                May 15, 2020 13:00 UTC   364d            false
front-proxy-client         May 15, 2020 13:00 UTC   364d            false
scheduler.conf             May 15, 2020 13:03 UTC   364d            false

该命令显示/etc/kubernetes/pki文件夹中的客户端证书的到期/剩余时间，以及kubeadm（admin.conf，controller-manager.conf和scheduler.conf）使用的KUBECONFIG文件中嵌入的客户端证书。

此外，如果证书是外部管理的，kubeadm会通知用户；在这种情况下，用户应该手动/使用其他工具来管理证书续订。

警告：kubeadm无法管理外部CA签名的证书。

注意：kubelet.conf不包含在上面的列表中，因为kubeadm配置kubelet以进行自动证书续订。

自动续订证书

kubeadm在控制平面升级期间更新所有证书。

此功能旨在解决最简单的使用案例；如果您没有对证书续订的具体要求并定期执行Kubernetes版本升级（每次升级之间不到1年），kubeadm将负责保持您的群集最新并且合理安全。

注意：最佳做法是频繁升级群集以保证安全。

如果您对证书续订有更复杂的要求，可以通过将–certificate-renewal = false传递给kubeadm upgrade apply或kubeadm upgrade node来退出默认行为。

手动续订证书

您可以使用kubeadm alpha certs renew命令随时手动续订证书。

此命令使用CA（或front-proxy-CA）证书和存储在/etc/kubernetes/pki中的密钥执行续订。

警告：如果您正在运行HA群集，则需要在所有控制平面节点上执行此命令。

注意：alpha certs renew使用现有证书作为属性（公用名，组织，SAN等）的权威来源，而不是kubeadm-config ConfigMap。强烈建议让它们保持同步。

kubeadm alpha certs renew提供以下选项：

  • –csr-only可用于通过生成证书签名请求（不实际更新证书）来与外部CA续订证书；有关更多信息，请参阅下一节
  • 也可以更新单个证书而不是全部证书

使用Kubernetes证书API续订证书

本节提供有关如何使用Kubernetes证书API执行手动证书续订的更多详细信息。

警告：这些高级主题是针对需要将其组织的证书集成到kubeadm构建的群集中的用户。如果默认的kubeadm配置满足您的需求，您应该让kubeadm管理证书。

设置签名

Kubernetes证书颁发机构非开箱即用。您可以配置外部签名，例如cert-manager，也可以使用内置签名。内置签名功能是kube-controller-manager的一部分。要激活内置签名功能，请向kube-controller-manager传递–cluster-signing-cert-file和–cluster-signing-key-file参数。

要激活内置签名功能，必须传递–cluster-signing-cert-file和–cluster-signing-key-file标志。

如果要创建新群集，可以使用kubeadm配置文件：

1
2
3
4
5
6
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controllerManager:
  extraArgs:
    cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
    cluster-signing-key-file: /etc/kubernetes/pki/ca.key

创建证书签名请求（CSR）

您可以使用kubeadm alpha certs renew –use-api为Kubernetes证书API创建证书签名请求。

如果设置[cert-manager] [cert-manager]等外部签名，则会自动创建证书签名请求（CSR）。否则，您必须使用kubectl certificate命令手动创建证书。以下kubeadm命令输出要创建证书的名称，然后阻塞并等待创建完成：

1
sudo kubeadm alpha certs renew apiserver --use-api &

输出类似于：

1
2
[1] 2890
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created

签发证书签名请求（CSR）

如果设置了外部签名，则会自动签发证书签名请求（CSR）。

否则，您必须使用kubectl certificate命令手动签发证书。例如：

1
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526

输出类似于：

1
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved

您可以使用kubectl get csr查看待处理证书的列表。

使用外部CA续订证书

本节提供有关如何使用外部CA执行手动证书续订的更多详细信息。

为了更好地与外部CA集成，kubeadm还可以生成证书签名请求（CSR）。CSR表示向CA请求客户端的签名证书。在kubeadm术语中，通常由on-disk CA签名的任何证书都可以作为CSR。但是，CA不能作为CSR。

创建证书签名请求（CSR）

您可以使用–csr-dir传入目录，以将CSR输出到指定位置。如果未指定–csr-dir，则使用默认证书目录（/etc/kubernetes/pki）。CSR和附带的私钥都会输出。

CSR表示向CA请求客户端的签名证书。您可以使用kubeadm alpha certs renew –csr-only创建证书签名请求。

CSR包含证书的名称，域和IP，但不指定用法。CA颁发证书时，有责任指定正确的证书用法。

证书签名后，必须将证书和私钥复制到PKI目录（默认情况下为/etc kubernetes/pki）。