coreos

从零开始搭建内网高可用k8s集群 前言 前期准备 服务器硬件准备 服务器软件准备 第一步-搭建内网yum仓库 root@test： root@node2: root@master1, master2, node1 第二步-搭建内网harbor服务器 root@test: root@ALL: root@node2: 第三步-在master1，master2节点上搭建haproxy+keepalived框架 root@master1，master2: 第四步-部署k8s集群 root@master1： root@master2： root@node1，node2： 第五步-部署dashboard root@master1: 第六步-搭建ceph root@ALL: myceph@node2: root@node2: 前言 前段时间由于项目需求，需要搭建k8s集群，由于是首次接触，因此经验不足，只搭建了一个最基础的简单集群，现重新在内网搭建高可用集群+分布式存储，记录搭建过程 前期准备 服务器硬件准备 服务器 ip 系统 master1 172.16.140.100 centos7 master2 172.16.140.101 centos7 node1 172.16.140.102 centos7 node2 172.16.140.103 centos7 test——外网服务器

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 从CoreOS发布Rocket应用容器项目到现在，已经过去半年时间了。为了增加辨识度，项目更名为了 Rkt 。在沉寂了许久后，最近又开始在社区里出现了一些新鲜的声音。 首先是4月7日的一条新闻， Google领头投资CoreOS公司1200万美元 以共同合作发展旗下的Kubernetes组件。此次合作除了促成新的商业发行版 Tectonic 的诞生，也使得Rkt容器与Kubernetes的关系拉近了一步：Kubernetes将提供对Rkt的友好支持，而Rkt则将沿用Kubernetes的Pods等概念来规划容器。 随后的4月20日，VMWare发布了旗下的通过容器部署应用的开源操作系统发行版： Photon 。这个项目比较闪亮的地方在于，除了最知名的Docker容器，Photon还支持另外两种容器标准：CloudFoundry旗下的Garden，以及我们即将介绍的AppC/Rkt。CoreOS也在多篇博客中 暗示 VMWare其实以已经是AppC规范社区的一员。 就在5月4日的CoreOS Fest大会上，Linux大鳄红帽公司（Red Hat）联合谷歌（Google）、VMware和 Apcera 共同宣布，将大力支持AppC社区的发展。红帽和谷歌甚至确认 将派出工程师协助维护AppC项目 。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 2015年是各种容器技术与名词扎堆的一年，Docker的出现使得“应用容器”的实施变得易如反掌的同时，也带动了它的许多竞争者。其中一个比较有趣的看点就在于“容器规范”的较量，最近红帽和英特尔也按捺不住，拿出自家的产品趁势搅局。 5月14日，红帽宣布了新的 多容器应用规范Nulecule （DockOne 翻译了这篇新闻 ），同时推出符合这个规范的一个实现：AtomicApp。（这个路子怎么看都有点像AppC和Rkt采用的模式） 因特尔则是发挥自家的特长，在5月18日，发布了 介于虚拟机与容器之间的跨界产品ClearLinux （DockOne同样 翻译了这篇新闻 ）。之所以特别要提这个项目，是因为它首先会实现基于Rkt/AppC规范的容器模型，而将Docker放在了其次的位置。 “容器规范”的概念，看起来让人有些摸不着头脑，但在容器业界中，它确实是颇具诱惑力的一块蛋糕。在这一篇里，我们就来聊一聊支撑Rkt背后的那个“容器规范”：AppC Spec。 AppC规范究竟约定了什么 使用了开源软件的人，未必都会有心情仔细阅读各种开源协议的内容。大多数的使用容器产品用户，也不见得要对容器规范的内容有很高的兴致。 不过，为了更好的理解后面将要介绍到的相关工具，还是不妨稍微深入的了解一些 AppC规范 约定的内容