Brains


Algorithm、Machine Learning、Search、cloud computing
on kubernetes, HA, Install

Kubernetes HA集群搭建详细指南

K8s HA集群的运行主要由k8s基本组件、etcd集群和docker运行环境组成的,其中etcd集群可以理解为k8s集群的数据库,它主要作用是服务发现、全局配置、以及保存一些路由相关的信息。为了保证k8s集群的高可用性,我们需要保证etcd存储数据的可靠性,所以在这个我们在搭建k8s集群的过程中搭建了一个etcd HA集群。我们搭建k8s HA集群的次序如下所示: 1、 搭建etcd集群 2、 启动k8s master组件 3、 启动k8s node组件 搭建ETCD集群 etcd集群搭建的方式比较多,可以搭建一个全新的集群,也可以从已有的etcd中,将数据迁移到一个新集群上。 创建一个全新的集群 创建一个全新的集群过程比较简单,这里我们采取的是在三台机器上搭建了一个etcd集群。假如说etcd的运行路径为/home/work/etcd,我们需要手动创建一个data-dir文件夹用于保存etcd中的数据以及集群的一些属性信息,然后在每台机器上启动start-etcd.sh脚本: #!/bin/bash HOSTNAME="http://sandbox-1" CLUSTER="etcd0=http://sandbox-3:2380,etcd1=http://sandbox-2:2380,
Read More
on kubernetes, etcd, data-restore

Etcd数据迁移

本文讲述从一个正在运行的 etcd 上,将数据迁移到一个包含三台 etcd 服务器组成的集群上,其中包含一些故障恢复和数据迁移的方法以及高可用 etcd 集群搭建方式的介绍。 数据迁移 在 inf-platform53 机器上运行着一个 etcd 服务器,其 data-dir 为 /var/lib/etcd/。我们要以 /var/lib/etcd 中的数据为基础,搭建一个包含三个节点的高可用的 etcd 集群,三个节点的主机名分别为: inf-platform53 inf-platform56 inf-platform60 初始化一个新的集群 我们先分别在上述三个节点上创建 /home/work/etcd/data-dir/ 文件夹当作 etcd 集群每个节点的数据存放目录。然后以 inf-platform60 节点为起点创建一个单节点的 etcd 集群,启动脚本 force-start-etcd.sh
Read More
on kubernetes, HA

Kubernetes高可用集群的部署方案

写在前面 这篇文章将介绍如何搭建一个高可用的kubernetes集群,主要参考的文档是:http://kubernetes.io/docs/admin/high-availability/。高可用性是一种需求,有多种选择可以实现这个需求,这里我们采用了最简单的方式搭建了这个集群,即在单个master节点的集群的基础上,部署一个高可用的Etcd集群、创建多个master Pod,并建立了一个对应的Service以实现多个master的负载均衡,最后将所有的Work Node全部注册到Service暴露的端口上。下面是集群的架构部署图: 注:这种高可用部署方案不可行,存在单点问题,查看另一篇文章的解决方案: Kubernetes HA集群搭建详细指南 高可用的部署过程 按照架构图的部署方式,需要做以下几步: 1、部署一个单master节点的Cluster 1#,单个master的集群部署方式比较简单,详情参考:https://get.k8s.io 2、其次我们应该部署一个高可用的Etcd集群Cluster 2#,详情参考:高可用Etcd集群搭建过程 3、在Cluster 1#中新建几个Pod,这个Pod里面运行着master所需要的全部组件 4、设置一个Service,
Read More
on kubernetes, etcd, 分布式存储

Etcd集群搭建过程

Etcd集群简介 随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,已经成为了迫切需要解决的问题,etcd为解决这类问题带来了福音。 我们此次在三个主机上搭建了一个包含三个Etcd节点的集群,实现了集群的动态扩展和收缩,并测试和验证了Etcd集群键——值存储的一致性和高可用性。本文主要参考了:https://github.com/coreos/etcd/blob/release-2.3/Documentation/docker_guide.md 拉取镜像ectd 从 https://quay.io/ 获取etcd最新版本的镜像,本次拉取的是v2.3.7版本。首先拉取到本地: # docker pull quay.io/coreos/etcd 再给这个镜像打上tag,并推送到sofacloud仓库 # docker tag
Read More
on kubernetes, service

[译]Kubernetes之Service

在Kubernetes中Pod是终将消失的,从创建到销毁的过程中,它们是无法自动重启的。而ReplicationController可以用来动态的创建和销毁Pod(比如说在进行滚动升级的时候,可以进行扩展和收缩)。每一个Pod都得到一个属于自己的IP,但这些IP不能一直有效存在,因为这些IP随着Pod的销毁而变得没有了意义。那么这就导致了一个问题,如果一些Pods为集群内部的其他Pods(我们称它们为前端)提供服务,那么这些前端怎么发现、追踪这些后端集合中的服务呢?Service就是做这个事情的。 Service是一个抽象概念,它定义了一些逻辑上的Pods集合,并且定义了访问这些Pods集合的策略,也被称作为micro-service。Service通常通过Label标签选择器来对应相应的Pods集合(也有一些没有标签选择器的,请看下文介绍)。 举个例子,考虑一个运行的镜像,它在集群中有三个副本,这些副本是可以相互替代的,前端并不关心它现在与哪个后端服务打交道。实际上Pods组成的后端服务集合可以是变化的,比如说通过scale进行副本增加或者副本减少,但我们的前端不应该关心或者跟踪后端服务的变化,Service这一层抽象可以做到这一点。 对于常规的应用,Kubernetes提供了一个简单的Endpoints API,当Service中的Pods集合变化时,Endpoints也会相应的做出变化。对于其他情况的应用,Kubernetes为Service提供了一个基于虚拟IP的网桥,这个网桥可以把前端的请求重定向到后端Pods中。 定义一个Service 在Kubernetes中,一个Service是一个REST对象,就像Pod一样。像所有的REST对象一样,将一个Service的定义发送给apiserver就可以创建一个相应的实例。例如,假设你有一系列的Pods都暴露9376端口,并且标签为"app=
Read More
on kubernetes, HTTPS

浅谈HTTPS认证

在学习kubernetes的过程中,关于监控部署这一部分中涉及到了HTTPS方面的知识。以前曾经在Web安全实践这门课上了解过这方面的知识,如今需要再详细的梳理一下HTTPS的认证过程。 HTTP VS HTTPS 因特网早期的很多东西在设计方面都没有考虑安全方面的因素,HTTP协议就是一个鲜明的例子。HTTP采用的明文传输的,如果我们使用wireshark抓包工具,可以很轻易的嗅探一些信息。 HTTPS在HTTP的基础上增加了安全方面的考虑,主要分为2个过程。 使用RSA加密算法来进行身份认证以及协商加密算法和秘钥 使用协商后的加密算法进行数据传输 HTTPS的身份认证 这里的身份认证分为2类,大多数情况下都是客户端需要验证服务端的身份,在政府以及银行一些领域,服务端也需要验证客户端的身份,这身份认证过程中使用的是RSA加密算法。 RSA加密算法 RSA加密算法是一种非对称加密算法,加密和解密的钥匙是不同的,所以被称为非对称加密算法。它有2种秘钥,分为公钥和私钥,公钥任何人都可以查到的,而私钥属于私人保管。这种加密体系下,私钥加密的的密文只有公钥可以解开,所以私钥可以用来签名;而公钥加密的密文只有私钥可以解开,它可以用来加密传输。 在密码学中,很多加密算法都来源于一个数学难题,没错RSA算法的原理也来自于数论领域中的大数难于被质因分解的问题。它的秘钥生成过程大致如下: 选取2个非常大的质数 p 和 q ,而 n = p * q 随机选取一个数 e1 ,但要求
Read More