分类目录归档:分布式

使用Skaffold一键将项目发布到Kubernetes

  当前skaffold版本为v0.4,还未发布正式版本,不建议在生产环境中使用;
  skaffold用于开发人员快速部署程序到Kubernetes中;skaffold提供了dev、run两种模式;使用skaffold需先编写skaffold配置文件,该文件为定义skaffold的工作流;
  Skaffold工作流定义了三个主要阶段Build、Push、Deploy

enter image description here

一、Build
  在构建阶段,Skaffold通过Dockerfile使用源码生成Artifacts,Skaffold中目前Docker镜像、bazel这两种Artifacts,这里使用的是Docker镜像所以也可以成称为Docker镜像,该镜像用于应用程序的运行,Build阶段的输出就是Artifacts;
二、Push
  在推送阶段,Skaffold将把构建阶段生成的Docker镜像推送到Docker镜像仓库中,并使用所配置的镜像名称;在运行Skaffold时需确保镜像能够推送到镜像仓库中;
  但如果使用的是Minikube或 Docker for Desktop本地Kubernetes集群时默认是不推送到镜像仓库的,跳过推送阶段,因为本地已经存在了该镜像所以是可以正常运行的;
三、Deploy
  部署阶段,将最新的Docker镜像部署到k8s中,该阶段可以使用不同的部署工具如kubectl或helm,每个工具都有不一样的参数用于定义如何安装与更新应用程序;

概念介绍

Artifacts
  在Build阶段通过运行一系列步骤来创建Artifacts,在Skaffold中Artifacts分为bazel与Docker镜像,可以定义Skaffold生成多个Docker镜像,Skaffold在开发模式运行时,Skaffold只会重新生成源码已经更改的Docker镜像,通过在Skaffold配置中指定Dockerfile来生成Docker镜像,并指定其名称;

标签策略
  标签策略在Build阶段进行配置,用于配置Skaffold在推送Docker镜像时如果对镜像进行打标签,目前Skaffold支持三种标签策略:sha256标签生成器、git标签生成器、自定义标签生成器策略
  在开发过程中,推荐使用基于内容的标签策略sha256,方便在源代码变更时Skaffold会使Kubernetes重新部署新Docker镜像;

运行模式

  Skaffold有dev、run两种运行模式,也就是开发模式与发布模式,在dev模式下Skaffold会监控项目的源码随着代码的变更会实时的重新生产镜像并将变更更新部署到Kubernetes中;还可在CI/CD管道中运行Skaffold;

  dev模式默认使用sha256标签生成器
  run模式默认使用git标签生成器

  所以注意如果使用run模式又没配置git则Skaffold是无法跑下去的,需配置标签策略(TagPolicy),或配置git即可;

使用流程:

  开发环境使用skaffold部署项目到远程k8s中;
  1、下载skaffold
https://github.com/GoogleCloudPlatform/skaffold/releases/download/v0.4.0/skaffold-windows-amd64.exe
  2、下载kubectl、服务端开放Docker远程连接
在服务端Docker配置中加上: -H tcp://0.0.0.0:2375
  在开发端在创建C:\Users\xin.docker\config.json文件,内容如下:

 {
    "auths" : {
    }
 }

  3、开发端kubectl 配置
  创建C:\Users\xin.kube\config.json文件,配置k8s的连接与密钥,文件内容如下:

 apiVersion: v1
 clusters:
 - cluster:
     server: http://182.61.xx.xxx:8001
   name: minikube
 contexts:
 - context:
     cluster: minikube
     user: minikube
   name: minikube
 current-context: minikube
 kind: Config
 preferences: {}
 users:
 - name: minikube
   user:
 as-user-extra: {}

  4、服务端kubectl使用开启代理
  kubectl proxy –address 0.0.0.0 –accept-hosts ‘.*’
  5、环境变量配置
  需要在环境变量中配置Docker的链接信息:

 DOCKER_HOST = tcp://xxx.xxx.xxx.xxx:2375
 DOCKER_TLS_VERIFY = 0

  下载Demo并使用Skaffold将其部署到Kubernetes中;

  git clone https://github.com/GoogleCloudPlatform/skaffold
  cd examples/getting-started

运行:skaffold dev

enter image description here
enter image description here

  可以看到由于使用的是Minikube所以只有Build、Deploy两个阶段跳过了Push阶段,与我们上面的说法是一致的;
修改main.go的内容即可看到Skaffold检测到了变化,并重新把项目更新到Kubernetes中;

enter image description here
enter image description here

  常见异常信息:

 WARN[0005] run: build: build step: running build: read auth configs: docker config: opening docker config: 
 open C:\Users\xin\.docker\config.json: no such file or directory   

不存在.docker\confog.json文件,在用户目录下添加上即可;

 open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on 
 Windows, the docker client must be run elevated to connect. This error may also indicate that the docker 
 daemon is not running.  

  未配置Docker环境变量,加上DOCKER_HOST、DOCKER_TLS_VERIFY环境变量即可;

本文使用的环境为:minikube、skaffold v0.4、windows

参考资料: https://github.com/GoogleCloudPlatform/skaffold/blob/master/docs/concepts.md

Akka初步介绍

  Akka可能很多人都没有用过,也不知道是什么,但如果说起Scala或Spark就有很多人都听说过或使用过 ,这里简单说下三者的关系Akka是使用Scala开发的,Spark中使用了Akka作为其消息的通信工具;这篇文章主要 说说Akka的一些特性,做个简要的介绍;
  要说Akka首先要从并发开始说起,我记得之前我也写过并发模型相关的文章,并发模型主要有这么三类:
    1、共享内存模型
    2、Actor模型
    3、CSP模型
  共享内存模型:是通过使用线程与锁对共享内存进行控制用于实现并发,它依赖于多线程、锁,会产生过多的线程又使用锁对竞态资源进行同步控制,所以性能不是太高,对编程也不太友好;
  Actor模型:使用Actor作为并发的基础多个任务之间通过Actor相互发送消息进行通讯,Actor比线程轻量得多,一组Actor使用一个或多个线程所以也就没有线程、锁相关影响性能的问题存在,对编程也很友好;
  CSP模型Communicating Sequential Process):为多个进程提供了channel,并发的任务存放于channel当中,Golang的goroutine也是用了类似CSP模式的并发,并在channel中多加一个缓存;
  Actor与CSP模型都提倡:要通过通讯来共享内存,不要通过共享内存来通讯,这个可以说是他们与共享内存模型最大的区别;
  介绍了相关的基本概念,接下来说说今天的主题:Akka
  
  简单来说Akka就是基于Actor模型实现的并发框架;Akka降低了编写具有容错性、可扩展的并发程序的难度,容错性方面采用了“let it crach(让它崩溃)模型”;Akka为垂直扩展(并发)、水平扩展(远程调用)、 高容错提供了一致的编程模型;Akka具有以下几种特性:

  Actors:Actor为并发程序提供了简单高级别的抽象,为异步、非阻塞、高性能的事件驱动模型,1G内存可以容纳数百万个Actor;
  容错性:使用“let it crach”作为其监控层次体系的核心,监控层次可跨越JVM,使编写出“永不停机”、“自愈和”的高容错系统的难度大大降低;
  位置透明:Akka中所有元素都是为了适应分布式而设计的,Actor之间只能通过发送消息进行通讯所有操作均是异步进行的,不管是本地Actor还是远程Actor通信方式、操作都是一致的;
  持久性:Actor的状态、收到的消息可被持久化,并可在Actor启动或重启时恢复状态与消息,不管是JVM崩溃或是节点迁移都适用;

  下面通过一个Akka程序,然后结束本篇文章;

/**
* Created by linx on 2016-06-26.
*/
class Greeter extends Actor {

  override def receive: Receive = {
    case "greet" =>
      println("hello world")
      val hello = context.actorOf(Props[HelloWorld], "hello")
      hello ! "done"
  }
}
/**
  * Created by linx on 2016-06-26.
*/
class HelloWorld extends Actor {

  override def receive: Receive = {
    case "done" =>
      println("done")
      context.system.shutdown()
  }
}
/**
* Created by linx on 2016-06-26.
*/
object Main {
  def main(args: Array[String]): Unit = {
    val system = ActorSystem("hello")
    val greeter = system.actorOf(Props[Greeter], "greeter")
    greeter ! "greet"
  }
}

  程序先创建一个Greeter Actor然后往该Actor发送“greet”字符串,Greeter Actor收到后打印Hello World,然后创建HelloWorld Actor并发送done,HelloWorld结束整个程序;
程序运行结果:
Akka Hello

参考资料:
http://doc.akka.io/docs/akka/2.4.7/scala.html
http://www.solinx.co/archives/464