软件技术学习笔记

个人博客,记录软件技术与程序员的点点滴滴。

EFK结构化日志

在分布式系统中,我们一般把日志集中收集到EFK或ELK中。默认情况下,Elasticsearch(ES)收集到的是一行一行日志文本,但是,这样的日志不方便业务检索,也没有充分发威ES的检索能力。

为了方便业务检索,我们做结构化日志,输出的内容均为JSON格式,经过Filebeat的简单处理,扔给ES存储与建立索引。查看日志时,可以对特定的业务字段做过滤,比如: user.id: 123。 日志输出格式如下,一条日志一行JSON:

继续阅读→

使用Elastic Stack观察分布式服务—K8s: Logging, Metrics, Tracing, APM

落地分布式微服务架构时,遥测信息收集是一个重要的环节。如果没有日志收集、指标收集、分布式追踪、应用性能管理,将导致问题定位效率低下、无法自动弹性伸缩、无法自动预警等,最终可能导致微服务架构落地失败。

在K8s中,我们可以使用Elastic Stack完成这些事情。Elasticsearch完成数据存储与搜索;Kibana提供可视化的用户界面;Beats完成数据采集;APM完成分布式追踪、应用性能管理。

在K8s集成Istio之后,虽然Jaeger可以追踪到Mesh边界,但仍需在代码中转发x-request-idx-b3-...等头部信息,也没有比Elastic APM优美。同时,我们大部分时候只关注应用边界的性能,很少关注Mesh边界的性能。因此,在单独K8s或K8s + Istio集群中,Elastic Stack满足了我们的APM需求。

Elastic Stack数据流

继续阅读→

在K8s中创建本地存储PV

在本地演练K8s,我们不一定需要分布式存储,只需一个本地存储就可以满足我们的需求。但是,本地存储不能自动分配持久化卷(PV),需要我们先创建好PV,PVC才能获取到资源。

继续阅读→

给K8s安装Helm与Tiller

Helm与Tiller是C/S模式配合工作的,它们已变成K8s事实上的标准部署工具。本地快速部署工具Draft也依赖Helm

Helm是安装在本地的,读取/home/$USER/.kube/config与远程的Tiller或K8s API通信。 Tiller是安装在K8s集群中的,有一个独立的Pod与Service。

k8s-master节点执行:

wget https://get.helm.sh/helm-v2.14.3-linux-amd64.tar.gz
tar -zxvf helm-v2.14.3-linux-amd64.tar.gz
sudo cp linux-amd64/helm /usr/local/bin/
sudo cp linux-amd64/tiller /usr/local/bin/

kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.3.3/install/kubernetes/helm/helm-service-account.yaml
helm init --service-account tiller --tiller-image doublemine/kubernetes-helm.tiller:v2.14.3 --skip-refresh   --upgrade

# check version info
xxx@k8s-master:~$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

看得Server端的版本信息,说明工具部署完成。

继续阅读→

Ceph分布式存储与K8s集成

在K8S集群中,比较麻烦的是:有状态服务持久化,并且保证高可用。面临的问题:

  1. 有状态服务POD死亡时,持久化数据能够立刻转移到新拉起的POD。
  2. 持久化数据本身读写的高可用。

Ceph分布式存储就是解决问题2;同时使用独立的分布式存储集群,分离PV与工作节点的耦合,确保PVC能够转移给新的POD,解决问题1。

本文将演练:部署一个Ceph分布式存储单例,通过CephFS集成到K8s。

继续阅读→

基于Docker、K8S和GitLab的云原生微服务Auto-DevOps

目前,微服务是比较流行且成熟的后端架构。这几年来,K8S、云原生与Service Mesh也比较火热。

去年开始接触到K8S,然后开始学习互联网架构与云原生,前段时间有空在自己的笔记本中搭建开放环境。环境准备如下:

  • DNS服务:阿里云域名服务,解析qinzhiqiang.cn的子域名到本地VM IP
  • 宿主:Windows 10 专业版 + Hyper-V,CPU四核八线程,内存32G,使用Docker CLI
  • VM1:Ubuntu 18.04 Server + Docker,提供Docker daemon、Docker registry服务,内存2G
  • VM2:Ubuntu 18.04 Server + Docker,提供GitLab服务,内存8G
  • VM3:Ubuntu 18.04 Server + Docker,提供K8S服务,内存16G
继续阅读→

Ubuntu中部署Kubernetes (K8s)集群

Kubernetes (K8s)是云原生生态的基石,是CNCF中第一个毕业的项目,是事实上的“云操作系统”标准;后续的分布式微服务都部署在K8s中。

演练K8s集群(CNI + IPVS模式),我们使用3个虚拟机(Ubuntu Server 18.04),需要SSD磁盘作为存储。K8s本身的微服务就不少,磁盘操作次数比普通的单应用服务的多。如果使用普通的机械磁盘,K8s集群的启动都困难。

节点类型 节点名称 IP地址 最小内存
主节点 k8s-master 192.168.80.90 3G
工作点 k8s-worker-1 192.168.80.91 2G
工作点 k8s-worker-2 192.168.80.92 2G
继续阅读→