阳明的博客

完善的日志系统是保证系统持续稳定运行的基石，帮助提升运维、运营效率，建立大数据时代的海量日志处理等能力都需要日志系统的支持，所以搭建一套行之有效的日志系统至关重要。

本文将介绍两种kubernetes 集群下日志收集的方案：阿里云日志服务或者EFK方案

prometheus2.0正式版已经发布了，新增了很多特性，特别是底层存储性能提升了不少：https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/。

在将之前监控平台升级到2.0 的过程中还是有一些坑的，因为有很多参数已经更改了，还不清除怎么在kubernetes上搭建prometheus监控平台的，可以查看前面的文章Kubernetes使用Prometheus搭建监控平台

本文章中涉及到的yaml文件可以在github中查看。

socket.io 单节点模式是很容易部署的，但是往往在生产环境一个节点不能满足业务需求，况且还要保证节点挂掉的情况仍能正常提供服务，所以多节点模式就成为了生成环境的一种必须的部署模式。

本文将介绍如何在kubernetes 集群上部署多节点的socket.io服务。

文章中涉及到的代码可以前往https://github.com/cnych/k8s-socketio-cluster-demo查看。

Harbor是一个用于存储和分发Docker 镜像的企业级Registry 服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。作为一个企业级私有Registry 服务器，Harbor 提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。Harbor 支持安装在多个Registry节点的镜像资源复制，镜像全部保存在私有Registry 中， 确保数据和知识产权在公司内部网络中管控。另外，Harbor也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。

本文将介绍如何在kubernetes 集群上搭建一个高可用的Harbor 服务。

在前面手动搭建高可用的kubernetes 集群一文中我们安装的kubernetes集群是v1.8.2版本，该版本的dashboard插件还是1.6.x，如果你把dashboard暴露在公网环境下面访问的话，是非常不安全的，因为该版本没有任何的安全登录之类的处理，在最新版本的1.7.x中则新增了更多安全相关的特性，我们可以升级到该版本或以上来暴露我们的dashboard到公网环境下面，当然安全都是相对的，能不暴露在公网环境下面当然是最好的。

谁都不愿意在使用网站服务的时候，被恶心的运营商劫持加上一些他们的服务(真的很贱，不是吗？)，不过这能难道我们程序员吗？当然不能，上https，老子全站https，你再劫持给我看看。

https证书服务大部分都是收费的，而且很贵，阿里云可以申请一个免费的证书，只能绑定一个域名，这里我们使用更加友好的免费https服务：Let’s Encrypt

之前按照和我一步步部署 kubernetes 集群的步骤一步一步的成功的使用二进制的方式安装了kubernetes集群，在该文档的基础上重新部署了最新的v1.8.2版本，实现了kube-apiserver的高可用、traefik ingress 的部署、在kubernetes上安装docker的私有仓库harbor、容器化kubernetes部分组建、使用阿里云日志服务收集日志。

部署完成后，你将理解系统各组件的交互原理，进而能快速解决实际问题，所以本文档主要适合于那些有一定kubernetes基础，想通过一步步部署的方式来学习和了解系统配置、运行原理的人。

本系列系文档适用于 CentOS 7、Ubuntu 16.04 及以上版本系统，由于启用了 TLS 双向认证、RBAC 授权等严格的安全机制，建议从头开始部署，否则可能会认证、授权等失败！

在做Django项目的时候，经常会遇到静态文件访问的问题，在本地开发的时候可以正常的访问静态文件，部署到服务器上后就出现各种幺蛾子了，我猜你一定也遇到过吧？之前在settings.py配置文件中对STATIC_ROOT与STATICFILES_DIRS两个配置项不是特别理解，总感觉都差不多，在线上就把STATIC_ROOT替换成STATICFILES_DIRS了，虽然可以解决问题，但是却没有知其所以然。

之前收集了很多优秀的PDF文档，但是需要看的时候不是很方便，需要去找到这个文件，如果是在手机上的话往往还需要下载PDF相关的插件才行，而且最大的问题是不便于资料的整理和分享。如果能够将PDF转换成网页，岂不是就能解决这些问题了？还能直接分享出去。

这里利用PyPDF包来处理PDF文件，为了方便快捷，我这里直接将一个页面转换成图片，就不需要去识别页面中的每一个PDF元素了，这是没必要的。

现在最火的后端架构无疑是微服务了，微服务将之前的单体应用拆分成了许多独立的服务应用，每个微服务都是独立的，好处自然很多，但是随着应用的越来越大，微服务暴露出来的问题也就随之而来了，微服务越来越多，管理越来越麻烦，特别是要你部署一套新环境的时候，你就能体会到这种痛苦了，随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。如果从头到尾完成过一套微服务框架的话，你就会知道这里面涉及到的东西真的非常多。当然随着微服务的不断发展，微服务的生态也不断完善，最近就发现新一代的微服务开发就悄然兴起了，那就是服务网格/Service Mesh。

我们k8s集群使用的是1.7.7版本的，该版本中官方已经推荐使用Deployment代替Replication Controller(rc)了，Deployment继承了rc的全部功能外，还可以查看升级详细进度和状态，当升级出现问题的时候，可以使用回滚操作回滚到指定的版本，每一次对Deployment的操作，都会保存下来，变能方便的进行回滚操作了，另外对于每一次升级都可以随时暂停和启动，拥有多种升级方案：Recreate删除现在的Pod，重新创建；RollingUpdate滚动升级，逐步替换现有Pod，对于生产环境的服务升级，显然这是一种最好的方式。

最近在测试环境搭建了Kubernetes集群环境，迁移了部分测试环境的应用，由于测试集群性能不是很好，有时会遇到集群资源不够的情况，一般情况下我们是直接通过Dashboard的资源统计图标进行观察的，但是很显然如果要上到生产环境，就需要更自动化的方式来对集群、Pod甚至容器进行监控了。Kubernetes内置了一套监控方案：influxdb+grafana+heapster。但由于之前我们的应用的业务监控使用的是Prometheus，所以这里准备使用Prometheus来完成k8s的集群监控。