Jimmy Song's Blog

使用filebeat收集kubernetes中的应用日志

(题图:民生现代美术馆 May 14,2017) 前言 本文已同步更新到Github仓库kubernetes-handbook中。 昨天写了篇文章使用Logstash收集Kubernetes的应用日志,发现logstash十分消耗内存(大约500M),经人提醒改用filebeat(大约消耗10几M内存),因此重写一篇使用filebeat收集kubernetes中的应用日志。 在进行日志收集的过程中,我们首先想到的是使用Logstash,因为它是ELK stack中的重要成员,但是在测试过程中发现,Logstash是基于JDK的,在没有产生日志的情况单纯启动Logstash就大概要消耗500M内存,在每个Pod中都启动一个日志收集组件的情况下,使用logstash有点浪费系统资源,经人推荐我们选择使用Filebeat替代,经测试单独启动Filebeat容器大约会消耗12M内存,比起logstash相当轻量级。 方案选择 Kubernetes官方提供了EFK的日志收集解决方案,但是这种方案并不适合所有的业务场景,它本身就有一些局限性,例如: 所有日志都必须是out前台输出,真实业务场景中无法保证所有日志都在前台输出 只能有一个日志输出文件,而真实业务场景中往往有多个日志输出文件 Fluentd并不是常用的日志收集工具,我们更习惯用logstash,现使用filebeat替代 我们已经有自己的ELK集群且有专人维护,没有必要再在kubernetes上做一个日志收集服务 基于以上几个原因,我们决定使用自己的ELK集群。 Kubernetes集群中的日志收集解决方案 编号 方案 优点 缺点 1 每个app的镜像中都集成日志收集组件 部署方便,kubernetes的yaml文件无须特别配置,可以为每个app自定义日志收集配置 强耦合,不方便应用和日志收集组件升级和维护且会导致镜像过大 2 单独创建一个日志收集组件跟app的容器一起运行在同一个pod中 低耦合,扩展性强,方便维护和升级 需要对kubernetes的yaml文件进行单独配置,略显繁琐 3 将所有的Pod的日志都挂载到宿主机上,每台主机上单独起一个日志收集Pod 完全解耦,性能最高,管理起来最方便 需要统一日志收集规则,目录和输出方式 综合以上优缺点,我们选择使用方案二。 该方案在扩展性、个性化、部署和后期维护方面都能做到均衡,因此选择该方案。 我们创建了自己的logstash镜像。创建过程和使用方式见https://github.com/rootsongjc/docker-images 镜像地址:index.tenxcloud.com/jimmy/filebeat:5.4.0 测试 我们部署一个应用对logstash的日志收集功能进行测试。 创建应用yaml文件fielbeat-test.yaml。 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: filebeat-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: filebeat-test spec: containers: - image: sz-pg-oam-docker-hub-001.

使用Logstash收集Kubernetes的应用日志

(题图:798艺术区 May 14,2017) 前言 本文同步更新到Github仓库kubernetes-handbook中。 很多企业内部都有自己的ElasticSearch集群,我们没有必要在kubernetes集群内部再部署一个,而且这样还难于管理,因此我们考虑在容器里部署logstash收集日志到已有的ElasticSearch集群中。 方案选择 Kubernetes官方提供了EFK的日志收集解决方案,但是这种方案并不适合所有的业务场景,它本身就有一些局限性,例如: 所有日志都必须是out前台输出,真实业务场景中无法保证所有日志都在前台输出 只能有一个日志输出文件,而真实业务场景中往往有多个日志输出文件 Fluentd并不是常用的日志收集工具,我们更习惯用logstash 我们已经有自己的ELK集群且有专人维护,没有必要再在kubernetes上做一个日志收集服务 基于以上几个原因,我们决定使用自己的ELK集群。 Kubernetes集群中的日志收集解决方案 编号 方案 优点 缺点 1 每个app的镜像中都集成日志收集组件 部署方便,kubernetes的yaml文件无须特别配置,可以为每个app自定义日志收集配置 强耦合,不方便应用和日志收集组件升级和维护且会导致镜像过大 2 单独创建一个日志收集组件跟app的容器一起运行在同一个pod中 低耦合,扩展性强,方便维护和升级 需要对kubernetes的yaml文件进行单独配置,略显繁琐 3 将所有的Pod的日志都挂载到宿主机上,每台主机上单独起一个日志收集Pod 完全解耦,性能最高,管理起来最方便 需要统一日志收集规则,目录和输出方式 综合以上优缺点,我们选择使用方案二。 该方案在扩展性、个性化、部署和后期维护方面都能做到均衡,因此选择该方案。 我们创建了自己的logstash镜像。创建过程和使用方式见https://github.com/rootsongjc/docker-images 镜像地址:index.tenxcloud.com/jimmy/logstash:5.3.0 测试 我们部署一个应用对logstash的日志收集功能进行测试。 创建应用yaml文件logstash-test.yaml。 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: logstash-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: logstash-test spec: containers: - image: sz-pg-oam-docker-hub-001.

Kubernete概念解析之Deployment

(题图:京广桥@北京国贸 Apr 30,2017) 前言 本文同步更新到Github仓库kubernetes-handbook中。 本文翻译自kubernetes官方文档:https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md 本文章根据2017年5月10日的Commit 8481c02翻译。 Deployment是Kubernetes中的一个非常重要的概念,从它开始是了解kubernetes中资源概念的一个很好的切入点,看到网上也没什么详细的说明文档,我就随手翻译了一下官方文档(Github中的文档),kubernetes官网上的文档还没有这个新。这篇文章对Deployment的概念解释的面面俱到十分详尽。 Deployment是什么? Deployment为Pod和Replica Set(下一代Replication Controller)提供声明式更新。 你只需要在Deployment中描述你想要的目标状态是什么,Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment。 一个典型的用例如下: 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态,看它是成功还是失败。 然后,通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet,Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。 如果当前状态不稳定,回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。 扩容Deployment以满足更高的负载。 暂停Deployment来应用PodTemplateSpec的多个修复,然后恢复上线。 根据Deployment 的状态判断上线是否hang住了。 清楚旧的不必要的ReplicaSet。 创建Deployment 下面是一个Deployment示例,它创建了一个Replica Set来启动3个nginx pod。 下载示例文件并执行命令: $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record deployment "nginx-deployment" created 将kubectl的 —record 的flag设置为 true可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个Deployment revision中执行了哪些命令。 然后立即执行getí将获得如下结果: $ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 0 0 0 1s 输出结果表明我们希望的repalica数是3(根据deployment中的.spec.replicas配置)当前replica数( .status.replicas)是0, 最新的replica数(.status.updatedReplicas)是0,可用的replica数(.status.availableReplicas)是0。

Kubernetes中的Rolling Update服务滚动升级

(题图:后海夜色 Apr 30,2017) 前言 本文已同步到gitbook kubernetes-handbook的第8章第1节。 本文说明在Kubernetes1.6中服务如何滚动升级,并对其进行测试。 当有镜像发布新版本,新版本服务上线时如何实现服务的滚动和平滑升级? 如果你使用ReplicationController创建的pod可以使用kubectl rollingupdate命令滚动升级,如果使用的是Deployment创建的Pod可以直接修改yaml文件后执行kubectl apply即可。 Deployment已经内置了RollingUpdate strategy,因此不用再调用kubectl rollingupdate命令,升级的过程是先创建新版的pod将流量导入到新pod上后销毁原来的旧的pod。 Rolling Update适用于Deployment、Replication Controller,官方推荐使用Deployment而不再使用Replication Controller。 使用ReplicationController时的滚动升级请参考官网说明:https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ ReplicationController与Deployment的关系 ReplicationController和Deployment的RollingUpdate命令有些不同,但是实现的机制是一样的,关于这两个kind的关系我引用了ReplicationController与Deployment的区别中的部分内容如下,详细区别请查看原文。 ReplicationController Replication Controller为Kubernetes的一个核心内容,应用托管到Kubernetes之后,需要保证应用能够持续的运行,Replication Controller就是这个保证的key,主要的功能如下: 确保pod数量:它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod,Replication Controller会创建新的,反之则会删除掉多余的以保证Pod数量不变。 确保pod健康:当pod不健康,运行出错或者无法提供服务时,Replication Controller也会杀死不健康的pod,重新创建新的。 弹性伸缩 :在业务高峰或者低峰期的时候,可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时,配置相应的监控功能(Hroizontal Pod Autoscaler),会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况,做到自动伸缩。 滚动升级:滚动升级为一种平滑的升级方式,通过逐步替换的策略,保证整体系统的稳定,在初始化升级的时候就可以及时发现和解决问题,避免问题不断扩大。 Deployment Deployment同样为Kubernetes的一个核心内容,主要职责同样是为了保证pod的数量和健康,90%的功能与Replication Controller完全一样,可以看做新一代的Replication Controller。但是,它又具备了Replication Controller之外的新特性: Replication Controller全部功能:Deployment继承了上面描述的Replication Controller全部功能。 事件和状态查看:可以查看Deployment的升级详细进度和状态。 回滚:当升级pod镜像或者相关参数的时候发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。 版本记录: 每一次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。 暂停和启动:对于每一次升级,都能够随时暂停和启动。 多种升级方案:Recreate:删除所有已存在的pod,重新创建新的; RollingUpdate:滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。 创建测试镜像 我们来创建一个特别简单的web服务,当你访问网页时,将输出一句版本信息。通过区分这句版本信息输出我们就可以断定升级是否完成。 所有配置和代码见Github上的manifests/test/rolling-update-test目录。 Web服务的代码main.go package main import ( "fmt" "log" "net/http" ) func sayhello(w http.

Kubernetes的边缘节点配置

(题图:南屏晚钟@圆明园 May 6,2017) 前言 为了配置kubernetes中的traefik ingress的高可用,对于kubernetes集群以外只暴露一个访问入口,需要使用keepalived排除单点问题。本文参考了kube-keepalived-vip,但并没有使用容器方式安装,而是直接在node节点上安装。 本文已同步到gitbook kubernetes-handbook的第2章第5节。 定义 首先解释下什么叫边缘节点(Edge Node),所谓的边缘节点即集群内部用来向集群外暴露服务能力的节点,集群外部的服务通过该节点来调用集群内部的服务,边缘节点是集群内外交流的一个Endpoint。 边缘节点要考虑两个问题 边缘节点的高可用,不能有单点故障,否则整个kubernetes集群将不可用 对外的一致暴露端口,即只能有一个外网访问IP和端口 架构 为了满足边缘节点的以上需求,我们使用keepalived来实现。 在Kubernetes集群外部配置nginx来访问边缘节点的VIP。 选择Kubernetes的三个node作为边缘节点,并安装keepalived。 准备 复用kubernetes测试集群的三台主机。 172.20.0.113 172.20.0.114 172.20.0.115 安装 使用keepalived管理VIP,VIP是使用IPVS创建的,IPVS已经成为linux内核的模块,不需要安装 LVS的工作原理请参考:http://www.cnblogs.com/codebean/archive/2011/07/25/2116043.html 不使用镜像方式安装了,直接手动安装,指定三个节点为边缘节点(Edge node)。 因为我们的测试集群一共只有三个node,所有在在三个node上都要安装keepalived和ipvsadmin。 yum install keepalived ipvsadm 配置说明 需要对原先的traefik ingress进行改造,从以Deployment方式启动改成DeamonSet。还需要指定一个与node在同一网段的IP地址作为VIP,我们指定成172.20.0.119,配置keepalived前需要先保证这个IP没有被分配。。 Traefik以DaemonSet的方式启动 通过nodeSelector选择边缘节点 通过hostPort暴露端口 当前VIP漂移到了172.20.0.115上 Traefik根据访问的host和path配置,将流量转发到相应的service上 配置keepalived 参考基于keepalived 实现VIP转移,lvs,nginx的高可用,配置keepalived。 keepalived的官方配置文档见:http://keepalived.org/pdf/UserGuide.pdf 配置文件/etc/keepalived/keepalived.conf文件内容如下: ! Configuration File for keepalived global_defs { notification_email { root@localhost } notification_email_from kaadmin@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.

在kubernetes中使用glusterfs做持久化存储

(题图:无题@北京奥林匹克森林公园 May 1,2017) 前言 本文章已同步到kubernetes-handbook 7.1章节。 Kubernetes集群沿用跟我一起部署kubernetes1.6集群中的三台机器。 我们复用kubernetes集群的这三台主机做glusterfs存储。 以下步骤参考自:https://www.xf80.com/2017/04/21/kubernetes-glusterfs/ 安装glusterfs 我们直接在物理机上使用yum安装,如果你选择在kubernetes上安装,请参考:https://github.com/gluster/gluster-kubernetes/blob/master/docs/setup-guide.md # 先安装 gluster 源 $ yum install centos-release-gluster -y # 安装 glusterfs 组件 $ yum install -y glusterfs glusterfs-server glusterfs-fuse glusterfs-rdma glusterfs-geo-replication glusterfs-devel ## 创建 glusterfs 目录 $ mkdir /opt/glusterd ## 修改 glusterd 目录 $ sed -i 's/var\/lib/opt/g' /etc/glusterfs/glusterd.vol # 启动 glusterfs $ systemctl start glusterd.service # 设置开机启动 $ systemctl enable glusterd.service #查看状态 $ systemctl status glusterd.service 配置 glusterfs # 配置 hosts $ vi /etc/hosts 172.

Kubernetes网络和集群性能测试

(题图:无题@安贞门 Jun 18,2016) 前言 该测试是为了测试在不同的场景下,访问kubernetes的延迟以及kubernetes的性能。进行以下测试前,你需要有一个部署好的kubernetes集群,关于如何部署kuberentes1.6集群,请参考kubernetes-handbook。 准备 测试环境 在以下几种环境下进行测试: Kubernetes集群node节点上通过Cluster IP方式访问 Kubernetes集群内部通过service访问 Kubernetes集群外部通过traefik ingress暴露的地址访问 测试地址 Cluster IP: 10.254.149.31 Service Port:8000 Ingress Host:traefik.sample-webapp.io 测试工具 Locust:一个简单易用的用户负载测试工具,用来测试web或其他系统能够同时处理的并发用户数。 curl kubemark 测试程序:sample-webapp,源码见Github kubernetes的分布式负载测试 测试说明 通过向sample-webapp发送curl请求获取响应时间,直接curl后的结果为: $ curl "http://10.254.149.31:8000/" Welcome to the "Distributed Load Testing Using Kubernetes" sample web app 网络延迟测试 场景一、 Kubernetes集群node节点上通过Cluster IP访问 测试命令 curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{time_total}' "http://10.254.149.31:8000/" 10组测试结果 No time_connect time_starttransfer time_total 1 0.

运用kubernetes进行分布式负载测试

(题图:Kubrick Book Store Mar 25,2016) 前言 Github地址https://github.com/rootsongjc/distributed-load-testing-using-kubernetes 该教程描述如何在Kubernetes中进行分布式负载均衡测试,包括一个web应用、docker镜像和Kubernetes controllers/services。更多资料请查看Distributed Load Testing Using Kubernetes 。 注意:该测试是在我自己本地搭建的kubernetes集群上测试的,不需要使用Google Cloud Platform。 准备 不需要GCE及其他组件,你只需要有一个kubernetes集群即可。 如果你还没有kubernetes集群,可以参考kubernetes-handbook部署一个。 部署Web应用 sample-webapp 目录下包含一个简单的web测试应用。我们将其构建为docker镜像,在kubernetes中运行。你可以自己构建,也可以直接用这个我构建好的镜像index.tenxcloud.com/jimmy/k8s-sample-webapp:latest。 在kubernetes上部署sample-webapp。 $ cd kubernetes-config $ kubectl create -f sample-webapp-controller.yaml $ kubectl create -f kubectl create -f sample-webapp-service.yaml 部署Locust的Controller和Service locust-master和locust-work使用同样的docker镜像,修改cotnroller中spec.template.spec.containers.env字段中的value为你sample-webapp service的名字。 - name: TARGET_HOST value: http://sample-webapp:8000 创建Controller Docker镜像(可选) locust-master和locust-work controller使用的都是locust-tasks docker镜像。你可以直接下载gcr.io/cloud-solutions-http://olz1di9xf.bkt.clouddn.com/locust-tasks,也可以自己编译。自己编译大概要花几分钟时间,镜像大小为820M。 $ docker build -t index.tenxcloud.com/jimmy/locust-tasks:latest . $ docker push index.tenxcloud.com/jimmy/locust-tasks:latest 注意:我使用的是时速云的镜像仓库。 每个controller的yaml的spec.template.spec.containers.image 字段指定的是我的镜像:

Kubernetes中的IP和服务发现体系

(题图:路边的野花@朝阳公园 Nov 8,2015) Cluster IP 即Service的IP,通常在集群内部使用Service Name来访问服务,用户不需要知道该IP地址,kubedns会自动根据service name解析到服务的IP地址,将流量分发给Pod。 Service Name才是对外暴露服务的关键。 在kubeapi的配置中指定该地址范围。 默认配置 --service-cluster-ip-range=10.254.0.0/16 --service-node-port-range=30000-32767 Pod IP 通过配置flannel的network和subnet来实现。 默认配置 FLANNEL_NETWORK=172.30.0.0/16 FLANNEL_SUBNET=172.30.46.1/24 Pod的IP地址不固定,当pod重启时IP地址会变化。 该IP地址也是用户无需关心的。 但是Flannel会在本地生成相应IP段的虚拟网卡,为了防止和集群中的其他IP地址冲突,需要规划IP段。 主机/Node IP 物理机的IP地址,即kubernetes管理的物理机的IP地址。 $ kubectl get nodes NAME STATUS AGE VERSION 172.20.0.113 Ready 12d v1.6.0 172.20.0.114 Ready 12d v1.6.0 172.20.0.115 Ready 12d v1.6.0 服务发现 集群内部的服务发现 通过DNS即可发现,kubends是kubernetes的一个插件,不同服务之间可以直接使用service name访问。 通过sericename:port即可调用服务。 服务外部的服务发现 通过Ingress来实现,我们是用的Traefik来实现。 参考 Ingress解析 Kubernetes Traefik Ingress安装试用

Kubernetes中的RBAC支持

(题图:无题 Apr 2,2016) 在Kubernetes1.6版本中新增角色访问控制机制(Role-Based Access,RBAC)让集群管理员可以针对特定使用者或服务账号的角色,进行更精确的资源访问控制。在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。 前言 本文翻译自RBAC Support in Kubernetes,转载自kubernetes中文社区,译者催总,Jimmy Song做了稍许修改。该文章是5天内了解Kubernetes1.6新特性的系列文章之一。 One of the highlights of the Kubernetes 1.6中的一个亮点时RBAC访问控制机制升级到了beta版本。RBAC,基于角色的访问控制机制,是用来管理kubernetes集群中资源访问权限的机制。使用RBAC可以很方便的更新访问授权策略而不用重启集群。 本文主要关注新特性和最佳实践。 RBAC vs ABAC 目前kubernetes中已经有一系列l 鉴权机制。鉴权的作用是,决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外,还会对一些运行在集群内部并对集群进行操作的软件产生作用,例如使用了 Kubernetes 插件的 Jenkins,或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。 ABAC(Attribute Based Access Control)本来是不错的概念,但是在 Kubernetes 中的实现比较难于管理和理解,而且需要对 Master 所在节点的 SSH 和文件系统权限,而且要使得对授权的变更成功生效,还需要重新启动 API Server。 而 RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户,让用户有权进行授权管理,这样就可以无需接触节点,直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和操作。 因为 Kubernetes 社区的投入和偏好,相对于 ABAC 而言,RBAC 是更好的选择。