Cloud

k3s 刚出来的时候，我刚好看到这个项目，然后了解到这是一个轻量级的 k8s 发行版。之前刚好遇到在阿里云学生机（1C2G）上安装 k8s 后内存占用太多的问题，因此就决定尝试。最后的效果超出了预期，k3s 可以帮助我们在低配置机器上运行 k8s 集群，缓解了 k8s 对于资源占用的压力，降低了服务器的成本。 k3s 简介 k3s 是 Rancher 推出的轻量级 k8s。k3s 本身包含了 k8s 的源码，所以本质上和 k8s 没有区别。但为了降低资源占用，k3s 和 k8s 还是有一些区别的，主要是： 使用了相比 Docker 更轻量的 containerd 作为容器运行时（Docker 并不是唯一的容器选择） 去掉了 k8s 的 Legacy, alpha, non-default features 用 sqlite3 作为默认的存储，而不是 etcd 其他的一些优化，最终 k3s 只是一个 binary 文件，非常易于部署 所以 k3s 适用于边缘计算，IoT 等资源紧张的场景。同时 k3s 也是非常容易部署的，官网上提供了一键部署的脚本。 安装环境 本文的安装环境： 阿里云 1C2G 机器若干，运行 CentOS 7.6 64位 k3s v0.5.0 安装脚本 https://get.k3s.io 这是 k3s 的安装脚本。我们直接运行这个脚本就可以安装 k3s。因为我们需要在 k3s 运行之前做一些事情，所以运行脚本的时候我们选择只安装，不启动 k3s...

安装Kubernetes向来不是一件容易的事情。之前在集群上部署好的K8s突然出了问题，于是需要重新安装。这次没有之前那次那么顺利了，出现了很多奇怪的问题。但经过一番实践和总结，总算是得出了Kubernetes国内安装的一个不完全指南。这个指南理论上适用于任意版本的K8s。 Master节点的安装过程主要可以参考《使用kubeadm安装kubernetes1.7》。主要的流程是： 安装Docker 安装Kubernetes相关组件 Kubeadm init Master节点 安装Overlay Network Join Node节点 下面主要说一些关于如何确定软件版本、如何制作软件镜像源等等细微但是很要命的问题。 关于Docker 目前使用Docker 1.12版本是比较稳定的。Docker这种基础设施软件没有必要追最新的。在阿里云的CentOS只要直接yum install docker就可以安装这个版本了。 关于操作系统 本文讲的是在CentOS 7上安装Kubernetes。理由是Kubernetes对CentOS支持比较好，网上资料比较多。当然Ubuntu的支持应该也是没问题的。 关于K8s源 因为国内的网络环境，我们在服务上明显是不能直接访问国外的镜像源的。所以我们找掌握寻找镜像源，以及在必要的时候自己制作镜像源的技能（因为云服务商的镜像源不一定同步了最新的版本）。 所以我们可以直接用阿里云的源，比如： cat >> /etc/yum.repos.d/kubernetes.repo <<EOF [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=0 EOF 目前阿里云的源是1.7.5的，Kubernetes目前的稳定版本是1.8.x，1.9.x马上要发布了。可见过国内的源虽然可以用，但版本上不会特别新。 第二种办法是在国外服务器上下载镜像然后上传到国内服务器。这样的好处是可以任意选择自己想要的版本。具体可以参考使用上文中的《kubeadm安装kubernetes1.7》。 关于镜像 Kubernetes安装过程中一个很大的问题，在于相关组件的镜像都是托管在Google Container Registry上的。国内的镜像加速一般针对的是Dockerhub上的镜像。所以国内的服务器是没法直接安装GCR上的镜像的。 这个问题其实很好解决，首先我们可以自己在本地翻墙拉到镜像，并把镜像push到阿里云的镜像仓库。拉镜像上传的脚本如下： #!/bin/bash set -o errexit set -o nounset set -o pipefail KUBE_VERSION=v1.7.5 KUBE_PAUSE_VERSION=3.0 ETCD_VERSION=3.0.17 DNS_VERSION=1.14.4 GCR_URL=gcr.io/google_containers ALIYUN_URL=registry.cn-hangzhou.aliyuncs.com/muxi images=(kube-proxy-amd64:${KUBE_VERSION} kube-scheduler-amd64:${KUBE_VERSION} kube-controller-manager-amd64:${KUBE_VERSION} kube-apiserver-amd64:${KUBE_VERSION} pause-amd64:${KUBE_PAUSE_VERSION} etcd-amd64:${ETCD_VERSION} k8s-dns-sidecar-amd64:${DNS_VERSION} k8s-dns-kube-dns-amd64:${DNS_VERSION} k8s-dns-dnsmasq-nanny-amd64:${DNS_VERSION}) for imageName in ${images[@]} ; do docker pull $GCR_URL/$imageName docker tag $GCR_URL/$imageName $ALIYUN_URL/$imageName docker login docker push $ALIYUN_URL/$imageName docker rmi $ALIYUN_URL/$imageName done K8s每个版本需要的镜像版本号在kubeadm Setup Tool Reference Guide这个文档的的Running kubeadm without an internet connection一节里有写。所以可以根据安装的实际版本来跳帧这个脚本的参数。注意把上面的镜像地址换成自己的。muxi是你创建的一个namespace，而不是仓库名。...

2019/6/5 今年我们有同学拿到了腾讯云和 Azure 的实习，所以未来在云计算上我们会有更多的领路人，来带领团队在这个方向进行探索。MAE 虽然还没做出来，但 k3s 的发现让我们在服务器上实现了自由，相信很快就会设计出下一代的 MAE 架构。 Muxi App Engine，简称MAE，是木犀的私有PaaS方案，也是木犀云的重要组成部分。MAE主要基于Docker和Kubernetes，为木犀所有应用的构建、部署、监控和扩容提供了一个统一的入口，让我们能专注于服务本身的开发。同时MAE也为木犀提供了一套标准化的运维流程，使得团队开发中的工程化程度进一步提高。 说的这么厉害，那如果你是一个技术小白，我应该如何来解释MAE呢？ TD;LR 比如我们有一个应用，华师匣子。华师匣子是由很多的服务构成的，比如成绩服务，课表服务，图书馆服务等等。每个服务都实现了对应的接口。我们使用Docker来运行这些服务。Docker是一种容器技术。我们可以简单的理解为一种沙盒环境。这些容器的存在，已经很大程度上方便了我们的部署。因为容器可以实现系统资源的隔离，使得服务器上可以同时运行很多不同的服务，而相互不打扰。 但手动部署容器，还是太复杂了。我们要登录服务器手动部署容器。容器如果出现问题，我们也需要亲自去重启。如果我们需要横向拓展，部署多个相同的容器以应对高负载，也需要一个个去手动部署。这个时候就需要一个调度者来帮我们自动完成这个任务。 我们可以把MAE理解为容器的调度者。我们在MAE中新建一个应用和下属的服务，填写相关的信息。比如我们只要提供Docker镜像的地址，就可以一键部署。MAE会帮我们将容器部署到合适的服务器上。如果容器因为某些原因崩溃了，MAE会自动重启容器。如果我们需要横向拓展，那只要在控制台里填写一下需要拓展的数量就可以了。如果需要更新代码，我们只需要提供镜像的新版本号，MAE会自动终止旧版本的容器，新建新版本的容器。一切都是这么简单。可以自动化的事情，我们都会做到自动化。 MAE提供Web UI和CLI。Web UI主要用于日常的使用以及查看监控数据。CLI适合在shell脚本等自动化环境下使用。 MAE带来的最大变革是，今后我们的应用从一开始就应该按Cloud Native的思路去编写。要拥抱云计算，我们必须编写Cloud Native的应用，具体的说，使用微服务架构，写无状态的功能单元，容器技术，将数据库等等持久化的组件作为单独的部分等等，都是Cloud Native的体现。只有这样，我们的应用才能和目前公有云和私有云的基础设施完美结合。 下面就是纯粹的技术讨论了，请耐心阅读。 MAE的技术选型 简单的说，就是Docker和Kubernetes。Docker是容器技术的实现，Kubernetes主要提供了容器编排管理的功能。上一节中说到的大部分自动化功能，都是Kubernetes实现的。MAE中需要我们研发的主要是MAE API服务、Web UI还有CLI程序。除了这些，还有就是在MAE中实现一套最适合我们的对应用的抽象。这套抽象是非常重要的。Kubernetes的概念并不是所有人都可以理解的，也没有必要对使用者暴露最底层的概念。PaaS的用户是从是应用和服务这些逻辑上的概念去看待问题的。所以MAE就提供了针对应用和服务的抽象，并且和Kubernetes整合起来。 MAE的组成部分 MAE的组成，从上到下，大致有三层： MAE服务层 MAE服务层是暴露给用户的一些服务。MAE API Server是MAE是中枢。负责和底层的集群通信，保存应用配置等等。MAE Web UI提供了一个Web界面，用户可以通过Web UI对MAE发出指令，查看监控数据。MAE CLI是一个命令行程序，提供了从命令行和API Server通信的渠道。 逻辑应用层 这一层是抽象的应用层。也就是我们概念上的应用。因为实际的集群中是没有应用概念的（当然Kubernetes的Services+Namespace已经非常接近了），所以我们需要在这里提供对应的抽象。我们可以在MAE中新建应用，然后配置这个应用对应的服务。MAE中的服务（以后简称MAE服务，区别于Kubernetes Service），其实就对应一个微服务。一个应用由至少一个微服务构成。MAE服务是用户可以控制的部署的最小单元。我们可以对某个MAE服务单独进行拓展。比较特殊的MAE服务就是Nginx入口服务，这个服务为所有应用提供反向代理，同时也作为一个MAE下的服务，被MAE部署。 Kubernetes层 Kubernetes这层就是底层的实现层了。包括了Service，Deployment和Pods。其中Service和Deployment在上层共同支撑了MAE服务。Pods则属于最底层的调度单元。在MAE层是完全不可见的。一个Pod由至少一个容器构成。 MAE的流量分发 那么作为一个分布式系统，一个用户的请求究竟是经过怎样的路径，到达最底层的Kubernetes Pod的呢？ 首先DNS把域名解析到Kubernetes的Master节点的公网IP上，然后部署在Master节点上的Nginx入口服务接管，Nginx根据MAE应用设置的域名和URL规则，将这个请求转发到对应应用的某个服务上。Kubernetes的服务都是可以通过<Master内网IP>:<Service Port>来进行访问的。然后Kubernetes proxy用iptables规则，将请求转发到某个节点上的Pod。 由于Kubernetes proxy提供了均衡负载，我们不用再操心如何分配流量到服务下属的多个Pod中的某一个这样的问题。今后可以做的优化是，实现Kubernetes Master节点的高可用，也就是同时部署多个Master节点。这样的话就需要在Master节点之上再实现一个均衡负载。 MAE的实现细节 MAE做的抽象，一个是应用，应用之下是服务。对于这两个抽象，应该各自保存一些什么样的数据，这属于MAE的实现细节。 每个应用需要的信息有，应用名，域名，Nginx转发规则，应用下属的服务列表。 每个服务需要的信息有：服务名，当前镜像版本，镜像仓库地址，Github仓库地址，Kubernetes Service和Deployment需要的全部信息，当前服务属于哪个应用，授权管理当前服务的用户列表。 因为服务是部署的最小单元，因此相对来说服务是MAE中比较核心的一个部分。MAE需要将数据库中保存的服务信息，自动转化为Kubernetes需要的.yaml文件。将数据库中保存的应用信息，自动转化为nginx的配置文件。这是实现上需要去考虑的一个问题。 另外，现在还需要仔细考虑的一点，MAE在全局/应用/服务这几个层面分别需要哪些监控数据。 MAE时代的部署工作流 部署服务之前，首先我们要构建镜像（构建之前可以引入CI，测试通过才可以构建镜像）。给镜像打上版本号，然后发布到云端的镜像仓库（可以用阿里云/蜂巢/Daocloud）。之后我们就可以在MAE中为某个服务新建一次部署了，填上新的版本号，点击部署，就启动了一次部署了。得益于Kubernetes超强的部署能力，我们可以回滚、暂停、继续每一次部署。 MAE的API Server把服务目前的配置转换为.yaml格式，向Kubernetes API Server发送请求。然后Kubernetes会进行相应的处理。和Service相关的就调整Service，和Deployment相关的就调整Deployment。最终服务更新到目标状态，部署完成。 MAE的物理节点组成 MAE的逻辑组成已经介绍了，那MAE和具体的云主机之间是什么关系呢。请看下图：...

这篇文章主要是写我对团队在云计算方向上现状的一些思考。并没有什么关于云计算的干货，毕竟我在这方面还需要大量的实践才能有足够的发言权。 IaaS 我们用的最多的就是IaaS（Infrastructure as a Service）了。阿里云中的ECS和RDS就是典型的IaaS，另外阿里云OSS或者亚马逊S3那样的存储服务也是。 IaaS，简单的理解就是，将计算资源，作为一种基础设施，提供给用户。用户可以像消费水和电一样来按需进行使用计算资源。 IaaS是基于虚拟化和分布式技术来提供服务的。在云计算之前的时代，公司的网站是部署在一台台实体的服务器上的。一般来说，一家小公司，可能只需要一两台服务器就可以满足业务需求了。有服务器也自然有传统的运维人员，这种工程师精通硬件、网络和安全方面的知识，全权负责机房里服务器的正常运转和性能优化。 然而维护一台实体服务器的成本是很高的，需要雇佣一个服务器运维人员，需要付出电费和购置服务器的费用，以及架设网络的成本。 大公司会建立数据中心，其实就是有着大量服务器的厂房。大公司有着足够的人力去维护自有的服务器。 在那个年代，后端工程师部署服务是直接部署在实体机器上的，在部署时需要和运维人员确定服务器的环境等，经常会有一些沟通上的问题。 还有一个问题则是，那时的网站是很难动态伸缩的，一个应用往往同时部署在多台服务器上。然而，要使得一个服务能抗下更多的流量，就需要更多的服务器，如果不能在短时间内配置好新服务器，网站在压力之下往往会崩溃。 云计算对于小公司的好处在于，消除了维护实体服务器需要的各种繁杂的成本。维护实体服务器的责任交给了云服务厂商。小公司只需要购买服务就可以。 对于大公司来说，云计算可以动态扩容，一键部署，使得应用在压力之下可以弹性伸缩。将计算资源利用率最大化。 我们使用的ECS其实并不对应一台实体的服务器，但我们在使用的时候可以将ECS当成一台完整的服务器来使用。这就是虚拟化技术的好处。我们可以按需使用计算资源（一台实体服务器往往是8核或者16核CPU这样的配置，我们用不到这么多的CPU）。 我们也不用担心服务器会被攻击或者数据丢失。ECS提供了自动快照的服务。 在我看来云计算是对计算资源做的一次抽象，将后端应用和实体的服务器硬件资源隔离了。使得基于硬件的备份和维护这些事情抽象出来，开发人员只用关注应用层面的逻辑就可以了。 而RDS和OSS这些服务，也是同理。我们不用关心存储具体的物理位置在哪台服务器上，只需要调用这个服务就可以了。 而RDS、ECS和OSS三个服务的分离，也是一种抽象。ECS只关心业务逻辑，OSS和RDS只关心数据存储。只有无状态的服务才能轻松实现横向的拓展。如果ECS上的应用和数据库一起部署的话，会对应用的可拓展性造成影响。 具体说到我们团队，ECS和RDS我们使用阿里云的服务。对象存储我们则打算自建。一个是利用手上的物理服务器，降低一些成本，还有一个就是研究一下分布式存储相关的技术，加深团队在云计算方面的技术深度（Ceph这个开源的分布式存储框架已经非常强大了，我们目前打算先尝试Ceph）。 PaaS PaaS（Platform as a Service）方面的服务的代表就是Google的App Engine（以下简称GAE）。在App Engine中你只需要写业务逻辑，不需要关心服务和数据的部署。GAE号称会根据你应用的流量实时拓展服务的部署。 GAE带来的其实是更高的一层抽象。将基础设施的使用也屏蔽了。其实这个就将当于大家写了一个Flask应用，push到Github，写一个简单的配置文件，然后就可以访问了。你不用关心Nginx的配置，也不用关心部署多个实例以及均衡负载这些问题。It just works。 另外你还可以在控制台用GUI控制你的应用，以及读取监控数据等等。 我对此是非常感兴趣的，特别是Docker的出现，使得自动化的部署，环境的隔离以及标准化变成了一件比较简单的事情。 我构想中的Muxi App Engine（以下简称MAE）是这样的： 支持Python和Node两种环境，会根据ECS上的实时部署情况，自动将容器实例部署在最合适的ECS上，并且在流量变大时会自动伸缩。在MAE控制台上可以看到常规的Log统计。可以在MAE上用配置中的Git仓库和分支进行一键部署，前端代码也是一样的。 MAE的目标是将一些应用公共的流程尽量标准化，目前我们的自动化部署还是需要自己写Webhook脚本的。统计的话也是需要手动去配置的。Nginx相关的一些配置也是手动的。 MAE是一个单独的服务，部署在一台服务器上。MAE对可支配的ECS都有着记录，并且在对应的ECS上都运行着守护进程，和MAE服务通信。 MAE时代的开发和目前并没有太大的区别，只是每个应用需要有一个MAE的配置文件，里面写了域名、Github仓库、Docker环境等等信息。 我们在MAE上新建一个应用，然后点击部署，就可以部署了。 对于我们的大部分，自己托管数据的应用（相比匣子这样需要实时爬取的应用），比如学而、桂声等等，MAE这样的模式可以很好的讲平台层的运维工作简单化、标准化。 当然MAE如何和微服务结合这个也是一个问题，目前的应用其实是有分拆成服务的空间的，这样的话MAE其实应该是以服务为单位的。 SaaS SaaS（Software as a Service）离普通用户最近的云计算形式。我们用Tower、百度云盘、石墨文档这些，都属于SaaS。 我们日后推出的服务，比如云简历，或者是其他工具类的应用，都是以软件形式向用户提供了某种基于云计算的服务。 结语 基于综合的考虑，我认为云计算是目前最有用，也是最触手可及的前沿技术。 目前后端技术这边，机器学习/人工智能、云计算、大数据，是几个比较火的领域。当然这几个领域目前有融合的趋势。 对于我们来说，要构筑我们的技术壁垒，云计算是最好的突破口。在知识水平、业务体量等种种的不利因素下，云计算是可以深挖，并且实践的一个领域。 无论是对于我们内部服务的支持，或者是对于个人技术能力，就业市场竞争力的提升来说，这都是一个最优的方向。 所以在接下来的很长一段时间，我希望大家能一起努力，在云计算上，达到一个不算太寒碜的水准。这需要所有同学的支持，包括前端、客户端和设计组的同学，因为转向云计算会对目前的开发流程产生很大的影响。然后在UI和品牌方面，自然也需要前端和设计师的配合。PM同学也需要理解这个战略。 就写这么多吧。祝一切顺利。