centos mesos docker，k8s和docker区别

大家好,今天小编来为大家解答以下的问题，关于centos mesos docker，k8s和docker区别这个很多人还不知道，现在让我们一起来看看吧！

openstack,docker,mesos,k8s什么关系

了解开放源码软件 OpenStack、Docker、Mesos、Kubernetes的关系，有助于构建高效、灵活的云环境。在企业中，OpenStack作为资源管理平台，将物理机、存储和网络资源统一管理，简化了服务器与虚拟机的部署、扩展和维护过程。它提供了一个界面，类似云服务提供商的控制台，如阿里云或腾讯云，使得开发和测试人员无需直接操作服务器，从而减轻了机房管理员的工作负担。

当测试团队面临快速发展的需求，OpenStack的使用提供了显著的便利性。但同时，也存在应用部署与环境一致性的问题，这促使团队探索更轻量级的解决方案——Docker。Docker提供了“沙盒”环境，每个应用运行在一个隔离的容器内，共享操作系统内核但拥有独立的文件系统、网络配置和环境变量。这样，开发人员可以快速部署应用，并通过镜像共享，减少环境差异带来的问题。

随着应用容器化的趋势，Kubernetes（K8s）成为管理容器化应用的关键工具。Kubernetes提供了自动化部署、扩展和管理容器化应用的能力，包括负载均衡、服务发现和自我修复机制，显著提高了运维效率和应用的可扩展性。通过 Kubernetes，运维团队能够集中管理大量容器服务，实现资源的最优配置和应用的平滑扩展，降低了手动操作的复杂性和风险。

综上所述，OpenStack、Docker和 Kubernetes在云平台构建中扮演着不同的角色，它们之间的紧密协作优化了资源管理、应用部署与运维流程。OpenStack提供了基础资源的管理平台，Docker则聚焦于应用容器的轻量化部署，Kubernetes则承担了容器集群的自动化管理和扩展任务。三者共同作用，构建了一个高效、灵活、可扩展的云平台环境，极大地提升了企业 IT运营的效率和灵活性。

如何配置一个 Docker Swarm 原生集群

如何配置一个 Docker Swarm原生集群

嗨，大家好。今天我们来学一学Swarm相关的内容吧，我们将学习通过Swarm来创建Docker原生集群。Docker Swarm是用于Docker的原生集群项目，它可以将一个Docker主机池转换成单个的虚拟主机。Swarm工作于标准的Docker API，所以任何可以和Docker守护进程通信的工具都可以使用Swarm来透明地伸缩到多个主机上。就像其它Docker项目一样，Swarm遵循“内置电池，并可拆卸”的原则（LCTT译注：batteries included，内置电池原来是 Python圈里面对 Python的一种赞誉，指自给自足，无需外求的丰富环境；but removable，并可拆卸应该指的是非强制耦合）。它附带有一个开箱即用的简单的后端调度程序，而且作为初始开发套件，也为其开发了一个可插拔不同后端的API。其目标在于为一些简单的使用情况提供一个平滑的、开箱即用的体验，并且它允许切换为更强大的后端，如Mesos，以用于大规模生产环境部署。Swarm配置和使用极其简单。

这里给大家提供Swarm 0.2开箱的即用一些特性。

Swarm 0.2.0大约85%与Docker引擎兼容。

它支持资源管理。

它具有一些带有限制和类同功能的高级调度特性。

它支持多个发现后端（hubs，consul，etcd，zookeeper）

它使用TLS加密方法进行安全通信和验证。

那么，我们来看一看Swarm的一些相当简单而简用的使用步骤吧。

1.运行Swarm的先决条件

我们必须在所有节点安装Docker 1.4.0或更高版本。虽然各个节点的IP地址不需要要公共地址，但是Swarm管理器必须可以通过网络访问各个节点。

注意：Swarm当前还处于beta版本，因此功能特性等还有可能发生改变，我们不推荐你在生产环境中使用。

2.创建Swarm集群

现在，我们将通过运行下面的命令来创建Swarm集群。各个节点都将运行一个swarm节点代理，该代理会注册、监控相关的Docker守护进程，并更新发现后端获取的节点状态。下面的命令会返回一个唯一的集群ID标记，在启动节点上的Swarm代理时会用到它。

在集群管理器上运行：

# docker run swarm create

Creating Swarm Cluster

3.启动各个节点上的Docker守护进程

我们需要登录进我们将用来创建集群的每个节点，并在其上使用-H标记启动Docker守护进程。它会保证Swarm管理器能够通过TCP访问到各个节点上的Docker远程API。要启动Docker守护进程，我们需要在各个节点内部运行以下命令。

# docker-H tcp://0.0.0.0:2375-d

Starting Docker Daemon

4.添加节点

在启用Docker守护进程后，我们需要添加Swarm节点到发现服务，我们必须确保节点IP可从Swarm管理器访问到。要完成该操作，我们需要在各个节点上运行以下命令。

# docker run-d swarm join--addr=<node_ip>:2375 token://<cluster_id>

Adding Nodes to Cluster

注意：我们需要用步骤2中获取到的节点IP地址和集群ID替换这里的<node_ip>和<cluster_id>。

5.开启Swarm管理器

现在，由于我们已经获得了连接到集群的节点，我们将启动swarm管理器。我们需要在集群管理器中运行以下命令。

# docker run-d-p<swarm_port>:2375 swarm manage token://<cluster_id>

Starting Swarm Manager

6.检查配置

一旦管理运行起来后，我们可以通过运行以下命令来检查配置。

# docker-H tcp://<manager_ip:manager_port> info

Accessing Swarm Clusters

注意：我们需要替换<manager_ip:manager_port>为运行swarm管理器的主机的IP地址和端口。

7.使用docker CLI来访问节点

在一切都像上面说得那样完美地完成后，这一部分是Docker Swarm最为重要的部分。我们可以使用Docker CLI来访问节点，并在节点上运行容器。

# docker-H tcp://<manager_ip:manager_port> info

# docker-H tcp://<manager_ip:manager_port> run...

8.监听集群中的节点

我们可以使用swarm list命令来获取所有运行中节点的列表。

# docker run--rm swarm list token://<cluster_id>

Listing Swarm Nodes

尾声

Swarm真的是一个有着相当不错的功能的docker，它可以用于创建和管理集群。它相当易于配置和使用，当我们在它上面使用限制器和类同器时它更为出色。高级调度程序是一个相当不错的特性，它可以应用过滤器来通过端口、标签、健康状况来排除节点，并且它使用策略来挑选最佳节点。那么，如果你有任何问题、评论、反馈，请在下面的评论框中写出来吧，好让我们知道哪些材料需要补充或改进。谢谢大家了！尽情享受吧:-)

Ubuntu 15.04下安装Docker

配置 Docker镜像下载的本地 mirror服务

Docker安装应用(CentOS 6.5_x64)

在 Docker中使用 MySQL

在Ubuntu Trusty 14.04(LTS)(64-bit)安装Docker

Docker安装应用(CentOS 6.5_x64)

Ubuntu 14.04安装Docker

阿里云CentOS 6.5模板上安装 Docker

docker mesos在生产环境的实践

我们是一家做生鲜电商的公司，从系统搭建初期，我们就采用微服务的架构，基于DevOps体系来不断提高我们的交付的质量和效率，随着业务和团队规模的发展，服务逐渐进行拆分，服务之间的交互越来越复杂，目前整个微服务已经近几十个应用模块，整体架构上包括负载均衡、API网关、基于Dubbo的微服务模块、缓存、队列、数据库等，目前整个集群的资源利用率也没有一个合理的规划评估，虚拟机上部署多个应用服务隔离性也存在问题，考虑到越来越多门店以及第三方流量的接入，需要考虑系统的快速的伸缩能力，而基于统一资源管理的Docker容器技术在这些方面有一些天然的优势，并且和微服务架构、DevOps体系完美衔接。

经过调研和对比，最终我们采用Mesos作为底层资源的管理和调度，Marathon作为Docker执行的框架，配合ZooKeeper、Consul、Nginx作为服务注册发现。目前已经有部分的核心业务已经平稳的运行在基于Docker容器的Mesos资源管理平台上。

逻辑架构

部署架构

在发布流程中，在发布上线之前的环节是预发布，预发布环境验证完成后进行打包，生成Docker镜像和基于虚拟机部署的应用部署包，push到各自对应的仓库中，并打Tag。

生产环境发布过程中，同时发布到Mesos集群和原有的虚拟机集群上，两套集群网络是打通的。

网络架构

在网络架构选型时，会考虑一下几个原则：

docker bridge使用默认的docker0网桥，容器有独立的网络命名空间，跨主机的容器通信需要做端口NAT映射；Host的方式采用和宿主机一样的网络命名空间，网络无法做隔离，等等这些方式有非常多的端口争用限制，效率也较低。

Docker Overlay的方式，可以解决跨主机的通信，现有二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。

Docker在libnetwork团队提供了multi-host网络功能，能完成Overlay网络，主要有隧道和路由两种方式，隧道原理是对基础的网络协议进行封包，代表是Flannel。

另外一种是在宿主机中实现路由配置实现跨宿主机的容器之间的通信，比如Calico。

Calico是基于大三层的BGP协议路由方案，没有使用封包的隧道，没有NAT，性能的损耗很小，支持安全隔离防护，支持很细致的ACL控制，对混合云亲和度比较高。经过综合对比考虑，我们采用calico来实现跨宿主机的网络通讯。

安装好ETCD集群，通过负载均衡VIP方式（LVS+keepalived）来访问ETCD集群。

ETCD_AUTHORITY=10.10.195.193:2379

export ETCD_AUTHORITY

构建Calico网络集群，增加当前节点到集群中，Calico节点启动后会查询 Etcd，和其他 Calico节点使用 BGP协议建立连接。

./calicoctl node–libnetwork–ip=10.10.3.210

增加可用的地址池ip pool

./calicoctl pool add 10.4.10.0/24–nat-outgoing

./calicoctl pool show

创建网络，通过Calico IPAM插件（Driver（包括IPAM）负责一个Network的管理，包括资源分配和回收），-d指定驱动类型为Calico，创建一个online_net的driver为Calico的网络：

docker network create-d calico–ipam-driver calico–subnet=10.4.10.0/24 online_net

启动容器，网络指定刚才创建的online_net，容器启动时，劫持相关 Docker API，进行网络初始化。查询 Etcd自动分配一个可用 IP，创建一对veth接口用于容器和主机间通讯，设置好容器内的 IP后，打开 IP转发，在主机路由表添加指向此接口的路由，宿主机10.10.3.210的路由表：

宿主机10.10.50.145的路由表：

容器包发送包的路由过程如上图，宿主机10.10.3.210上的容器IP 10.4.10.64通过路由表发送数据包给另外一个宿主机10.10.50.145的容器10.4.10.55。

对于有状态的数据库，缓存等还是用物理机（虚拟机），来的应用集群用的是虚拟机，Docker容器集群需要和它们打通，做服务和数据的访问交互。那么只需要在物理机（虚拟机）上把当前节点加入容器网络集群即可：

ETCD_AUTHORITY=10.10.195.193:2379

export ETCD_AUTHORITY

./calicoctl node–ip=10.10.16.201

服务自注册和发现

API网关提供统一的API访问入口，分为两层，第一层提供统一的路由、流控、安全鉴权、WAF、灰度功能发布等功能，第二层是Web应用层，通过调用Dubbo服务来实现服务的编排，对外提供网关的编排服务功能，屏蔽业务服务接口的变更；为了能够快速无缝的实现web层快速接入和扩容，我们用Consul作为服务注册中心实现Web服务的自动注册和发现。

对于Web服务注册，我们自己实现了Register，调用Consul的API进行注册，并通过TTL机制，定期进行心跳汇报应用的健康状态。

对于Web服务的发现，我们基于Netflix Zuul进行了扩展和改造，路由方面整合Consul的发现机制，并增加了基于域名进行路由的方式，对路由的配置功能进行了增强，实现配置的动态reload功能。API网关启动定时任务，通过Consul API获取Web服务实例的健康状态，更新本地的路由缓存，实现动态路由功能。

平台的微服务框架是基于Dubbo RPC实现的，而Dubbo依赖ZooKeeper做服务的发现和注册。

Consul在Mesos Docker集群的部署方案：

不建议把Consul Agent都和Container应用打包成一个镜像，因此Consul Agent部署在每个Mesos Slave宿主机上，那么Container如何获取宿主机的IP地址来进行服务的注册和注销，容器启动过程中，默认情况下，会把当前宿主机IP作为环境变量传递到Container中，这样容器应用的Register模块就可以获取Consul代理的IP，调用Consul的API进行服务的注册和卸载。

在日常应用发布中，需要保障发布过程对在线业务没有影响，做到无缝滚动的发布，那么在停止应用时应通知到路由，进行流量切换。

docker stop命令在执行的时候，会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认的10秒，会继续发送SIGKILL的系统信号强行kill掉进程。这样我们可以让程序在接收到SIGTERM信号后，有一定的时间处理、保存程序执行现场，优雅的退出程序，我们在应用的启动脚本中实现一段脚本来实现信号的接受和处理，接收到信号后，找到应用的PID，做应用进程的平滑kill。

应用的无缝滚动发布、宕机恢复

Marathon为运行中的应用提供了灵活的重启策略。当应用只有一个实例在运行，这时候重启的话，默认情况下Marathon会新起一个实例，在新实例重启完成之后，才会停掉原有实例，从而实现平滑的重启，满足应用无缝滚动发布的要求。

当然，可以通过Marathon提供的参数来设置自己想要的重启策略：

“upgradeStrategy”:{“minimumHealthCapacity”: N1,“maximumOverCapacity”: N2}

如何判断新的实例是否启动完成可以提供服务，或者当前容器的应用实例是否健康，是否实例已经不可用了需要恢复，Marathon提供了healthchecks健康监测模块

"healthChecks": [{

"protocol":"COMMAND",

"command":{

"value":"sh/data/soft/healthcheck.sh app 10.10.195.193"

},

"gracePeriodSeconds": 90,

"intervalSeconds": 60,

"timeoutSeconds": 50,

"maxConsecutiveFailures": 3

}]

healthcheck.sh通过负载均衡调用HealthMonitor来获取应用实例的监控状态， HealthMonitor是我们的健康检查中心，可以获取应用实例的整个拓扑信息。

容器监控、日志

对于容器的监控，由于我们是采用Mesos Docker的容器资源管理的架构，因此采用mesos-exporter+Prometheus+Grafana的监控方案，mesos-exporter的特点是可以采集 task的监控数据，可以从task的角度来了解资源的使用情况，而不是一个一个没有关联关系的容器。mesos-exporter导出Mesos集群的监控数据到Prometheus，Prometheus是一套监控报警、时序数据库组合，提供了非常强大存储和多维度的查询，数据的展现统一采用Grafana。