0%

问题描述

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

用于将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功能

问题描述

我在文档中理解的是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?

问题描述

我有几个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?

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

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)。