Magnum Kuernetes源码分析(一)
Magnum版本说明
本文以magnum的mitaka版本代码为基础进行分析。
Magnum Kubernetes
Magnum主要支持的概念有bay,baymodel,node,pod,rc,service。其中Magnum可以创建kubernetes的bay,即kubernetes的集群。本文主要介绍的就是magnum中kubernetes bay的创建过程。
Kubernetes Bay创建流程
首先通过magnum-api发起创建bay的请求,api的入口函数在这里。
@expose.expose(Bay, body=Bay, status_code=201)
def post(self, bay):
"""Create a new bay.
:param bay: a bay within the request body.
"""
...
res_bay = pecan.request.rpcapi.bay_create(new_bay,
bay.bay_create_timeout)
# Set the HTTP Location Header
pecan.response.location = link.build_url('bays', res_bay.uuid)
return Bay.convert_with_links(res_bay)
接着通过rpc调用,将创建请求发送给magnum-conductor,从而调用了bay_conductor的bay_create函数进行处理。
def bay_create(self, context, bay, bay_create_timeout):
...
try:
# Generate certificate and set the cert reference to bay
cert_manager.generate_certificates_to_bay(bay) //为bay创建秘钥
created_stack = _create_stack(context, osc, bay, //驱动heat,为bay创建对应的stack
bay_create_timeout)
...
接着我们来分析创建stack的过程。
def _create_stack(context, osc, bay, bay_create_timeout):
template_path, heat_params = _extract_template_definition(context, bay) //获取模板文件的地址和参数
tpl_files, template = template_utils.get_template_contents(template_path) //获取模板文件内容和其他需要的文件
# Make sure no duplicate stack name
stack_name = '%s-%s' % (bay.name, short_id.generate_id()) //生成stack name
if bay_create_timeout:
heat_timeout = bay_create_timeout
elif bay_create_timeout == 0:
heat_timeout = None
else:
# no bay_create_timeout value was passed in to the request
# so falling back on configuration file value
heat_timeout = cfg.CONF.bay_heat.bay_create_timeout
fields = {
'stack_name': stack_name,
'parameters': heat_params,
'template': template,
'files': tpl_files,
'timeout_mins': heat_timeout
} //拼成heat的参数
created_stack = osc.heat().stacks.create(**fields) //驱动heat创建stack
return created_stack
kubernets的模板文件是kubecluster.yaml。这是一个heat的模板文件。下文主要对这个文件进行分析。
至此,一个bay就可以完整创建出来了。
kubernetes bay stack
kubecluster.yaml是一个标准的heat模板。heat模板的说明可以参看Heat Orchestration Template (HOT) Guide。
kubernetes中节点分为master和minion两个。
- master部署有etcd,kube-apiserver,kube-scheduler,kube-controllermanager。master主要负责对于集群的管理和kubernetes的数据存储。master支持多节点部署,通过LB实现etcd和kubernetes服务的高可用。master的数量在baymodel中定义。
- minion部署有kubelet,kube-proxy,flannel,docker-io。minion是实际创建容器的节点,也就是k8s中的minion。minion节点同样可以有多个。初始的数量在baymodel中定义。
从这个文件,可以看到创建一个kubernetes集群需要的资源。下文对各个resource进行一一分析。
resources:
fixed_network: //kubernetes集群的内网,所有创建出来的node,都会在该内网中
type: OS::Neutron::Net
properties:
name: private
fixed_subnet: //kubernetes集群的内网子网,所有创建出来的node,都会分配该子网的ip地址
type: OS::Neutron::Subnet
properties:
cidr: {get_param: fixed_network_cidr}
network: {get_resource: fixed_network}
dns_nameservers:
- {get_param: dns_nameserver}
extrouter: //对外的外网路由
type: OS::Neutron::Router
properties:
external_gateway_info:
network: {get_param: external_network}
extrouter_inside: //内网路由,连接外网
type: OS::Neutron::RouterInterface
properties:
router_id: {get_resource: extrouter}
subnet: {get_resource: fixed_subnet}
secgroup_base: //基础安全组
type: OS::Neutron::SecurityGroup
properties:
rules:
- protocol: icmp
- protocol: tcp
port_range_min: 22
port_range_max: 22
secgroup_kube_master: //供master使用的安全组
type: OS::Neutron::SecurityGroup
properties:
rules:
- protocol: tcp
port_range_min: 7080
port_range_max: 7080
- protocol: tcp
port_range_min: 8080
port_range_max: 8080
- protocol: tcp
port_range_min: 2379
port_range_max: 2379
- protocol: tcp
port_range_min: 2380
port_range_max: 2380
- protocol: tcp
port_range_min: 6443
port_range_max: 6443
- protocol: tcp
port_range_min: 30000
port_range_max: 32767
secgroup_kube_minion: //供minion使用的安全组
type: OS::Neutron::SecurityGroup
properties:
rules:
- protocol: icmp
- protocol: tcp
- protocol: udp
######################################################################
#
# load balancers.
#
api_monitor: //kube-api的负载均衡监控
type: OS::Neutron::HealthMonitor
properties:
type: TCP
delay: 5
max_retries: 5
timeout: 5
api_pool: //kube-api的负载均衡池
type: OS::Neutron::Pool
properties:
protocol: {get_param: loadbalancing_protocol}
monitors: [{get_resource: api_monitor}]
subnet: {get_resource: fixed_subnet}
lb_method: ROUND_ROBIN
vip:
protocol_port: {get_param: kubernetes_port}
api_pool_floating: //kube-api的浮动ip
type: OS::Neutron::FloatingIP
depends_on:
- extrouter_inside
properties:
floating_network: {get_param: external_network}
port_id: {get_attr: [api_pool, vip, port_id]}
etcd_monitor: //etcd的负载均衡监控
type: OS::Neutron::HealthMonitor
properties:
type: TCP
delay: 5
max_retries: 5
timeout: 5
etcd_pool: //etcd的负载均衡池
type: OS::Neutron::Pool
properties:
protocol: HTTP
monitors: [{get_resource: etcd_monitor}]
subnet: {get_resource: fixed_subnet}
lb_method: ROUND_ROBIN
vip:
protocol_port: 2379
######################################################################
#
# kubernetes masters. This is a resource group that will create
# <number_of_masters> masters.
#
kube_masters: //master资源组
type: OS::Heat::ResourceGroup
depends_on:
- extrouter_inside
properties:
count: {get_param: number_of_masters} //创建的master数量
resource_def:
type: kubemaster.yaml //创建master的模板
properties:
...
######################################################################
#
# kubernetes minions. This is an resource group that will initially
# create <number_of_minions> minions, and needs to be manually scaled.
#
kube_minions: //minion资源组
type: OS::Heat::ResourceGroup
depends_on:
- extrouter_inside
- kube_masters
properties:
count: {get_param: number_of_minions} //创建的minion数量
removal_policies: [{resource_list: {get_param: minions_to_remove}}]
resource_def:
type: kubeminion.yaml //创建minion的模板
properties:
...
每个master也是一个stack,它不仅仅包含一个虚拟机,还包括其他一些资源。master的模板在kubemaster.yaml进行了定义。同样,minion的模板在kubeminion.yaml进行了定义。后面再对这些文件进行分析。
Magnum Kuernetes源码分析(一)的更多相关文章
- Magnum Kuernetes源码分析(二)
Kubernetes Master Stack kubernetes master的stack的resources主要分为三个部分. master wait handle wait handle主要用 ...
- Magnum Kubernetes源码分析(一)
Magnum版本说明 本文以magnum的mitaka版本代码为基础进行分析. Magnum Kubernetes Magnum主要支持的概念有bay,baymodel,node,pod,rc,ser ...
- Magnum Kubernetes源码分析(二)
Kubernetes Master Stack kubernetes master的stack的resources主要分为三个部分. master wait handle wait handle主要用 ...
- ABP源码分析一:整体项目结构及目录
ABP是一套非常优秀的web应用程序架构,适合用来搭建集中式架构的web应用程序. 整个Abp的Infrastructure是以Abp这个package为核心模块(core)+15个模块(module ...
- HashMap与TreeMap源码分析
1. 引言 在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Ja ...
- nginx源码分析之网络初始化
nginx作为一个高性能的HTTP服务器,网络的处理是其核心,了解网络的初始化有助于加深对nginx网络处理的了解,本文主要通过nginx的源代码来分析其网络初始化. 从配置文件中读取初始化信息 与网 ...
- zookeeper源码分析之五服务端(集群leader)处理请求流程
leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcesso ...
- zookeeper源码分析之四服务端(单机)处理请求流程
上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析 ...
- zookeeper源码分析之三客户端发送请求流程
znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,通过这个特性可以实现的功能包括配置的 ...
随机推荐
- .net使用cefsharp开源库开发chrome
.net使用cefsharp开源库开发chrome 离上篇写介绍pc端的混合开发和为什么以cefsharp入手研究混合开发已经有好几天,一直忙,抽不出时间继续写怎么搭建cefsharp开发环境.其实没 ...
- JSON解析之Json-lib
1.Json-lib介绍 Json-lib是一个java类库,它用于把beans, maps, collections, java arrays and XML 传递给一个Json,或者返回来把Jso ...
- js 指定位置插入html标签(可编辑div)
demo效果如下: html代码部分如下: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" &q ...
- sql 事务日志传输
原文:sql 事务日志传输 概述 可以使用日志传送将事务日志不间断地从一个数据库(主数据库)发送到另一个数据库(辅助数据库).不间断地备份主数据库中的事务日志,然后将它们复制并还原到辅助数据库,这将使 ...
- codeforces #257 C称号Jzzhu and Chocolate
职务地址:http://codeforces.com/contest/450/problem/C 这次CF的时候绝壁脑残了. ..A题和C题都出现了脑残失误... 唯一一个AC的B题还是被HACK了. ...
- Linux下PHP开发环境搭建
平时写程序时都是在服务器已经搭建好的PHP环境进行的.出于对未知知识的好奇,这几天在自己的机器上搭建起了PHP开发环境.本想轻松顺利的看到phpinfo显示在我的页面上,没想到安装环境时一路的erro ...
- idea中ajax中文乱码
case:@RequestMapping中添加 produces= "text/plain;charset=UTF-8", @RequestMapping(method = Req ...
- Node填坑教程——简易http服务器
我们这一期做一个简易的http服务器. 先建一个文件夹,就算是一个空的项目了.然后新建app.js和package.json文件. 这样一个简易项目的基本文件就建好了. 通过命令行工具,在项目路径下输 ...
- c++对象内存布局的理解
我对c++对象内存布局的理解 引言 结合网上的一些资料,通过自己的一番摸索,得出了一点个人见解.现在写下来,希望与各位同学共同探讨,共同进步. 以下所有代码均是在VS2012下测试. 一个普通的基 ...
- 昨天面试新浪 java试题
昨天去了新浪网面试,感觉新浪真的挺不错的,工作环境那叫一个好啊.对于一般屌丝的话进到这种公司就可以呆一辈子了.做了面试之后感觉不管大公司还是小公司都还是注重基础和你平时工作的积累的.所以不能抱怨现 ...