近期花了比较多的时间研究和学习k8s,陆续写了一些博文。为方便阅读,顺手整理了个索引。希望对大家有所帮助,如有错误之处,烦请指出。一、K8S1.5.2篇1、kubernetes简要介绍——>ylw6006/20662872、kubernetes集群环境准备工作——>ylw6006/20663243、
博客文章太多了,整理个索引吧!将不定期更新,方便自己温故而知新,希望对大家也有帮助!若本索引存在错误之处,烦请各位看官及时指出!10G RAC安装:http://ylw6006.blog.51cto.com/470441/592564 —— 安装前准备http://ylw6006.blog.51cto.com/470441/592816 —— 安装数据集群件http://ylw6006.blog.
背景在某些时候,研发会提出直连pod网段进行debug或者数据台账处理的需求;正常情况下,通过网络拨号可以访问到华为云北京一的容器网段,但由于华为云北京一和华为云北京四的网段是相同的,拨号服务端部署在北京一环境,因此无法直接访问到华为云北京四的容器网段;这个时候,我们可以转换一下思路,通过nginx或者api网关将pod的tcp端口暴露出来,让需求方通过公网进行访问。Nginx传统解决方案cat/
需求背景在完成API网关的一系列部署和配置之后,下一步在系统上需要对应用程序叠加自定义的插件,主要用于认证与鉴权逻辑。Kong社区版本身集成了众多的插件,其中也包括认证相关的oauth2、jwt等插件,但使用的时候需要和kong内部的consumer结合,也就意味着应用系统设计上需要和kong的数据库进行交互。对应用系统而言,早期网关功能由nginx来实现,其认证鉴权的业务逻辑由应用系统自身来实现
在前文中完成了api网关kong、konga面板的部署,在将后端应用发布到网关之后,就需要对应用的日志进行统一管理。由于我们生产环境选择将kong部署进K8S环境,因此选项之后,决定采用http-log插件的方式实现日志的通过收集,将日志发送到logstash服务,对接elasticsearch,最终由kibana面板来展示和查询。添加全局日志插件访问konga面板,添加http-log插件填写l
参考github上的dockerfilehttps://github.com/Kong/docker-kong/tree/master/centos,在dockefile里面添加自定义的内容进行进行编译。本例中在官方的例子上安装了telnet、iproutes等软件包,同时为了实现网关的后续的应用程序认证鉴权,增加了graphql的lua扩展模块准备dockerfileFROMcentos:7LA
前文介绍了在k8s集群内部署API网关kong,在部署完成后,为方便管理kong,通常会再搭配一个面板控制台,本文介绍纯docker方式部署konga面板初始化数据库dockerrun--rmpantsel/konga:latest\-cprepare-apostgres-upostgresql://postgres:123456@192.168.1.14:5432/容器部署dockerrun-i
随着全面微服务化的落地,在网关层上对运维提出的新的要求,经过了几轮测试与验证,最终选型微服务网关kong来替换nginx。本文将简要介绍如何将Kong网关部署在K8S环境中1、下载相关进行并上传harbor私服docker pull kong:2.1 docker pull kong-docker-kubernetes-ingress-controller.bintray.io/kong-ing
### 背景一直以来在内网开发、测试环境的K8S web控制台使用的是rancher面板。通过使用rancher面板服务,在容器管理上运维、开发、测试人员的工作效率得到了极大的提升但由于早期仅注重功能实现及用户体验上问题,忽略了权限管理上的问题。给用户开放出去的rancher面板用户均为cluster-owner权限### 问题由于长期以来忽略权限管理上的问题导致最近一天,突然接到研发人员的通知,
网关是什么,为什么我们需要网关?网关好比我们现实生活中的大门,我们要每天出门上班,下班回家都要通过大门进出在网络世界中网关实际上起着控制流量进出的作用我们平常使用电脑访问互联网,路由器承担了出去流量的网关的工作,在流量到达网关后,网关使用NAT技术完成了源地址转换(可以理解为出门前换了一双鞋子)当客户端流量到达服务端之后,也需要进入服务端的网关进行处理,这个网关通常也叫web反向代理,通常为了提高
背景目前项目在移动端上,首推使用微信小程序。各项目的小程序访问数据有必要进行采集入库,方便后续做统计分析。虽然阿拉丁后台也提供了趋势分析等功能,但在众多的个小程序情况下一个个查找获取数据然后做数据分析也是很痛苦的一件事情。通过将数据转换成sql持久化到数据库上,为后面的数据分析和展示提供了基础。实现思路阿拉丁产品分开放平台和统计平台两个产品线,目前开放平台有api及配套的文档http://doc.
背景一年前,使用了rancherserver导入集群方式纳管了内网的自建的二进制版本K8S集群,rancherserver版本为2.1.7。今日突然接到研发人员反馈,控制台页面无法打开。https://blog.51cto.com/ylw6006/2367448问题分析1、首先通过netstat命令发现端口正常2、通过dockerlogs-francher-server发现日志提示如下。大致可以定
需求背景业务系统将各类的报表和统计数据存放于ES中,由于历史原因,系统每天均以全量方式进行统计,随着时间的推移,ES的数据存储空间压力巨大。同时由于没有规划好es的索引使用,个别索引甚至出现超过最大文档数限制的问题,因此我们需要最小的代价来解决这个问题。下面以内网开发、测试环境举例使用python脚本解决这个问题。EachElasticsearchshardisaLuceneindex.There
一、背景介绍在使用纯手工维护yaml文件方式完成内网开发和两套测试环境和现网生成环境的核心微服务pod化之后。发现主要痛点如下:1、工作负载相关的yaml文件维护量巨大,且易出错。(目前内网共有77个工作负载)2、研发人员对工作负载配置改动的需求比较频繁,例如修改jvm相关参数,增加initcontainer、修改liveness、readiness探针、亲和性与反亲和性配置等,这类的配置严重同质
随着现网生产环境容器化改造逐步完成,核心的业务都由K8S集群中的pod对外提供服务。各个微服务应用间的内部资源调用次数、调用链耗时、调用阈值告警、超时错误等信息指标对保障业务健康运行来说显得非常重要。由于现网使用的是云容器引擎服务,公有云提供了一整套的解决方案。下面是华为云和阿里云相关的产品介绍,总体来说,借助这类的工具,可以快速的查看微服务的各项指标和调用情况,定位相关的问题。https://s
通过将近1个季度的努力,基本上完成了内网开发、测试以及生产环境(借助公有云容器引擎服务)关键服务容器化工作。在这个过程中,本来是把已经验证过的技术和方案进行落地,只是执行上的问题。但是研发大爷在使用过程中又提出了许多新的需求,见招拆招之后,发现还是有些许收货,因此整理成文,本文介绍rancherserver的应用。一、什么是rancher?Rancher是一个开源的企业级容器管理平台,通过使用ra
通过在内网自建K8S环境及使用华为云CCE对现网平台进行一轮容器化改造测试后,积累一些k8s的常见问题和应对方案,整理如下。问题一、POD时间同步问题容器内部时间和node节点的系统时间不一致,这个问题其实不是k8s问题,单纯使用docker也存在类似问题。解决方案,将物理机的时区文件以hostpath方式只读挂载,这样只要保证物理机的系统时间是正确的即可。问题二、POD内部hosts文件问题默认
在K8S环境中(集群环境为自建),node节点上的pod网络互联互通是采用网络插件结合etcd实现的。默认情况下pod访问集群外部的网络(例如:访问百度)走的是对应node节点的nat规则。最近收到研发反馈的需求,由于我们mysql这种公共服务并没有放到k8s集群内(对照生产环境使用的也是RDS这种云服务),所以从mysql的information_schema.processlist这张表查询到
在k8s中,提供相同服务的一组pod可以抽象成一个service,通过service提供的统一入口对外提供服务,每个service都有一个虚拟IP地址(clusterip)和端口号供客户端访问。Kube-proxy存在于各个node节点上,主要用于Service功能的实现,具体来说,就是实现集群内的客户端pod访问service,或者是集群外的主机通过NodePort等方式访问service。ku
在前文介绍的k8smaster高可用实践方案中,需要对kube-apiserver的证书进行更新,加入VIP和从节点的IP,然后重新下发证书。回顾K8S集群整个搭建过程中,最容易让人懵圈的也就是配置证书环节,因此本文对K8S集群所用到的证书进行梳理一下。一、根证书ca.pem根证书公钥文件ca-key.pem根证书私钥文件ca.csr证书签名请求,用于交叉签名或重新签名ca-config.json
本文将在前文基础上介绍k8s集群的高可用实现,一般来讲,k8s集群高可用主要包含以下几个内容:1、etcd集群高可用2、集群dns服务高可用3、Api-server、kube-controller-manager、kube-scheduler等master组件的高可用其中etcd实现的办法较为容易,具体实现办法可参考前文:ylw6006/2095871集
在完成前文的pipeline项目构建和更新之后,本文我们来测试maven项目的构建自动发布。具体环境要求如下:1、docker私有仓库(本例中使用vmware企业级产品harbor)2、jenkins插件PublishOverSSH安装完成3、JenkinsSlavePod中需要有Docker环境(因为poststep1中需要将war文件打包到docker镜像中,因此JenkinsSlave需要有
在完成前文的jenkinsserver在k8s环境部署之后,本文我们来测试在k8s集群环境中的jenkinspipeline构建项目和更新,具体环境要求如下:1、jenkinspipeline插件安装成功2、要更新的应用已提前部署3、Jenkinsslave中需要有kubectl、svn、mvn客户端且环境变量设置准确4、Jenkisslave需要能和master的api-server进行正常通信
本文介绍在k8s环境中进行jenkinsserver的部署和配置。Jenkins是一个开源的、功能强大的持续集成和持续构建工具,采用master和salve架构,我们通过将jenkins集成环境部署在k8s集群中,可以实现jenkinsslave按需创建、动态的伸缩。同时也提供了在k8s环境中应用的持续部署解决方案。一、准备docker镜像文件1、编译jenkinsserverdocker镜像,默
本文介绍mysql8版本下的InnodbCluster配置与测试过程,其核心还是mysql的组复制功能,通过使用mysqlshell简化了组复制的配置过程,同时使用mysqlroute中间件实现了故障的自动转移以及读写分离等功能。之前测试mysql组复制的时候有提出过中间件的问题,mysql-route是个不错的解决方案,前文传送门:ylw6006/19
本文介绍在k8s上部署和使用helm。Helm是Kubernetes的一个包管理工具,用来简化Kubernetes应用的部署和管理。可以把Helm比作CentOS的yum工具。通过使用使用Helm可以管理Kubernetesmanifestfiles、管理Helm安装包charts、基于chart的Kubernetes应用分发。一、Helm的基本概念Chart:是helm的应用打包格式。Chart
前文介绍使用ingress结合traefik实现了入口的动静分离,本文将在前文基础上实现ingress的https配置。为了简单且高效,建议应用容器化部署之后,https卸载在ingress这一级实现。通俗一点来说就是用户到ingress的连接走https协议,ingress到后端服务的连接走https协议。我们对https的配置要求也比较简单,主要如下:1、http自动重定向到https2、ht
今年3月份在公司的内部k8s培训会上,和研发同事详细探讨了应用部署容器化部署的几个问题,问题简要如下:1、java应用容器化部署首先通过自动化部署工具编译出全量的war包,将war包直接编译到docker镜像后推送到私用仓库并版本化控制;其次通过更新deployment的yaml文件来实现部署和后续的滚动更新,应用程序需要进行容器化改造。这里的难点和工作量在于容器的镜像制作以及版本化管理,之后准备
本文介绍使用基于prometheus的自定义metric进行HPA。一般来说,前文介绍的根据CPU和内存做metric进行HPA就已经满足了绝大多数应用场景。现在主流公有云产商的弹性伸缩服务支持的metric类型也较为丰富。以华为云的弹性伸缩服务为例,指标主要涵盖:CPU、内存、网络、磁盘这些资源层面。针对应用级别的就比较少见了,因此本文将介绍基于http请求访问次数的HPA。一、创建pormet
K8S从1.8版本开始,CPU、内存等资源的metrics信息可以通过MetricsAPI来获取,用户可以直接获取这些metrics信息(例如通过执行kubecttop命令),HPA使用这些metics信息来实现动态伸缩。本文介绍K8S集群基于metricserver的HPA。在开始之前我们需要了解一下MetricsAPI和MetricsServer。MetricsAPI:1、通过MetricsA
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号