Traefik

注意 本文，只是笔者针对Kubernetes生产环境运行的一些关于架构设计和实现方案的总结，内容很粗糙，后续会不断完善。 首先，我们来梳理下Kubernetes生产架构，其设计适用于绝大多数环境，如下图所示 在该架构中，我们可以将其分为四层，如下： Client层：即Kubernetes集群外部用户、客户端等； 服务访问层：即由Traefik ingress实现服务发现、负载均衡和路由规则定义等； 业务应用层：即基于Kubernetes平台构建和运行企业业务应用，如CI/CD持续集成、微服务项目、监控告警和日志管理、私有镜像仓库等服务； 基础设施层：即由Kubernetes容器管理平台和Ceph/NFS数据持久化存储等系统组成的基础设施服务。 下面，我们分别来谈谈各层的具体实现方案。 基础设施层 Kubernetes平台 部署管理：Kubernetes平台除了直接使用公有云如阿里云、AWS等云服务提供商的K8s服务外，我们还可以自己部署和管理等，如使用Kubespray工具。 网络通信：在容器和容器之间、容器和主机网络方面，可以使用 Calico 或Flannel等方案。 HA高可用：Kubernetes节点分为Master和Node两种类型节点，前者负责运行集群相关的控制管理服务，而后者负责运行Pod容器。在多Node节点模式下，由于Kubernetes

Ingress 英文翻译 进入;进入权;进食 ，更准确的讲就是 入口 ，即外部流量进入 k8s 集群必经之口。这道大门到底有什么作用？我们如何使用 Ingress ？ k8s 又是如何进行服务发现的呢？先看一张图： 原理 虽然 k8s 集群内部署的 pod 、 server 都有自己的 IP ，但是却无法提供外网访问，以前我们可以通过监听 NodePort 的方式暴露服务，但是这种方式并不灵活，生产环境也不建议使用。 Ingresss 是 k8s 集群中的一个 API 资源对象，扮演边缘路由器(edge router)的角色，也可以理解为 集群防火墙 、 集群网关 ，我们可以 自定义路由规则 来转发、管理、暴露服务(一组pod)，非常灵活，生产环境建议使用这种方式。另外 LoadBlancer 也可以暴露服务，不过这种方式需要向云平台申请负债均衡器；虽然目前很多云平台都支持，但是这种方式深度耦合了云平台，所以你懂的。 首先我们来思考用传统的 web 服务器，比如 Nginx ，如何处理这种场景？ Nginx 充当一个反向代理服务器拦截外部请求，读取路由规则配置，转发相应的请求到后端服务。 kubernetes 处理这种场景时，涉及到三个组件 ： 反向代理 web 服务器 负责拦截外部请求，比如 Nginx 、 Apache 、 traefik 等等。我一般以 Deployment

1、说明 对于Kubernetes的service，无论是cluster-ip和nodeport均是四层的负载，集群内的服务如何实现七层的负载均衡，这就需要借助于ingress，ingress控制器实现的方式有很多，比如nginx,contour,haproxy,trafik,lstio。几种常用的ingress功能对比和选型可以参考这里www.kubernetes.org.cn/5948.html ingress-nginx是七层的负载均衡器，负责统一管理外部对k8s cluster中的service的请求。主要包含 ingress-nginx-controller：要据用户编写的ingress规则（创建的Ingress的yaml文件），动态的去更改服务的配置文件，并且reload重载使其生效（是自动化的，通过Lua脚本来实现）； ingress资源对像：将Nginx的配置抽像成一个Ingress对像 Ingress是K8S的标准资源类型之一，也是一种核心资源，它其实就是一种基于域名和URL路径，把用户的请求转发至指定Service资源的规则 可以将集群外部的请求流量，转发至集群内部，从而实现“服务暴露” Ingre控制器是能够为Ingress资源监听某套接字，然后根扰Ingress规则匹配机制路由调度流量的一个组件 参考链接： https://github.com

前言 拥抱开源，无私分享，共享技术，相互学习，共同进步，分享更多有深度的文章，欢迎转发分享 四层负载均衡器service回顾 使用四层负载均衡调度器service时，当客户端访问kubernetes集群内部的应用时，数据包走向如下面流程所示 client--->nodeip:port--->service ip:port--->podip:port 客户端-->node节点的ip:端口--->service的ip:端口--->pod的ip:端口 1.Ingress Controller Ingress Controller是一个七层负载均衡调度器，客户端的请求先到达这个七层负载均衡调度器，由七层负载均衡器在反向代理到后端pod，常见的七层负载均衡器有nginx，traefik等，以我们熟悉的nginx为例，假如请求到达nginx，会通过upstream反向代理到后端pod，但是后端pod的ip地址是一直在变化的，因此在后端pod前需要加一个service，这个service只是起到分组的作用，那么我们upstream只需要填写service地址即可 nginx：需要手动加载配置文件 traefik：定期自动加载配置文件，不需要手动干预，在微服务中几乎都会使用这种调度器 2.Ingress 官方： https://kubernetes.io/docs/concepts

简介： 在正常生产环境中使用k8s部署业务后能正常运行还不够，我们需要很多附加的东西来满足日常的需求。比如日志、监控、告警等。这一篇给大家分享一下我们生产环境中的日志集中解决方案。当然不敢说是最好的，分享出来供大家参考。 在正常环境中有几类日志我们比较关心： 1、k8s中的ingress日志。比如traefik，里面记录的从公网域名访问进来的访问记录，类似nginx的access.log 2、istio中envoy边车日志。如果启用了istio那么这个日志也是需要的，每次程序被调用时都会有一个记录。 3、k8s中的事件日志。里面就有容器健康检查失败重新部署，或者pod新建、删除等事件。kubectl describe pods中的Events:内容 4、业务程序运行时产生的业务日志。比如java中常用的log4j套件输出的日志和kubectl logs命令查看的日志。这个和输出方式有关。 实现方式 这里日志收集的方式是采用elk模式，如果大家感兴趣还有loki的模式。当然这次分享是基于elk的。首先要部署的还是es集群，这里我们使用的是虚拟机部署方式非容器化。理由es是公共的组件可以对接所有的产品业务线，单独拿出来部署可以给别的产品线输出集中化日志存储方案。平时维护量还是比较少的，当然我们的es集群每15分钟大概800万条记录规模并不是特别大， 不过以后出现瓶颈横向扩容也不是问题