Category Archives: Docker

visual studio 容器工具首次加载太慢 vsdbg\vs2017u5 exists, deleting 的解决方案

如上情况 感兴趣可以打开  GetVsDbg.ps1

 

  下面说说解决方案 下载包

转载于:https://www.cnblogs.com/microestc/p/10784877.html   from:https://blog.csdn.net/weixin_30809333/article/details/99176681

View Details

windows 10 下加载docker报错，当前用户不在“docker-users"组中，请将你自己添加到”docker-users"组，然后注销并重新登录

工具VS2019 MSDN解决方法：https://docs.microsoft.com/zh-cn/visualstudio/containers/troubleshooting-docker-errors?view=vs-2019 执行net localgroup docker-users DOMAIN\username（“DOMAIN\username”这个是用户名，根据你的电脑的用户名填入） /add   from:https://blog.csdn.net/weixin_41432198/article/details/104575932

View Details

使用 Docker 排查 Visual Studio 开发方面的问题

未启用卷共享。 启用“Docker CE for Windows”设置中的卷共享（仅 Linux 容器） 若要解决此问题，请执行以下操作： 右键单击通知区域中的“Docker for Windows” ，并选择“设置” 。 选择“共享驱动器” ，并共享系统驱动器和项目所在的驱动器。  备注 如果文件显示“已共享”，可能仍需要单击对话框底部的“重置凭据…”链接，以便重新启用卷共享。 若要在重置凭据后继续，可能必须重启 Visual Studio。  提示 如果未配置共享驱动器，Visual Studio 2017 版本 15.6 之后的版本会发出提示 。 容器类型 向项目添加 Docker 支持后，请选择 Windows 或 Linux 容器。 Docker 主机必须运行类型相同的容器。 要更改正在运行的 Docker 实例中的容器类型，请右键单击系统托盘中的 Docker 图标，再选择“切换到 Windows 容器…”或“切换到 Linux 容器…” 。 无法开始调试 其中一个原因可能与在用户配置文件的文件夹中有过时调试组件有关。 请执行以下命令来删除这些文件夹，以便在下次调试会话上下载最新调试组件。 del %userprofile%\vsdbg del %userprofile%\onecoremsvsmon 调试应用程序时特定于网络的错误 尝试执行可从清理容器主机网络下载的脚本，此操作会刷新主机上的网络相关组件。 装载被拒绝 使用 Docker for macOS 时，可能会遇到引用文件夹 /usr/local/share/dotnet/sdk/NuGetFallbackFolder 错误。 将文件夹添加到 Docker 中的“文件共享”选项卡 Docker 用户组 使用容器时，可能会在 Visual Studio 中遇到以下错误： 复制

必须是“docker-users”组的成员，才有使用 Docker 容器的权限。 若要将自己添加到 Windows 10 中的组，请执行以下步骤： 从“开始”菜单中，打开“计算机管理” 。 展开“本地用户和组”，并选择“组” 。 找到“docker-users”组，右键单击并选择“添加到组” 。 添加用户帐户或帐户。 注销后再次登录，以使更改生效。 还可以在管理员命令提示符下使用 net localgroup 命令向特定组添加用户。 cmd复制

[…]

View Details

Docker安装问题3 No default Boot2Docker ISO found locally, downloading the latest release（然后下载失败!）

问题背景 Win8.1 Docker-toolbox版本为18.03.0，在解决了上文这个问题后：Docker安装问题2 This computer doesn’t have VT-X/AMD-v enabled，启动Docker Quick Terminal时，报下面的错;

  问题原因 启动时如果检测到没有 Boot2Docker，就会去下载，在下载过程中法出现了网络连接上的错误，导致启动失败。 解决方案 先删除已下载的临时文件，我的目录是：C:\Users\libin.docker\machine\cache. 用其他工具去下载对应的 boot2docker.iso 文件，下载链接：https://github.com/boot2docker/boot2docker/releases/download/v18.06.1-ce/boot2docker.iso 注意: 这里的链接地址其实就在上面的报错信息中，直接复制也可以。 将下载好的文件放到1中的目录下（不需要解压）   from:https://blog.csdn.net/lililuni/article/details/83243062

View Details

Docker 部署 Net Core

一、docker 安装及设置

  二、新建Net Core 程序 1、新建Net Core 项目。注意不启动Docker 支持   2、发布新建的项目（目标运行时：可移植）   3、在发布后的文件夹中新建一个Dockerfile 文件（没有后缀） 大概内容如下：

  三、上传发布后的项目到Linux服务器（CentOS） 1、进入程序的发布目录

  2、直接访问就可以了     3、docker 容器自动启动（在容器退出或断电开机后，docker可以通过在容器创建时的 --restart参数来指定重启策略）

4、docker 相关命令 镜像文件和容器命令

  容器日志

from:https://www.cnblogs.com/songl/p/11128012.html

View Details

Docker入门 第一课 --.Net Core 使用Docker全程记录

微服务架构无疑是当前最火热的开发架构，而Docker作为微服务架构的首选工具，是我们必须要了解掌握的。 我通过一天的时间，网上查文档，了解基础概念，安装Docker，试验Docker命令，通过Docker，成功部署运行Asp.NET core示例程序，算是基本入门。 这篇文章是自己总结的Docker入门篇，力求简洁，快速入门，以最短的时间看到学习成果，为深入学习Docker做基础。   学习前提：不要畏惧 面对未知，人们心里往往会产生恐惧，这是人与生俱来的，所以，我们在进入新的领域之前，首先要克服的是自己的畏难心理。不要因为困难，看几眼就放弃，那样你永远学不会。 面对新的未知领域，我们要把它当成一座灯塔，让它指引我们前进的方向。   第一：了解几个概念 镜像（Image）：相信大家看到这个词，都明白什么意思，我们可以把它理解为操作系统的安装盘，Ghost镜像。我给它个定义，就叫：Docker基础运行环境副本。 容器（Container）：运行中的Docker实例，称为容器。也就是一个镜像（Image）的运行时状态。 镜像仓库（Repository）：Docker为开发者提供了面向各种环境的已经打包好的镜像，这些镜像构成了一个镜像仓库。开发者只需找到自己需要的Docker镜像，下载到本地，添加自己的应用上去，运行即可，某些工具类的镜像，可无需修改，直接运行。 Docker 主机（Host）：运行着Docker容器的计算机或虚拟机，用于执行Docker的守护进程。 Docker客户端（Client）：是与Docker主机守护进程进行通信的工具，如：Docker控制台。   第二：安装Docker 不同操作系统按照方式不同，以Win7系统为例，需要利用 docker toolbox 来安装，可以使用阿里云的镜像来下载。 下载地址：http://mirrors.aliyun.com/docker-toolbox/windows/docker-toolbox/ 安装完成之后，在桌面找到三个启动图标：Oracle VM VirtualBox，Kitematic(Alpha)，Docker Quickstart …。 安装完成之后，建议重启一下计算机。 Oracle VM VirtualBox ：是一个虚拟机程序。Docker是运行在Linux环境下的，要想在Windows下运行，必须借助虚拟机。感兴趣的话可以留着以后研究。 kitematic（alpha）：是docker推出的GUI工具，可以更简便地操作Docker，非常适合windows用户使用习惯，推荐大家试试。这个alpha表示预览版吧，可能功能还不完善。 Docker Quickstart Terminal：是Docker控制台启动程序，双击图标启动Docker。 如果一切正常的话，可以看到以下界面。 如果启动过程中出现下面错误，Looks like something went wrong in step 'Looking for vboxmanage.exe’… 意思是没有找到虚拟机启动程序，需要设置VirtualBox的环境变量，系统环境变量中增加VBOX_MSI_INSTALL_PATH和VBOX_INSTALL_PATH 值都为C:\Program Files\Oracle\VirtualBox\ ，即VirtualBox的安装路径，注意后面的\ 不能少。环境变量设置完成之后，可尝试重新启动。   第三：熟悉几个命令 我建议实际工作中使用图形界面 kitematic，真的既简单又实用，但Docker命令还是要学习的，最重要的是，使用命令行操作显得更酷更专业。 docker 命令都是以docker开头，下面介绍几个简单，常用的命令。仅作基础介绍，具体参数用法可后期详细学习 。 docker pull：从镜像仓库中拉取镜像 。 docker run：通过镜像创建一个新的容器，并运行。需要注意的是，如果本地没有指定的镜像，会直接去镜像库下载，一定要保证拼写正确。 docker stop：停止一个容器 。 docker start：启动一个容器 。 docker restart：重启一个容器 。 docker ps：列出当前运行的容器机器状态 。 docker images 或 docker image ls：列出本地镜像。 docker build：使用Dockerfile创建自己的镜像。   第四：操作演示，从hello world开始 你可以登录Docker官方镜像仓库，选择自己感兴趣的镜像进行试验，这里我们选择最简单的 hello-world。 Docker官方镜像仓库地址：https://hub.docker.com […]

View Details

什么是CI/CD

CI, CD AND CD 当我们在谈论现代的软件编译和发布流程的时候，经常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。这里我们将给大家介绍它们之间的区别和联系。 持续集成（CONTINUOUS INTEGRATION） 在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前 持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。 持续交付（CONTINUOUS DELIVERY） 持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。 通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。 但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。 持续部署（CONTINUOUS DEPLOYMENT） 如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工作流中构建失败才能阻止它部署到产品线。 持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。 合并CI CD and CD？ 当然，正如我所说，他们每部分都更加接近生产环境。你可以构建自己的持续集成环境，然后，一旦团队适应，你可以添加持续交付流，最后，可以添加持续部署流到整个工作流中。 举例CI, CD and CD 流水线 到底值不值这样做呢? 持续集成: 你需要具备哪些条件: 你的团队需要为每个新功能，代码改进，或者问题修复创建自动化测试用例。 你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。 研发团队需要尽可能快的提交代码，至少每天一次提交。 你能获得什么呢？: 通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中 发布编译将会更加容易，因为合并之初已经将所有问题都规避了 减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。 测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试。 你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。 持续交付 需要具备什么条件？: 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求 部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。 你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。 你能收获什么？: 繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。 你可以更快的进行交付，这样就加快了与客户之间的反馈环。 轻松应对小变更，加速迭代 持续部署 需要具备的条件: 研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。 你的文档和部署频率要保持一致。 特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。 可以获得什么？: 发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。 在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。 客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。 如前所述，您可以采用持续集成，持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目，并且还没有客户，那么你就可以去创建这些工作流，最好是将这三个方面都实现，并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目，那么您可以一步一步地分阶段去实现他们。   原文链接：http://www.ttlsa.com/news/ci-cd-cd/ from:https://www.cnblogs.com/soymilk2019/p/11445773.html

View Details

CD基金会、Jenkins、Jenkins X、Spinnaker和Tekton的常问问题

FAQ 什么是持续交付（CD）？ CD是一种软件工程方法，团队在短周期内生成软件，确保软件可以随时可靠地发布。微服务、云原生架构的兴起引发了持续交付实践的必然结果。这与CI/CD有关，其中包括持续集成（CI） – 将所有开发者工作副本一天多次合并到共享主线的做法。 宣布了什么？ CDF（Continuous Delivery Foundation，持续交付基金会）是一个新的、中立的组织，将发展和维持一个开放的持续交付生态系统。它将提供统一的治理和与供应商中立的管理，以及对资金和运营的监督。CD基金会的第一批项目是Jenkins、Jenkins X、Spinnaker和Tekton。 为什么CD社区组成基金会。为什么需要？ 整个行业都迫切需要围绕管道、工作流程和其他CI/CD领域合作定义行业规范，并为CI/CD工具提供基础支持。例如，Jenkins社区正在寻求一个“全方位服务”的基金会来托管Jenkins（最受欢迎的CI/CD项目之一），并构建一个增强协作的平台。还需要一个全行业的中立DevOps/CD会议。 这是否代表了云原生态系统的转变？ 是的，市场已转向容器化和云原生技术，因此CI/CD系统、DevOps和相关工具的生态系统发生了根本性的变化。CNCF云原生互动景观展示了CI/CD领域的多样性，以及在该领域中活跃的众多项目和供应商。 通过建立供应商中立的持续交付基金会，业界顶级开发者、最终用户和供应商可以将CI/CD作为方法，定义/记录最佳实践以及创建培训材料，以使全球任何软件开发团队能够交付代码更改更快、更可靠、无论它们是否为云原生。 开发者为何要关心？ CI/CD项目目前面临的挑战，包括工具复杂性和管道和其他CI/CD工具缺乏行业标准化，正在抑制增长和创新。由于缺乏中立的法律实体和强有力的治理，项目很难吸引新开发者和组织的宝贵支持。项目维护者和开发者花费大量时间和金钱处理安全程序和监督等方面的变通方法。这使人们不再关注新的发展和创新。拥有广泛行业支持的基金会将能够更快地定义行业规范，并为跨项目协作创造更多机会，以改善开发者的工具。 谁用CD？ CD广泛应用于云计算、企业IT，并且正在迅速扩展到其他顶级行业垂直领域。例如，在网络运营商与供应商并肩工作，开发CI/CD工具，使开发者能够直接与上游项目的分支合作 – 大幅缩短实施新功能的时间，并解决数月到数天的错误。使用云原生技术（如Kubernetes）时，设置CI/CD管道将加快发布生命周期。这使开发者每天可以多次发布；让团队灵活到足以快速迭代。 CDF如何与渐进式交付相关？ 渐进式交付（Progressive delivery）是现代持续交付技术的一种形式，例如灰度发布、功能标记、A/B测试、经过验证的部署组等。渐进式交付技术和技术与持续交付密切相关。有关渐进式交付的更多信息，请阅读James Governor关于此主题的Redmonk博客：https://redmonk.com/jgovernor… 这将如何影响开源软件的开发？ 持续交付可提高软件开发团队的速度、生产力和可持续性。CDF促进行业顶级开发者、最终用户和供应商之间的合作，以确保CD方法的软件工程充分发挥其潜力，推进开源软件开发。 哪些项目将包含在CDF中？ CDF正在推出四个项目：Jenkins、Jenkins X、Spinnaker和Tekton，还有更多感兴趣的项目正在筹备中。我们邀请人们关注CDF技术监督委员会（“TOC”），该委员会将在未来做出项目决策：https://github.com/cdfoundati…。 我是否必须是成员才可以贡献到CDF项目？ 绝对不是，CDF中的开源项目或任何Linux基金会计划的技术贡献都不需要成员资格。组织作为成员加入CDF，因为它们希望在持续交付模型和最佳实践的增长和发展中扮演积极的角色，而不只是支持CDF中的开放源码项目。如果你有兴趣加入，请参阅https://cd.foundation/members…。 什么是Jenkins？ Jenkins是领先的开源自动化服务器，由大量不断增长的开发者、测试者、设计者和其他对持续集成、持续交付和现代软件交付实践感兴趣的人提供支持。它基于Java虚拟机（JVM），提供超过1,500个插件，可将Jenkins扩展为几乎所有技术软件交付团队使用的自动化服务器。2019年，Jenkins有超过了200,000个已知安装，使其成为部署最广泛的自动化服务器。 什么是Jenkins X？ Jenkins X是Kubernetes上现代云应用程序的开源CI/CD解决方案。Jenkins X提供管道自动化、内置GitOps和预览环境，以帮助团队协作并加速他们的软件交付。Jenkins X使用最好的OSS工具自动化Kubernetes的CI + CD，如Jenkins、Tekton、Prow、SkaffoldKaniko和Helm。 为什么Jenkins和Jenkins X成为CDF的一员？ Jenkins和Jenkins X将成为与技术兴趣相关的中立社区的一部分，并在构建开发者社区和项目治理方面获得帮助。CD基金会还将协助Jenkins和Jenkins X的营销和文档工作。 这对现有Jenkins用户有何影响？ 将Jenkins和Jenkins X捐赠给CD基金会将促进行业内开发者、最终用户和供应商之间的更多合作。有关详细信息，请参阅此电子邮件和与Jenkins社区的对话：https://groups.google.com/for… 什么是Tekton？ Tekton是一组用于构建CI/CD系统的共享开源组件。它使持续交付控制平面现代化，并将软件部署的大脑转移到Kubernetes。Tekton的目标是通过供应商中立的开源基金会为CI/CD管道、工作流程和其他构建模块提供行业规范。Tekton的代码在https://github.com/tektoncd/p…。 为什么Tekton成为CDF的一员？为什么Google会捐赠代码？ 作为CDF的创始成员，谷歌正在捐赠Tekton。正如Kubernetes通过提供一组标准的API在云中进行交互而彻底改变了应用程序开发，Google的目标是通过CD基金会为DevOps从业者提供相同的优势。CDF将提供行业规范、安全、实用和可扩展的持续交付构建块，可用于在任何地方部署代码。 Tekton对knative build的影响是什么？ 从第1天开始，可插拔性一直是knative的核心功能。将Build与Serving分离的目标是强化这种可插拔性概念。已经对构建系统感到满意的用户可以将其与Knative Serving一起使用。Tekton将继续支持Knative生态系统作为一流的目标环境。Tekton管道将部署到Knative环境。 在可预见的未来，Knative Build将继续作为Knative的一部分，专注于无服务器环境的源到容器工作流程。这两个项目将在标准和界面上保持紧密联系。 什么是Spinnaker？ Spinnaker是云端优先的持续交付平台，最初由Netflix创建，目前由Netflix和Google共同领导。它支持所有主要的云平台和Kubernetes，并得到各个供应商的贡献。Spinnaker通常用于大规模组织，DevOps团队通过提供“黄金路径”（golden path）应用程序部署管道来支持许多开发者。 为什么Google/Netflix将Spinnaker捐赠给CDF？ 随着Spinnaker最近将其治理正式化，将其转移到基金会是社区自然的下一步。Spinnaker设计为持续交付平台，通常与Jenkins结合使用，因此CDF真的是项目的理想之家。 Spinnaker也是一个多组件系统，在概念上与Tekton分享了许多想法 – 看到两个项目在一个基金会上聚集在一起，是将持续交付向前推进的巨大机会。 这对Spinnaker用户有何影响？ Spinnaker作为CDF的一员，社区将有更多机会创建更简单、更强大的端到端体验，并就CI/CD的一套通用标准进行协作。Spinnaker用户在持续交付领域拥有丰富的经验，加入CDF提供了一个与更广泛的社区分享专业知识的绝佳机会。 Spinnaker用户还将受益于CDF社区中广泛的CI/CD知识，他们使用的各种工具之间的一致性，当然还有不断改进的生态系统！ 未来的CI/CD项目进入CDF的过程是怎样？ 其他项目预计将通过其即将成立的技术监督委员会（TOC）加入CDF：https://github.com/cdfoundati…，重点是将CD生态系统整合在一起，围绕可移植性和互操作性构建规范和项目。 CDF的下一步是什么？ 接下来的步骤是启动治理结构。将成立一个理事会、技术和外联/营销委员会。我们计划在未来几个月内实现这一目标，并邀请新成员加入我们的社区。如果你有兴趣加入社区推进CD，请到https://cd.foundation/members…。 CNCF的参与程度，为什么需要一个单独的基金会？ 首先要注意的是，CD适用于整个软件行业，而不仅仅适用于现代云原生应用程序。CNCF（Cloud Native Computing Foundation，云计算本地计算基金会）是CDF的姐妹基金会，拥有自己的治理结构和使命。每个基金会都有不同的使命，由其创始成员和技术专家定义。CNCF认为大多数与CD相关的工具超出了他们专注的云原生定义的范围，后者主要关注容器化、微服务、服务网格和编排。CDF超越云和容器，包括传统基础设施、移动、物联网、裸机等。CNCF和CDF都属于较大的Linux基金会旗下，计划在许多领域进行合作，包括同场会议。例如，CDF将于5月20日在西班牙巴塞罗那的KubeCon + CloudNativeCon Europe 2019举办持续交付峰会（CDS）活动。 CDF如何支持或与DevOps领域的其他玩家合作？ CDF的使命是为开发者、最终用户和供应商提供一个中立的家庭，以便在CI/CD方法上进行协作。在这方面，CDF将通过发布关注可移植性的最佳实践、培训材料和行业指南来支持DevOps从业者。 有兴趣成为这个新基金会成员并制定治理方案的组织应到CDF加入的页面。开发者可以在此处注册CD基金会邮件列表：info@lists.cd.foundation。任何有兴趣加入CDF的项目都可以联系技术监督委员会（TOC）：https://github.com/cdfoundati…。 KubeCon […]

View Details

CentOS7安装k8s

借鉴博客：https://www.cnblogs.com/xkops/p/6169034.html 此博客里面有每个k8s配置文件的注释：https://blog.csdn.net/qq_35904833/article/details/78190257   啊西吧，啊西吧，根据上面的博客终于安装成功了。妈的，网上大部分博客安装k8s配置写得乱七八槽的，终于找到一篇条理清晰，安装详细的k8s安装博客啦，哈哈哈哈，不容易啊快三个星期了，从狗屁不懂搞这玩意。   下面写一写我自己的安装流程： 　　一、安装准备： 准备两台服务器（我用的是CentOS7系统）：192.168.26.227，192.168.26.228 一主一从： master机：192.168.26.227 node机：192.168.26.228     简单说一下k8s： 　　　　　　　　k8s是个什么玩意？ 可以这样去理解：k8s全称：Kubernetes，它可以看作是一个分布式系统支撑平台。   　　　　　　　　我们为什么要用k8s集群？ 故障自愈： k8s这个玩意可以监控容器运行，我们把项目放到容器里。由于一些外部内部原因服务器承受不住压力，如果主节点上的容器突然挂了，k8s立刻会自己将主机上的服务调度到另一个node机器上运行 应用更新： 更新项目上线时不用中断当前项目的运行。   还有一些自动扩容，缩容的概念就不讲了，我本人也没亲身体会用过，不好说。       　　　　　　k8s的全生命周期管理： 在k8s进行管理应用的时候，基本步骤是：创建集群，部署应用，发布应用，扩展应用，更新应用。    　　　　　　k8s的主要组件，以及它们主要是用来干什么的： etcd：一款开源软件。提供可靠的分布式数据存储服务，用于持久化存储K8s集群的配置和状态   apiservice：用户程序（如kubectl）、K8s其它组件之间通信的接口。K8s其它组件之间不直接通信，而是通过API server通信的。这一点在上图的连接中可以体现，例如，只有API server连接了etcd，即其它组件更新K8s集群的状态时，只能通过API server读写etcd中的数据。   Scheduler：排程组件，为用户应用的每一可部署组件分配工作结点。   controller-manager：执行集群级别的功能，如复制组件、追踪工作结点状态、处理结点失败等。Controller Manager组件是由多个控制器组成的，其中很多控制器是按K8s的资源类型划分的，如Replication Manager（管理ReplicationController 资源），ReplicaSet Controller，PersistentVolume controller。   kube-proxy：在应用组件间负载均衡网络流量。   kubelet：管理工作结点上的容器。   Contriner runtime Docker， rkt等实际运行容器的组件   上面都是些k8s集群所要用到的组件，具体这些组件都是用来干嘛的呢，我们来好好分析分析。 master主机上192.168.26.277必须要有的组件： etcd　　：提供分布式数据存储的数据库吧，用于持久化存储k8s集群的配置和状态 kube-apiserver：api service提供了http rest接口，是整个集群的入口，K8s其它组件之间不直接通信，而是通过API server通信的。（只有API server连接了etcd，即其它组件更新K8s集群的状态时，只能通过API server读写etcd中的数据） kube-scheduler：scheduler负责资源的调度 kube-controller-manager：整个集群的管理控制中心，此组件里面是由多个控制器组成的，如：Replication Manager（管理ReplicationController 资源），ReplicaSet Controller，PersistentVolume controller。主要作用用来复制组件、追踪工作结点状态、处理失败结点   node节点机上192.168.26.228必须要有的组件： flannel：好像是用来支持网络通信的吧 kube-proxy：用来负载均衡网络流量 kubelet：用来管理node节点机上的容器 docker：运行项目镜像容器的组件     2018年11月30日： 今天又看了一些博客，多了一些认识和理解，如下： 　　　　　　　　k8s的整个集群运行原理：【重点核心知识很重要】 master主机上的kube-controller-manager是整个集群的控制管理中心，kube-controler-manager中的node controller模块 通过apiservice提供的监听接口，实时监控node机的状态信息。 当某个node机器宕机，controller-manager就会及时排除故障并自动修复。   node节点机上的kubelet进程每隔一段时间周期就会调用一次apiservice接口报告自身状态，apiservice接口接受到这些信息后将节点状态更新到ectd中。kubelet也通过apiservice的监听接口监听pod信息，如果监控到新的pod副本被调度绑定到本节点，则执行pod对应的容器的创建和启动，如果监听到pod对象被删除，则删除本节点对应的pod容器。（目前对pod、容器、镜像这些概念还不是很清晰，无法在大脑中构建这都是些什么玩意，先做个笔记记着吧）     […]

View Details