docker+k8s简介

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了docker+k8s简介相关的知识,希望对你有一定的参考价值。

参考技术A

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

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

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的值来进行设置。

R假设检验之k-s检验(KOLMOGOROV AND SMIRNOV TEST)

R假设检验之k-s检验(KOLMOGOROV AND SMIRNOV TEST)

目录

R假设检验之k-s检验(KOLMOGOROV AND SMIRNOV TEST)

假设检验

假设检验的应用

以上是关于docker+k8s简介的主要内容,如果未能解决你的问题,请参考以下文章

k8s和docker简介

k8s简介

k8s的简介以及搭建

#yyds干货盘点#docker 与 k8s 底层架构的区别

docker和k8s预研

云原生之kubernetes实战部署k8s集群管理平台Wayne