关于kubernetesdocker的信息

十分钟了解kubernetes的核心概念

下文将简单介绍 kubernetes 的核心概念。因为这些定义可以 kubernetes 的官档中找到， 中文文档地址 ，所以下文中也会避免用大段枯燥的文字介绍。相反，我们会使用一些图表和示例来解释这些概念，借助它们我们可以全面理解晦涩难懂的一些概念。

kubernetes （k8s）是自动化容器操作的开源平台，这些操作包括布署，调度和节点集群间扩展。如果你曾经用docker容器技术布署容器，那么可以将docker看成kubernetes内部使用的低级别组件。kubernetes不仅仅支持docker，还支持rocker（另一种容器技术）。

使用kubernetes拥有下面的特点：

实际上，kubernetes只需一个部署文件，使用一条命里就可以布署多层容器（前后端）的完整集群。

集群是一组节段，这些节点可以是物理服务器或者虚拟机，之上安装了kubernetes平台。下图展示这样的集群，注意概图为了强调核心概念有所简化。

上图可以看到如下组件，使用特别的图标表示Service和Label：

Pod（上图绿色框）安排在节点上，包括一组容器和卷。同一个Pod里面的容器共享一个命名网络空间，可以使用localhost互相通信。Pod是短暂的，不是持续性实体。你可以有下面的问题：

如上图所示，一些Pod有Label。一个Label是attach到Pod的一对键值对，用来传递用户定义的属性。比如你可能创建了一个"tier"和"app"标签，通过Label(tier=frontend, app=myapp)来标记前端Pod容器，使用Label(tier=backend, app=myapp)标记后台容器，然后可以使用Seletors选择带有特定标签Label的Pod，并且将Service或Replication Controller应用到上面。

是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么？能否将Pods划分到逻辑组里面去。

Replication Controller确保任意时间都有着指定数量的Pod副本在运行。如果为某个Pod创建了Replication Controller并制定3个副本，它会创建3个副本，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，

如果之前不响应的Pod恢复了，现在就有了4个Pod，那么Replication Controller就会将其中一个终止并保持总数为3。如果在运行中将副本总数改为5，Replication Controller就会立即启动2个新的Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时比较有用。

当创建Replication Controller时，需要执行两个东西：

现在已经创建了Pod的副本，那么在这些副本上如何进行均衡负载？我们需要的是Service。

如果Pods是短暂的。那么重启时IP地址可能会发生变化，怎么才能从前端容器正确可靠的指向后端容器呢？

Service是定义一些列Pod以及访问这些Pod的策略的一层抽象。 Service通过Label找到Pod组。因为Service是抽象的，所以在图表中通常看不到它们的存在，这也就让这一概念更难理解。

现在，假定有两个后台Pod，并定义后台Service的名称为‘backend-service’，label选择器为（tier=backend, app=myapp）。backend-service会完成如下两件重要的事情：

下图动画展示了Service的功能。注意该图做了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。

有一个特别类型的Kubernetes Service，称为‘LoadBlancer’，作为外部负载均衡器使用，在一定数量的Pod之间负暂均衡。

节点（上橘色方框）是物理机或虚拟机，作为kubernetes worker，通常称为Minion。每个节点都运行如下Kubernetes关键组件：

集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角，并且拥有一系列组件，如Kubernetes API Service。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。

十分钟带你理解Kubernetes核心概念

再下面会继续理解属于和概念，最后尝试使用。

将Kubernetes的Runtime由Docker修改为containerd

Kubernetes 从 v1.20 开始弃用 Docker，并推荐用户切换到基于容器运行时接口（CRI）的容器引擎，如 containerd、cri-o 等。如果你使用了云服务商提供的托管 Kubernetes 服务，那你不用担心，像 GKE、AKS 等云服务商都已经在新版集群中把默认的运行时切换到 containerd 。如果是自管的集群则需要手动修改集群的Runtime，以下介绍集群Runtime的修改方法。

首先将需要修改的节点设置成不可调度

驱逐该节点上除了daemonset的pod

关闭docker、containerd 和 kubelet：

我们在使用docker-ce作为集群runtime时默认安装了containerd，先将其卸载。

安装containerd可参考我的文章： Containerd的安装和配置

/etc/containerd/config.toml 修改默认的 pause 镜像为国内的地址，替换 [plugins."io.containerd.grpc.v1.cri"] 下面的 sandbox_image：

配置下镜像仓库的加速器地址：

修改 kubelet 配置，将容器运行时配置为 containerd，编辑/etc/sysconfig/kubelet 文件，在该文件中可以添加kubelet 启动参数：

或者修改/etc/systemd/system/kubelet.service.d/10-kubeadm.conf文件

--container-runtime ：指定使用的容器运行时的，可选值为 docker 或者 remote，默认是 docker，除 docker 之外的容器运行时都应该指定为 remote。

--container-runtime-endpoint：是用来指定远程的运行时服务的 endpiont 地址的，在 Linux 系统中一般都是使用 unix 套接字的形式，unix:///run/containerd/containerd.sock。

--image-service-endpoint：指定远程 CRI 的镜像服务地址，如果没有指定则默认使用 --container-runtime-endpoint 的值了，因为 CRI 都会实现容器和镜像服务的。

配置完成后重启 containerd 和 kubelet 即可：

查看服务

允许调度

docker+k8s简介

容器是镜像的可运行实例。容器是您机器上的沙盒进程，与主机上的所有其他进程隔离。总而言之，一个容器：

运行容器时，它使用隔离的文件系统。此自定义文件系统由 容器映像 提供。由于镜像包含容器的文件系统，它必须包含运行应用程序所需的一切——所有依赖项、配置、脚本、二进制文件等。镜像还包含容器的其他配置，例如环境变量、运行的默认命令、和其他元数据。

Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器镜像中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。

容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。

如果说以 Docker 为代表的容器引擎将软件的发布流程从分发二进制安装包转变为直接分发虚拟化后的整个运行环境，令应用得以实现跨机器的绿色部署；那以 Kubernetes 为代表的容器编排框架，就是把大型软件系统运行所依赖的集群环境也进行了虚拟化，令集群得以实现跨数据中心的绿色部署，并能够根据实际情况自动扩缩。

以容器构建系统

自从 Docker 提出“以封装应用为中心”的容器发展理念，成功取代了“以封装系统为中心”的 LXC 以后，一个容器封装一个单进程应用已经成为被广泛认可的最佳实践。然而单体时代过去之后，分布式系统里应用的概念已不再等同于进程，此时的应用需要多个进程共同协作，通过集群的形式对外提供服务，以虚拟化方法实现这个目标的过程就被称为容器编排（Container Orchestration）。

容器之间顺畅地交互通信是协作的核心需求，但容器协作并不仅仅是将容器以高速网络互相连接而已。如何调度容器，如何分配资源，如何扩缩规模，如何最大限度地接管系统中的非功能特性，让业务系统尽可能免受分布式复杂性的困扰都是容器编排框架必须考虑的问题，只有恰当解决了这一系列问题，云原生应用才有可能获得比传统应用更高的生产力

Docker 设计的 Dockerfile 只允许有一个 ENTRYPOINT，这并非无故添加的人为限制，而是因为 Docker 只能通过监视 PID 为 1 的进程（即由 ENTRYPOINT 启动的进程）的运行状态来判断容器的工作状态是否正常，容器退出执行清理，容器崩溃自动重启等操作都必须先判断状态。设想一下，即使我们使用了 supervisord 之类的进程控制器来解决同时启动 Nginx 和 Filebeat 进程的问题，如果因某种原因它们不停发生崩溃、重启，那 Docker 也无法察觉到，它只能观察到 supervisord 的运行状态，

在想要创建的 Kubernetes 对象对应的 .yaml 文件中，需要配置如下的字段：

也需要提供对象的 spec 字段。对象 spec 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。 Kubernetes API 参考 能够帮助我们找到任何我们想创建的对象的 spec 格式。

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括：

“Service” 简写 “svc”。如上文提到的，Pod不能直接提供给外网访问，而是应该使用service。Service就是把Pod暴露出来提供服务，Service才是真正的“服务”，它的中文名就叫“服务”。Service代理Pod集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端Pod中的容器。

k8s使用service还有一个原因。一般而言，k8s每创建一个新的Pod，它的ip地址都是不一样的，一个Service与特定的一个或者一组Pod挂钩，即使Pod挂掉了，k8s又创建了新的特定的Pod，Service仍然与这个新的Pod挂钩，这样，Pod的ip不一样了，哪怕端口也不一样了，仍然能通过Service来获取Pod所提供的服务。

Service是如何保持这种与特定Pod绑定的关系的呢？那就是“Label”和“Label Selector”，可以给Pod分配特定的Label，然后配置Service，通过“Lable Selector”选择具有这些特定“Label”的Pod来接受请求、提供服务。

为容器设定最大的资源配额的做法从 cgroups 诞生后已经屡见不鲜，但你是否注意到 Kubernetes 给出的配置中有limits和requests两个设置项？这两者的区别其实很简单：requests是给调度器用的，Kubernetes 选择哪个节点运行 Pod，只会根据requests的值来进行决策；limits才是给 cgroups 用的，Kubernetes 在向 cgroups 的传递资源配额时，会按照limits的值来进行设置。

K8S 和 Docker 关系简单说明

本篇文章目的：让你更全面了解k8s概念，以及学到在工作中常用的操作。整体更偏向于原理和应用。在正式开始k8s之前，我们先看看k8s和Docker的关系，分别从虚拟化角度、部署方式角度叙述why use容器，话不多说，开干。

目前发现并没有将kubernetes和Docker技术产生背景和需求进行比较的文章，本文从最纯正的官方定义角度出发并展开，阐述二者产生背景及与传统技术对比。

简要介绍：

官方定义1： Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。

官方定义2： k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

与传统技术对比：

接下来我们看两张经典的图：

一、从虚拟化角度：

上图是Docker容器（可用k8s管理的玩意儿）与传统虚拟化方式的不同之处：传统的虚拟技术在将物理硬件虚拟成多套硬件后，需要在每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。而Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。每个集群有多个节点，每个节点可运行多个容器，我们的kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

二、从部署角度

注意，大家别把这幅图与上面Docker的那张图混淆了，图1是从虚拟化角度，说明了为应用提供必要的运行环境所需要做的虚拟化操作（即：传统：虚拟出的虚拟机装操作系统、Docker：容器引擎管理下的容器）。

而图2是在这些具体运行环境上进行真实应用部署时的情况，传统方式是将所有应用直接部署在同一个物理机器节点上，这样每个App的依赖都是完全相同的，无法做到App之间隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式来将App部署到其中（就像图1上半部分那样），但这样太过繁重，故比虚拟机更轻便的Docker技术出现，现在我们通过部署Container容器的技术来部署应用，全部Container运行在容器引擎上即可。既然嫌弃虚拟机繁重，想用Docker，那好，你用吧，怎么用呢？手动一个一个创建？当然不，故kubernetes技术便出现了，以kubernetes为代表的容器集群管理系统，这时候就该上场表演了。

说白了，我们用kubernetes去管理Docker集群，即可以将Docker看成Kubernetes内部使用的低级别组件。另外，kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。希望我这篇文章中简单的描述能让你对两者有所理解和认识。

到此这篇关于k8s和Docker关系简单说明的文章就介绍到这了。

以上就是本次分享的全部内容，现在想要学习的程序员欢迎关注六星社区，获取更多技能与教程。