你可以将本文作为开发者极速了解Kubees的指南。从基础常识到更初级的主题，如HelmChart，以及一切这些如何影响你作为开发者。

译自KubernetesforLazyDevelopers。作者marcobehler。

引见

假设你是一位开发者，要么从未经常使用过Kubernetes，要么想要温习Kubernetes常识，以便让你的DevOps共事对你另眼相看，那么这份指南适宜你。

极速疑问：为什么将Kubernetes缩写为K8s？

答案：它将在本指南末尾神奇地提醒，但仅在你齐全浏览完之后。所以，让咱们不再糜费时期。

咱们是如何抵达这里的？

我在整个职业生涯中遇到的许多开发者，关于他们运行程序生命周期的如今我曾经编写了代码，它还须要在某个中央运转的局部并不必定关心。（依据你的公司对DevOps这个词的定义和认知水平，这或许有所不同）。

但让咱们缓缓开局。运转一个运行程序实践上象征着什么？

这在必定水平上取决于你所经常使用的编程言语生态系统。例如，在和现代Web运行程序方面，你可以将一切源代码编译成一个繁多的可执行.jar文件，而后经过便捷的命令运转它。

java-jarmyNewStartup.jar

关于消费部署，通常你也会宿愿有一些属性，用于设置数据库凭据或其余秘密。在上述的JavaSpringBoot状况下，最便捷的方式是领有一个lication.properties文件，但你也可以经常使用外部的秘密治理服务。

无论如何，上述的命令实践上是你须要运转的一切内容，用于部署你的运行程序-无论你是在裸金属上、虚构机上、容器中、有或没有Kubernetes，甚至是你的Java驱动的烤面包机。

仅运转一个命令必需不够。哪里是疑问的瓶颈？

关于部署运行程序时或许出现的疑问曾经在网络上写了很多：

关于这些疑问，依据你经常使用的编程言语生态系统，处置方法或许会有很大的不同-这是在线讨论中经常被漠视的一个主题。

关于纯正的JavaWeb运行程序，上述提到的疑问（不包括潜水艇或更理智的基础设备局部，比如你的数据库），在很大水平上并不是疑问。你在主机/虚构机/容器/潜水艇上装置JDK，运转java-jar，而后幸福地生存在一同。

关于、/target=_blankclass=infotextkey>Python、咳咳，Node，状况就不同了，你很容易在开发、测试或消费环境之间遇到版本不兼容的疑问。因此，人们盼望一种处置方案来解脱这些烦恼：容器。

Docker、DockerCompose和Swarm：回忆

向Docker致敬！

很有或许你曾经知道Docker是什么，以及如何经常使用它。（假设不知道，并且想看一个特定于Docker的指南，请在上方评论！需求越多→颁布越快）。冗长的总结是：

→你不再部署你的.jar文件，而是部署你的Docker镜像并运转Docker容器。

这样做的美妙之处在于：只需在指标机器上装置了Docker（并且你的主机操作系统与Docker容器兼容内核），你就可以运转任何Docker镜像。

dockerrun--namemy-new-ai-startup-p80:8080-dmynewaistartup//yay,yourapplicationisdeployed//ThiswillstartaDockercontainerbasedonthe`_mynewaistartup_`Dockerimage.//Thatimagewill,thatotherthings,containyoure.g.-jarfile,//awebapplicationwhichrunsonport8080,aswellasinstructionsonhowtorunit.//Hint:Theseinstructionsare`_java-jarmynewaistartup.jar_`.

什么是'deploying'Docker镜像？

你或许你的CI/CD主机设法将你的运行程序制形成了一个Docker镜像。但是这个Docker镜像最终是如何在指标部署主机上运转的呢？

你通常上可以将Docker镜像保留为.tar文件，复制到最终主机上并在那里加载它。但更理想的状况是，你会将Docker镜像推送到一个DockerRegistry，无论是dockerhub、AmazonECR还是其余像GitLab的不可胜数的自托管容器Registry之一。

一旦你的镜像成功上行到Registry，你可以在指标主机上登录到该注册表。

dockerloginmysupersecret.registry.com

一旦你在Registry上登录成功，你的dockerrun就能找到你的自定义镜像了。

dockerrun--namemy-new-ai-startup-p80:8080-dmynewaistartup//....SUCCESS!

DockerCompose：同时运转多个容器

假设你的运行程序不只仅蕴含一个独自的Docker容器，比如说，由于你须要运转98354个微服务？

DockerCompose来挽救。你将在一个传统而又经典的YAML文件，即compose.yaml文件中定义一切服务及其之间的依赖相关（运转这个或那个先）。以下是一个定义两个服务的示例，一个是Web服务，另一个是服务。

services:web:build:.ports:-"8000:5000"volumes:-.:/code-logvolume01:/var/logdepends_on:-redisredis:image:redisvolumes:logvolume01:{}

而后只需运转dockercomposeup，整个环境（由一切独立服务在独自的Docker容器中运转组成）将被启动。请留意，这象征着一切容器将在同一台机器上运转。假设要将其裁减到多台机器上，您将须要经常使用DockerSwarm。

虽然DockerCompose或许关键用于极速启动开发或测试环境，但它实践上也实用于（单主机）消费部署。假设你的运行程序…

…经常使用DockerCompose启动消费部署将大有裨益。

Kubernetes101:基础和概念

那么我为什么须要Kubernetes呢？

当你想要开局运转数百、数千（或是它们的倍数）的容器时，事情变得幽默起来。假设你不关心或许不想知道这些容器将在哪台详细的配件/主机上运转，但依然宿愿能够正当地治理一切这些，那么Kubernetes就派上用场了！

（注：相当长时期以前，我读过一本关于Kubernetes的书，在引见中他们规则了运转Kubernetes开局变得无心义的下限数字，我记得它从数百到数千开局，虽然我无法找到那本确切的书了。）

让咱们极速了解一下Kubernetes的基础概念。

图片

（上班，Worker）节点

你的软件（或许在Kubernetes术语中称为上班负载）必需在某个中央运转，无论是虚构机还是物理机器。在Kubernetes中，这个中央被称为节点（Node）。

此外，Kubernetes部署和运转容器：你好，Docker，我的老好友！（注：Kubernetes支持许多容器运转时，包括containerd、CRI-O、DockerEngine等，虽然Docker是最罕用的）

实践上，这并不齐全正确。在Kubernetes的术语中，你部署（调度）Pods，一个Pod蕴含一个或多个容器。

好吧，咱们在节点上运转Pods，但是谁控制这些节点，以及你在这些节点上如何选择运转什么呢？

（小贴士：一个小映射表）

控制平面

意识控制平面。为便捷起见，咱们可以将其视为控制节点的一个组件（与其蕴含的大概9472个组件相对）。控制平面，除了其余许多性能…

Pods与Nodes

假设Pods和Nodes之间的区别还有点不分明。Kubernetes有一个所谓的调度器。每当调度器发现新的Pod（==容器（们））须要调度时（耶！），它会尝试找到Pod的最佳节点。这象征着很有或许多个Pod在同一节点上运转，或许在不同节点上运转。假设你想深化了解这个主题，你或许须要浏览有关"节点选用"以及如何影响它的官网文档。

集群&云

取多个节点和你的控制平面，你就有了一个集群。

取多个集群，你可以分隔你的开发、测试和消费环境，或许团队、名目或不同类型的运行程序-这取决于你。

再进一步，尝试启动多云Kubernetes，超越不同的私有和/或私有云平台运转多个集群（祝贺！你所取得的成就绝非易事。）

裁减

还有许多Kubernetes裁减。

最关键的是，关于开发人员来说，有一个WebUI/Dashboard，你可以经常使用它来基本治理你的集群。

假设你没有自托管你的Kubernetes设置，你可以便捷地经常使用云供应商提供的任何UI，比如Cloud、AWS或其余泛滥云供应商提供的UI。

请，让咱们中止Kubernetes101

上方的那四个101局部将（宿愿）为你提供足够的心智模型，让你开局经常使用Kubernetes，咱们将在概念上完结。

说瞎话，假设你在上搜查"Kubernetes"，你会感到震惊。你将取得不可胜数的学习资源结果，其中许多书籍都超越500页长。这关于一个下雨天的冬天是很好的浏览！好信息是：作为开发人员，你不用关心这些书中大少数内容，这些书教你如何设置、保养和治理你的集群，虽然了解一切这些的复杂性是有协助的。

我须要做什么才干看到一切这些在运转中的状况？

我从哪里失掉kubectl？

你可以下载kubectl，这实质上是用于与你的Kubernetes集群做任何你想做的事情的CLI工具。该页面列出了为你的特定操作系统装置kubectl的各种方法。

我如何读kubectl？†

参见。它的发音是"KubeControl"。

kubectl要如何上班？

你须要一特性能文件，一个名为kubeconfig的文件，它准许你访问你的Kubernetes集群。

自动状况下，该文件位于~/.kube/config。值得留意的是，这特性能文件也被你喜欢的集成开发环境（如IntelliJIDEA）读取，以正确设置其Kubernetes性能。

我从哪里失掉kubeconfig文件？

选项1假设你正在经常使用托管的Kubernetes装置（EKS、GKE、AKS），请检查相应的文档页面。是的，只需点击链接，我曾经为你链接到正确的页面。简而言之，你将经常使用它们的CLI工具为你生成/下载该文件。

选项2假设你本地装置了Minikube，它将智能为你创立一个kubeconfig文件。

选项3假设你碰巧知道你的Kubernetes主节点并可以经过SSH登录，运转：cat/etc/kubernetes/admin.conf或cat~/.kube/config

kubeconfig文件还有其余须要知道的吗？

一个kubeconfig文件由传统的YAML组成，它可以蕴含许多内容（clusters、users、contexts）。关于有兴味的人，请查阅官网文档。

目前，咱们可以疏忽users和contexts，并且简化为kubeconfig文件蕴含你可以衔接的集群，例如development或test。

以下是一个示例kubeconfig文件，摘自官网Kubernetes文档。

（别担忧，你不用逐行了解这个文件，它只是为了让你感触一下这些文件的样子）

apiVersion:v1clusters:-cluster:certificate-authority:fake-ca-fileserver:""kind:Configpreferences:{}users:-name:developeruser:client-certificate:fake-cert-fileclient-key:fake-key-file-name:experimenteruser:#Documentationnote(thiscommentisNOTpartofthecommandoutput).#StoringpasssinKubernetesclientconfigisrisky.#Abetteralternativewouldbetouseacredentialplugin#andstorethecredentialsseparately.#See

 Kubectl101


 你如今可以用Kubectl做什么呢？记住，一开局咱们说你的指标是领有一个Pod（n+个容器），并在节点（主机）上调度它（运转它们）。


 方法是将yaml文件（耶）带有集群希冀形态的文件输入到kubectl中，它将欢快地将你的集群设置为希冀的形态。


 Pod清单


 例如，你可以创立一个名为marcocodes-pod.yaml的文件，内容如下…

apiVersion:v1kind:Podmetadata:name:marcocodes-webspec:containers:-image:gcr.io/marco/marcocodes:1.4name:marcocodes-webports:-containerPort:8080name:httpprotocol:TCP

 …并经常使用以下kubectl命令将其输入到你的Kubernetes集群中：

kubectlapply-fmarcocodes-pod.yaml

 运行这个yaml文件会做什么呢？嗯，让咱们逐渐了解：


 Kubernetes知道各种所谓的对象，Pod是其中之一，你稍后会遇到其余对象。便捷来说，这个.yaml文件形容了咱们要部署的Pod。

metadata:name:marcocodes-web

 Kubernetes中的每个对象，因此每个.yaml文件都充溢了metadata标签。在这种状况下，咱们为咱们的pod指定了称号，值为marcocodes_web。这个metadata有什么用呢？便捷来说，Kubernetes须要以某种方式惟一标识集群中的资源：我能否曾经运转了一个称号为marcocodes_web的pod，还是我须要启动一个新的pod？这就是metadata的作用。

spec:containers:-image:gcr.io/marco/marcocodes:1.4name:marcocodes-webports:-containerPort:8080name:httpprotocol:TCP

 你须要通知Kubernetes你的pod应该是什么样的。记住，它可以是n+个容器，因此你可以在YAML文件中指定容器的列表，虽然通常你只指定一个。


 你将指定一个特定的Docker镜像，包括其版本，并经过http在该容器上泄露端口8080。就是这样。


 这个yaml文件究竟出现了什么？


 长话短说，当你运转kubectlapply时，你的yaml文件将被提交到KubernetesAPI主机，最终咱们的Kubernetes系统将布置一个pod（带有marcocodes1.4容器）在咱们集群中的一台肥壮、可行的节点上运转。


 更技术性地说，Kubernetes有一个协调循环的概念，一个调度器能够说的花哨点的术语：


 "这是我的以后Kubernetes集群形态，这是用户的yaml文件，让我协调这两者。用户想要一个新的pod吗？我会创立它。用户想要存储吗？我会将其附加到容器上，等等。


 说到存储...


 资源和卷


 仅指定容器镜像并不是你所能做的所有。首先，你或许想要处置容器的资源消耗：

#....spec:containers:-image:gcr.io/marco/marcocodes:1.4resources:requests:cpu:"500m"memory:"128Mi"#....

 这确保你的容器至少取得500m（即0.5）的CPU和128MB的内存（你还可以指定永远无法打破的下限）。


 此外，当一个pod被删除或容重视新启动时，容器文件系统中的数据也将被删除。为了防止这种状况，你或许想要将数据存储在耐久卷上。

#....spec:volumes:-name:"marcocodes-data"hostPath:path:"/var/lib/marcocodes"containers:-image:gcr.io/marco/marcocodes:1.4name:marcocodesvolumeMounts:-mountPath:"/data"name:"marcocodes-data"ports:-containerPort:8080name:httpprotocol:TCP#....

 咱们将领有一个名为marcocodes-data的卷，它将被挂载到容器上的/data目录下，并存在于主机机器上的/var/lib/marcocodes下。


 有什么要留意的吗？


 你刚学到有pod，它们由一个或多个Docker镜像组成，以及资源消耗规则和卷定义。


 有了一切这些YAML，咱们成功地布置了一个繁多的、静态的、一次性性的pod。疑问来了：与仅运转dockerrun-d--publish8080:8080gcr.io/marco/marcocodes:1.4相比，有何长处？


 嗯，实践上目前并没有。


 这就是为什么咱们须要更深化地了解ReplicaSet和Deployment概念的要素。


 ReplicaSet


 咱们要谦卑一点。一开局咱们不须要智能缩放，但领有运行程序的冗余实例和一些负载平衡会很不错，这样咱们的部署会显得更专业，不是吗？


 Kubernetes的ReplicaSet来挽救咱们！


 让咱们看一个定义了这样一个最小ReplicaSet的marcocodes-replica.yaml文件。

apiVersion:apps/v1kind:ReplicaSet#metadata:#...spec:replicas:2selector:"youwilllearnthislater"#...template:metadata:"youwilllearnthislater"#...spec:containers:-name:marcocodes-webimage:"gcr.io/marco/marcocodes:3.85"

 我省略了这个YAML文件中的很多行（和复杂性），但如今最幽默的是这两个变动：


 这个.yaml如今形容的是一个ReplicaSet，而不再是一个Pod。


 这是重点：咱们宿愿一直有2个正本==pod在任何给定的时期运转。假设咱们在这里填入10，Kubernetes将确保同时运转10个pod。


 当咱们如今运行这个.yaml文件...

kubectlapply-fmarcocodes-rs.yaml

 Kubernetes将从KubernetesAPI失掉一个Pod清单（并依据metadata过滤结果），依据前往的pod数量，Kubernetes将启动或中止额外的正本。就是这么便捷。


 ReplicaSet：总结


 ReplicaSet简直是你想要的，但它们存在一个疑问：它们与特定版本的容器镜像绑定（在咱们的例子中为3.85），而这些实践上不应该更改。而且ReplicaSets也不能协助你成功软件的滚动颁布环节（思考零停机时期）。


 因此，咱们须要一个新的概念来协助咱们治理新版本的颁布。见识一下：Deployment（部署）。

apiVersion:apps/v1kind:Deploymentmetadata:"ignorefornow"#...spec:progressDeadlineSeconds:600replicas:2revisionHistoryLimit:10selector:"ignorefornow"#...strategy:rollingUpdate:maxSurge:25%maxUnavailable:25%type:RollingUpdatetemplate:"ignorefornow"#...

 你还须要学习Deployments的其余92387个YAML键值对，而咱们曾经在本文中启动了相当长时期的讨论。其要点是：Kubernetes准许你经常使用不同的软件颁布战略（rollingUpdate或recreate）。


 K8s的静态实质


 请留意，到目前为止，你所看到的一切基本上是静态的。你有YAML文件，即使经常使用上方的Deployment对象，假设你有一个新版本的容器，你须要编辑.yaml文件，保留并运行它-这触及相当多的手动上班。


 假设你宿愿事情变得愈加灵活，你将须要经常使用额外的工具，比如，咱们将在上方讨论。


 滚动更新：过于美妙而不实在


 虽然咱们正在议论部署容器的新版本...


 自始自终，魔鬼在细节中。滚动更新在Kubernetes存在之前很久就曾经成功了，即使只是批处置脚本触发SSH命令。


 坦率地说，疑问并不是能够封锁并启动运行程序的新实例，而是在短时期内（在部署时期）你的运行程序基本上须要优雅地支持两个运行程序版本-这总是一个幽默的疑问，特意是触及数据库或前后端API之间启动了严重重构的状况。


 因此，请留意营销资料，它们向你采购便捷的滚动更新-它们真正的应战与Kubernetes有关。


 附注：自愈才干


 在相似的背景下，雷同实用于self-healing（自愈）一词。Kubernetes能够执行肥壮审核，而后中断无照应的pod，布置启动一个新的。这也是某种方式上不时存在的性能。你喜欢的发行版实质上不时能够经过各种方式监督并从新启动服务-虽然限于以后机器。


 Kubernetes不能智能处置失误的数据库迁徙造成的运行程序失误，而后经过神奇的方式自愈集群，即修复损坏的数据库列。


 我只是觉得关于自愈系统的讨论通常在某种水平上含有后者的象征（兴许在治理层之间），而实践上它是更基本的性能。


 服务发现、负载平衡和Ingress


 到目前为止，咱们讨论了灵活生成pod，但从未讨论过网络流量如何实践抵达你的运行程序。Kubernetes实质上是灵活的，这象征着你可以在任何时刻生成新的pod或封锁它们。


 Kubernetes有一些概念可以协助你处置这个疑问，从Service对象（准许将集群的局部泄露给外部）到Ingress对象（准许启动HTTP负载平衡）。雷同，这将触及少量的YAML和相当多的浏览，但在一天完结时，Kubernetes准许你将运行程序接纳到的任何流量路由到你的集群，反之亦然。


 （幽默的Ingress理想：您将须要装置Ingress控制器（Kubernetes没有内置规范控制器），它将为您执行负载平衡。选用很多：在像AWS这样的平台上，您可以便捷地经常使用ELB，假设经常使用裸金属Kubernetes，则可以经常使用Contour，等等。）


 最后但雷同关键的是：ConfigMap和Secret治理


 除了您曾经看到Kubernetes执行的各种义务之外，您还可以经常使用它存储性能键值对，以及秘密（思考数据库或API凭据）。


 （自动状况下，Secrets以未加密的方式存储，因此有必要遵照此页面上安保经常使用Secrets局部的倡导，甚至可以齐全拔出外部Secrets存储，从AWS、GCP和Azure的处置方案到HashiCorp的Vault。）


 够了！这些YAML文件难道不会变得凌乱吗？


 嗯...假设您思考经常使用Kubernetes部署等运行，那么您将须要一个Deployment，以及一个ConfigMap和或许还有Secret。而后还有一些其余服务和咱们尚未触及的对象。这象征着，您最终将失掉不可胜数行的YAML。这并不是实质上的凌乱，但在这个小阶段，曾经触及了少量的DevOps复杂性。


 但是，您也是一名开发人员，宿愿不必定是那位在保养这些文件的人。


 只需有须要，经常使用你的IDE的Kubernetes支持（在我这里是IntelliJIDEA）对Helmcharts、Kustomize文件等启动编码支持，会极大地协助你。哦，咱们还没有议论过它们。让咱们来谈谈。这里有一段视频，会让你迅速了解IntelliJ的Kubernetes插件。


 Kubernetes：附加主题


 什么是Helm？HelmChart又是什么？


 你可以把Helm构想成Kubernetes的包治理器。让咱们了解一些概念：


 正如咱们上方提到的，仅仅在Kubernetes集群中装置WordPress就会造成不可胜数行的YAML代码。假设你不用亲身编写这些YAML代码，而是可以经常使用预先构建的软件包，途中只需交流一些变量，那将是十分好的。


 这就是HelmChart，一堆YAML文件和模板，依照特定的目录结构规划。当你开局装置一个特定的chart时，Helm将下载它，解析它的模板，并与你的值一同生成经典的KubernetesYAML文件/清单，而后将其发送到你的Kubernetes。


 以下是一个这种模板文件的小片段（用于Deployment清单），包括一些占位符：

apiVersion:apps/v1kind:Deploymentmetadata:name:{{include"myChart.name".}}labels:{{-include"myChart.labels".|nindent4}}

 你可以将这些chart分享到仓库中。并没有繁多的自动chart仓库。一个查找盛行chart仓库的好中央是。


 简而言之，经常使用Helm的上班流程如下：

helminstallmy-releaseoci://registry-1.docker.io/bitnamicharts/wordpress

 这条命令会从盛行的bitnamichart仓库装置wordpresschart到你的集群，最终结果是一个运转中的WordPress装置。假设你想知道OCI是什么：你可以将Helmcharts托管在支持OpenContainersInitiative规范的容器Registry中（比如AmazonECR、DockerHub、Artifactory等）。


 由于简直总是须要笼罩一些性能值（在WordPress的状况下，可以在这里检查参数的渺小列表），你会想要向装置命令提供你的详细值。你可以经过一个命名为values.yaml的YAML文件传递值，或许间接经常使用命令行标志。因此，装置命令或许会像这样：

helminstallmy-releaseoci://registry-1.docker.io/bitnamicharts/wordpress--valuesvalues.yaml//ORhelminstallmy-releaseoci://registry-1.docker.io/bitnamicharts/wordpress--setwordpressUsername=m4rc0//etc...

 假设你想深化了解Helm，我剧烈介绍你浏览《学习Helm》一书。


 什么是Kustomize？


 在前文中，你了解到Helm经常使用模板生成Kubernetes清单。这象征着有人须要将Kubernetes清单制形成Helm模板，启动保养，而后作为最终用户，你可以经常使用helm命令行客户端来运行它们。


 Kustomize的开发人员选用了不同的门路：它准许你经过将额外的更改层叠在原始清单之过去创立清单的自定义版本。因此，与其创立模板并在其中搁置"占位符"，你最终会失掉一个文件结构，例如：

├──deployment.yaml//youroriginalKubernetesmanifestfilef└──kustomization.yaml////(inmorerelalisticscenar,you'devenhave'overlays'subfoldersfordifferentenvironments,likedevelopment/staging/prodetc

 而后，你可以运转kustomizebuild，以便Kustomize运行你的笼罩层，并渲染最终的YAML结果，你可以间接输入kubectl命令（或间接运转kubectlapply-k）。

kustomizebuild.|kubectlapply-f-

 假设你想了解kustomization.yaml文件须要如何结构化，可以检查这里。


 哪个更好：Helm还是Kustomize？


 咱们都喜欢Reddit上的意见，虽然有争议：。


 什么是Terraform以及与Kubernetes的区别是什么？


 感谢上帝，咱们凑近本指南的完结，我不用再在Terraform上破费另外一千字（提醒：自始自终，你会在Terraform上找到很多书籍和学习资源），所以我会尽量冗长：


 Kubernetes是关于容器编排的。"让我通知你我在这个YAML文件中想要的：为我运转我的容器！"


 Terraform是关于基础设备的创立："让我通知你我在这些HashiCorp性能言语（HCL，.tf）文件中想要的！请为我创立五个主机，几个负载平衡器，两个数据库，几个队列，以及例如我选用的云中的监控设备。"或许："请为我在AWS上设置这些Kubernetes集群（EKS）"。


 我如何在本地经常使用Kubernetes启动开发？


 关于本地开发，你基本上有两个选用。


 你可以运转一个本地的Kubernetes集群，并将你的运行程序部署到其中。你或许会经常使用Minikube来成功这一点。由于整个"我的运行程序出现了变动-如今让咱们构建一个容器镜像-而后让咱们将其部署到我的集群"这个流程手动执行起来相当繁琐，因此你或许还想经常使用相似Skaffold的工具来协助你。检查这个教程以了解如何开局经常使用这个上班流。虽然这种设置是有效的，但它随同着相当多的复杂性和/或资源消耗。


 这就是第二种选用，处置方案的中央。关于本地开发，你基本上会疏忽Kubernetes，将你须要的任何性能克隆到你自己的docker-compose.yml文件中，而后便捷地运转它。这是一个更便捷的设置，但它的缺陷是必需保养两套性能（docker-compose.yml+你的K8s清单文件）。


 假设您曾经在经常使用Kubernetes，请在上方的评论局部通知我您是如何处置本地开发的。


 我真的须要一切这些吗？


 这是一个很好的疑问，如今是撒些实在的Kubernetes轶事的绝佳机遇：系统治理员限制资源以致于Pod的启动时期变得十分长-长到它们被标志为不肥壮并被中断，造成无休止的Pod创立和中断循环，但咱们将长篇的解释留到另一个时刻。


 作为开发者，通常您无法选择，但以下是大局观：


 正如本文早些时刻提到的，关于仅托管Kubernetes集群的学习资料是无量无尽的，咱们不只仅是在议论在裸金属上启动自托管，还有经常使用任何托管Kubernetes变体的状况。假设您有外部专业常识：


 经常出现的Kubectl命令


 假设有任何对开发人员或许须要的kubectl命令感兴味的话，请在上方留言，我会将最罕用的命令参与到这里，作为一个划一分组/排序的列表。


 为什么Kubernetes被缩写为K8s


 我想你或许如今曾经遗记了！这里是间接摘自Kubernetes文档的一段援用：


 Kubernetes的称号源自希腊语，意为舵手或领航员。K8s作为缩写是由于在K和s之间有八个字母。Google在2014年开源了Kubernetes名目。


 完结语


 到目前为止，您应该对Kubernetes有了相当好的概述。反应、更正和随机的意见都是受欢迎的！只需在上方留下评论。


 感谢浏览。


 下一个版本的方案


 在评论局部投票，假设您宿愿以下任何一项或一切这些都出现：


 致谢与参考


 感谢MaartenBalliauw、AndreasEisele、AndreiEfimov、AntonAleksandrov、GarthGilmour、MaritvanDijk、PaulEveritt、MukulMantosh的评论、更正和讨论。特意感谢《GettingStartedwithKubernetes》和《LearningHelm》的作者们。



 如何在CoreOS集成Kubernetes核心组件Kubelet


 许多开发者已经求助于Docker容器来实现云端和本地的新应用迭代时的一致性，而且很多应用都要依赖多个Docker容器的编排。
  
  而围绕着容器集的启动以及为了让它们能够协作而连带的相关设置和配置又引发了一系列新的挑战。


 kubernetes 怎么启动kubelet


 使用Shell脚本运行多进程Docker容器 这个方法大家应该会比较熟悉，使用Shell脚本依次启动Kubernetes的各个组件即可。
  
  以下为 !/bin/bashstart docker daemondocker daemon > /var/log/ 2>&1 & start etcdetcd --dat....