VF@优快云

当前版本的kubeadm已经原生支持部署HA模式集群，非常方便即可实现HA模式的kubernetes集群。本次部署基于Ubuntu18.04，并使用最新的docker版本：18.06.3，kubernetes适用1.17.x版本，本文采用1.17.0。Kubernetes&Docker技术交流QQ群：491137983，一起学习，共同进步！1 环境准备准备了六台机器作安装测试工作...

Kubernetes 1.5.2发布，调整部署文档。1 环境准备准备了三台机器作安装测试工作，机器信息如下: IP Name Role OS 172.16.1.101 Master01 Controller Centos7.2 172.16.1.106 Minion01 Compute Centos7.2 172.16.1.107 Minin

随着docker及Kubernetes技术发展的越来越成熟稳定，越来越多的公司开始将docker用于生产环境的部署，相比起物理机上直接部署，多了一层docker容器的环境，这就带来一个问题：进程信号接收与处理。相信有不少同学发现，在docker中捕获不到进程的结束信号，这就给我们的一些进程异常处理带来了麻烦，用Supervisor等进程管理工具也能够解决这一问题，不过太“重”了，在容器时代追求“轻

随着docker及Kubernetes技术发展的越来越成熟稳定，容器平台不仅仅局限于部署无状态应用，越来越多的有状态服务也可以在容器云上稳定地部署运行，本文主要就讲讲kubernetes中的PersistentVolume特性（静态PV）。1 名词概念VolumeVolume是Pod的挂载接口，生命周期同Pod，可以在Pod内的各个Container之间进行共享，主要用于存储Pod生命周期内的临时

Kubernetes 1.5.0刚刚发布，添加了众多的新特性，我们的云平台也计划从Mesos和Rancher迁移到kubernetes，所以迫不及待地想尝试一下，Google出品，必属精品，无奈GFW的层层阻挡，让原本简单的部署步骤变得异常复杂，所以写下此文，供各位参考。1 环境准备准备了三台机器作安装测试工作，机器信息如下: IP Name Role OS 172.16.1.

本环境中多实例应用的访问，可以通过Haproxy负载均衡服务提供支持，Haproxy的动态配置及实例的服务发现由Bamboo组件实现，当然，也可以使用大名鼎鼎的Consul来实现。

Master是整个系统的核心，负责管理接入mesos的各个Framework（由frameworks_manager管理）和slave（由slaves_manager管理），并将slave上的资源按照某种策略分配给Framework（由独立插拔模块Allocator管理）。在本环境中用于构建轻量级PaaS平台的Framework是Marathon，Master节点上主要包括以下功能组件：Mesos-master..

Slave节点负责接收并执行来自mesos-master的命令、管理节点上的mesos-task，并为各个task分配资源。mesos-slave将自己的资源量发送给mesos-master，由mesos-master中的Allocator模块决定将资源分配给哪个framework，当前考虑的资源有CPU和内存两种，也就是说，mesos-slave会将CPU个数和内存量发送给mesos-master......

Mesos和Marathon都自带了简易的控制台，可以完成一些简单管理控制功能。Mesos的控制台上可以查看的当前的资源实用情况、Slave节点状态、当前运行的Task、完成的Task、可以切换到Framework（如Marathon）或者Slave。

最近总有同学问kubernets中的各个组件的相关问题，其实这些概念内容在官方文档中都有，奈何我们有些同学可能英文不好，又或者懒得去看，又或者没有找到，今天有时间就专门写了这篇博客。

Kubernetes的调度有简单，有复杂，指定NodeName和使用NodeSelector调度是最简单的，可以将Pod调度到期望的节点上。本文主要介绍kubernetes调度框架中的NodeName和NodeSelector。1 NodeNamePod.spec.nodeName用于强制约束将Pod

本文主要介绍kubernetes的中调度算法中的Taints和Tolerations用法，实际上是对PodToleratesNodeTaints策略和TaintTolerationPriority策略的具体应用。先从中文字面意思

当前版本的kubeadm已经原生支持部署HA模式集群，非常方便即可实现HA模式的kubernetes集群。本次部署基于Ubuntu16.04，并使用最新的docker版本：18.06.3，kubernetes适用1.15.x版本，本文采用1.15.0。Kubernetes&Docker技术交流QQ群：491137983，一起学习，共同进步！1 环境准备准备了六台机器作安装测试工作...

当前版本的kubeadm已经原生支持部署HA模式集群，非常方便即可实现HA模式的kubernetes集群。本次部署基于Ubuntu16.04，并使用最新的docker版本：18.06.1，kubernetes适用1.13.x版本，本文采用1.13.1。Kubernetes&Docker技术交流QQ群：491137983，一起学习，共同进步！1 环境准备准备了六台机器作安装测试工作...

当前版本的kubeadm已经原生支持部署HA模式集群，非常方便即可实现HA模式的kubernetes集群。本次部署基于Ubuntu16.04，并使用最新的docker版本：18.03.1，kubernetes适用1.11.x版本，本文采用1.11.2。 Kubernetes&Docker技术交流QQ群：491137983，一起学习，共同进步！1 环境准备准备了六台机器...

Kubernetes 1.7.6+发布，调整部署文档。本次部署基于Ubuntu16.04，并使用最新的docker版本：17.06。1 环境准备准备了三台机器作安装测试工作，机器信息如下: IP Name Role OS 172.16.2.1 Master Controller,etcd Ubuntu16.04 172.16.2

当前版本的kubeadm原生并不支持部署HA模式集群，但是实际上可以使用kubeadm部署后，再进行少量手动修改，即可实现HA模式的kubernetes集群。本次部署基于Ubuntu16.04，并使用最新的docker版本：17.06，kubernetes适用1.7.x版本，本文采用1.7.6。1 环境准备准备了六台机器作安装测试工作，机器信息如下: IP Name

前边讲了Taints和Tolerations的调度策略，可以满足一些需求场景，但是基于Taints和Tolerations的调度还是毕竟“生硬”，并且也不够灵活，例如：POD的多实例尽量分布到不同的Node节点、POD_A尽量调度到POD_B所在的Node节点等，此时我们就需要Affinity（亲和性）调度策略。

Kubernetes 1.6.6发布，调整部署文档。本次部署基于Ubuntu16.04，并使用最新的docker版本：17.03。

调度器是编排工具的核心，调度策略和算法是编排工具的灵魂。Kubernetes之所以能够大行其道，正是因为其优良的调度算法，本文就来分析下kubernets中scheduler组件的调度原理。

本系列文章主要讲述如何使用Mesos来构建基于Docker容器技术的轻量级PaaS平台。master类型节点负责构建高可用的分布式计算管理平台，slave提供分布式计算支持，bamboo提供服务发现及负载均衡服务。

三年前，关于云计算，更多的还是概念的理解两年前，关于云计算，更多的还是价值的思考一年前，关于云计算，还只是小规模的研发、测试、使用而今天，关于云计算，已经是铺天盖地，动辄几千上万台服务器的规模，推出的产品也全面覆盖了IaaS、PaaS、SaaS，涉及的多种技术甚至超越国外巨头

部署Micro Bosh碰到的问题一、Micro Bosh虚拟机上执行micro bosh部署命令时出错：bosh micro deploy /var/vcap/stemcells/micro-bosh-stemcell-openstack-kvm-0.8.1.tgz报错信息：Could not find Cloud Provider Plugin: openstack

RDO是由红帽RedHat公司推出的部署OpenStack集群的一个基于Puppet的部署工具，可以很快地通过RDO部署一套复杂的OpenStack环境，当前的RDO默认情况下，使用Neutron进行网络管理，默认部署的是OpenStack Havana版本。

CloudFoundry是VMware旗下子公司Pivotal的一款开源PaaS产品，是一个由多个独立子系统组成的分布式系统，能偶支持多种运行时环境、开发语言、框架及服务，可以构建于IaaS平台之上，也可以直接部署于物理机器上，总共有两个版本分别是V1和V2，V2版本采用的更为成熟的架构思想，引入了如Buildpack、Warden等强大灵活的组件，V2版本相比V1版本改动较大，教程及文档等都不通用，所以在使用当中请注意区别。

BOSH是一个针对大规模分布式系统的部署和生命周期管理的开源工具。BOSH的诞生是出自CloudFoundry的部署难题，但是不仅仅局限于部署CloufFoundry，也可以应用于别的分布式系统，只需要其提供符合要求的Release即可，BOSH现在能够支持的IaaS平台包括VMware vSphere，vCloud Director，Amazon EC2， OpenStack。Micro BOSH则是一个微型版的BOSH，因为BOSH本身也是分布式的，由若干个虚拟机组成，所以为了部署分布式的BOSH环境

cinder-volume服务无法正常启动的解决办法

常规的应用，大多数可以不经过任何修改即可部署于CloudFoundry云平台之上，但是在一些特殊情况下，总是不可避免地会出现一些细小的问题，如果在应用设计之初，就考虑到针对云平台的一些特殊情况，遵守云平台的规范，就会使应用更适应云平台环境，不止是CF平台，也包括其他的云平台

Cinder组件装在Controller节点，节点发生故障重启后，发现挂载了volumn的实例无法启动，错误日志如下：2013-06-28 09:48:46 14338 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling2013-06-28 09:48:46 14338 TRACE nova.o

同事调整公司网络，造成OpenStack的控制节点和计算节点间的网络暂时中断，网络恢复后，在控制台看到所有的实例都处于shutoff状态，控制台重启实例后也无法ping通，但是新建的实例却是正常的，查看原实例日志发现错误：cloud-init start running: Mon, 06 May 2013 06:48:47 +0000. up 5.09 seconds2013-05-06

OpenStack中的Cinder-volume组件的iSCSI target volume可以通过iscsitarget或者tgt提供支撑的，通常情况下使用iscsitarget，但是有的时候会出现一些问题，比较常见的就是cinder-volume无法启动、或者创建volume，而解决问题的时候甚至都搞不清楚自己用的到底是tgt还是iscsitarget，因为两个软件都安装了，本文就给大家大概的介绍下这两个软件的安装和出现问题时的解决办法。

问题描述：Cinder组件装在Controller节点，节点发生故障重启后，发现挂载了volumn的实例无法启动，并且无法创建及挂载定的volume，查看cinder-volume服务，处于stop状态，执行启动命令发现无法启动，错误日志如下：2013-12-19 14:44:33 INFO [cinder.service] Starting 1 workers2013-12-19

本文主要介绍在OpenStack Folsom或者Grizzly上部署最新版本的CloudFoundry环境的IaaS平台准备工作。涉及到：IaaS环境搭建，安全组策略配置、密钥对创建、Flavor创建及配额调整。

在CloudFoundry的实际生产环境中，随着业务量的提高，访问量和数据流量的快速增长，附加给CloudFoundry中的各个组件的压力也会随之增大，当组件节点所承受的压力超过了其所能够承受的范围，就会出现节点宕机崩溃或者计算缓慢，解决此类问题无疑需要对应地加大组件节点的计算处理能力，一般来说，可以有两种途径：一是增加该组件节点的计算资源，如加大内存、增加CPU等，这是纵向扩展；二是额外增加具有相同职责的组件节点并通过负载均衡处理以分担原组件节点的计算压力，这是横向扩展。CloudFoundry整个平台组

Mysql服务现在在CloudFoundry的Github上有独立的工程支持，工程名称：cf-mysql-release，是基于V2 Broker API开发的新版Service，功能相当强大，可以通过Broker对内部或者外部的Mysql数据库进行管理，该服务最新的发布版本为Release-V5，本文介绍下如何使用BOSH部署两个独立的mysql服务，其中一个是纯Broker接口服务，另一个包括Mysql-Server，使用同一个release包，只是yml配置文件有差别。

Mysql服务现在在CloudFoundry的Github上有独立的工程支持，工程名称：cf-services-release，这个工程中目前还没有正式的发布版本，之前的版本中还包括了postgresql服务，但是现在已经移除，GitHub上的说明文档中的例子是针对postgresql编写的，实际上mysql服务的配置也是类似，本文就介绍下如何使用BOSH部署一个独立的mysql服务。

CloudFoundry目前官方的版本为V2版，release最新发布为134，不过CloudFoundry在GitHub上的仓库代码贡献非常频繁，一般只要提出有BUG，很快就会有修改并提交，所以，最好的部署方式是直接下载源码，创建dev版的release进行部署，当然，也可以直接使用官方发布的release进行打包部署，本文中使用134.1-dev进行打包部署，如果要使用官方release，指定release路径即可，如：bosh create release release/cf-release-134

本文介绍如何使用Micro Bosh来部署Bosh，部署需要创建8个虚拟机来部署8个Bosh组件，所以，至少得准备好8个Fixed IP，后边使用Bosh的时候需要访问Director组件及配置DNS，所以准备至少2个Floating IP，本文中为（10.68.19.132和10.68.19.133），Bosh组件的详细介绍可以看这里：http://docs.cloudfoundry.com/docs/running/bosh/components/

本文介绍如何在OpenStack环境中部署Micro Bosh，Micro Bosh其实就是Bosh，不过是将分布式的Bosh浓缩到一个机器节点上，用于小规模化部署分布式的Bosh环境，事实上，也可以直接使用Micro Bosh来部署CloudFoundry，不过Micro Bosh只适用于小规模部署的情况，大规模的生产环境如果使用Micro Bosh还是不太适合

CloudFoundry V2版本已经将第三方的服务以独立release包的形式托管在GitHub上，并且已经发布了第一个发布版，包括以下服务：elastic search、memcached、mongodbc、postgresql、rabbitmq、redis、vblob