精华内容
下载资源
问答
  • traefik-consul-test:临时演示资料库,以帮助合并traefik#7407
  • <div><p>This will make it way easier to remove Ansible from edge nodes</p><p>该提问来源于开源项目:mantl/mantl</p></div>
  • Traefik dropping nodes?

    2020-12-25 23:25:26
    allLabelsmap[:map[traefik.frontend.auth.basic.users:admin:$apr1$urYfOtau$Gjbmr1.qKmCYudUKbC/Za/ traefik.frontend.rule:Host:consul.eye.middle-earth.io traefik.docker.network:traefik-public traefik....
  • Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, ...) and configures itself automatically and dynamically. ...
  • 计划的技术: Terraform,Consul,Nomad,Vault,Linkerd,Jaeger,Traefik,Hashi-UI,Vault-UI,Prometheus,BedrockDB,LXD,ZFS,Drone.io,Powershell。 注意:此刻仅适用于开发环境,直到我了解更多Terraform...
  • Traefik简介

    2020-03-25 19:10:44
    它可以支持多种后端 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。 本文为个人在学习Traefik的过程中,对Traefik...

    Traefik是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它可以支持多种后端 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。

    概览

    让我们通过Traefik的架构图,来了解下Traefik中的几个核心的组件。
    在这里插入图片描述
    从上述架构图中,我们可以看到进入到Traefik的请求会经过以下路径到达最终的服务端:

    Requests -》Entrypoints -》Routers(Rules,Middlewares)-》Services -》Server

    EntryPoints:是请求进入Traefik的网络入口。Traefik通过EntryPoints定义了一些端口来接收请求,比如HTTP,TCP等。
    Routers:职责是连接进入Traefik的请求和最终处理这些请求的服务。在这个过程中,Router有可能会使用一些middleware去对这些请求作出更新。
    Services:职责在于配置如何让Routers将这些请求转发到最终处理这些请求的后端服务上。

    Traefik在K8S上的使用体验

    部署

    为了测试方便,本文使用helm进行traefik的安装,在执行以下命令前,请确保你已经有一个可以正常工作的Kubernetes集群,并已经安装了helm v3版本。
    通过以下三条命令就可以将traefik安装到你的K8S集群上:

    $ helm repo add traefik https://containous.github.io/traefik-helm-chart
    $ helm repo update
    $ helm install traefik traefik/traefik
    

    Traefik CRD

    Traefik v2版本通过Kubernetes提供的CRD定义了以下核心的资源对象:

    • IngressRoute 和 IngressRouteTCP
    • MiddleWare
    • TraefikService
    • TLSOption

    其中IngressRoute和IngressRouteTCP是Traefik最重要的CRD资源,它将Traefik中所有核心的概念关联到一起,最终实现了请求的中间处理,并最终转发到具体的服务。

    以下为在K8S上定义一个IngressRoute的yaml配置文件,仅供参考。

    apiVersion: traefik.containo.us/v1alpha1
    kind: IngressRoute
    metadata:
      name: ingressroutefoo
    spec:
      entryPoints:
        - web
      routes:
      # Match is the rule corresponding to an underlying router.
      # Later on, match could be the simple form of a path prefix, e.g. just "/bar",
      # but for now we only support a traefik style matching rule.
      - match: Host(`foo.com`) && PathPrefix(`/bar`)
        # kind could eventually be one of "Rule", "Path", "Host", "Method", "Header",
        # "Parameter", etc, to support simpler forms of rule matching, but for now we
        # only support "Rule".
        kind: Rule
        # (optional) Priority disambiguates rules of the same length, for route matching.
        priority: 12
        services:
        - name: whoami
          port: 80
          # (default 1) A weight used by the weighted round-robin strategy (WRR).  
          weight: 1
          # (default true) PassHostHeader controls whether to leave the request's Host
          # Header as it was before it reached the proxy, or whether to let the proxy set it
          # to the destination (backend) host.
          passHostHeader: true
          responseForwarding:
            # (default 100ms) Interval between flushes of the buffered response body to the client.
            flushInterval: 100ms
    ---
    apiVersion: traefik.containo.us/v1alpha1
    kind: IngressRouteTCP
    metadata:
      name: ingressroutetcpfoo.crd
    spec:
      entryPoints:
        - footcp
      routes:
      # Match is the rule corresponding to an underlying router.
      - match: HostSNI(`*`)
        services:
        - name: whoamitcp
          port: 8080
    

    除此之外,Traefik v2也提供了丰富的MiddleWares,通过CRD在K8S上定义和使用MiddleWares的方式如下所示:

    apiVersion: traefik.containo.us/v1alpha1
    kind: Middleware
    metadata:
      name: stripprefix
    spec:
      stripPrefix:
        prefixes:
          - /stripit
    ---
    apiVersion: traefik.containo.us/v1alpha1
    kind: IngressRoute
    metadata:
      name: ingressroute
    spec:
    # more fields...
      routes:
        # more fields...
        middlewares:
          - name: stripprefix
    

    Traefik v2当前支持的插件如下表所示:
    在这里插入图片描述

    总结

    以上仅为本人对前期调研和使用Traefik的一点粗浅的理解,如有不当之处,请不吝赐教。

    展开全文
  • traefik简介

    2017-01-17 23:07:35
    traefik(https://traefik.io/)是一款开源的反向代理与负载均衡...目前支持Docker, Swarm, Mesos/Marathon, Mesos, Kubernetes, Consul, Etcd, Zookeeper, BoltDB, Rest API等等后端模型。 traefik的具体模型如下...

    traefik(https://traefik.io/)是一款开源的反向代理与负载均衡工具。它最大的优点是能够与常见的微服务系统直接整合,可以实现自动化动态配置。目前支持Docker, Swarm, Mesos/Marathon, Mesos, Kubernetes, Consul, Etcd, Zookeeper, BoltDB, Rest API等等后端模型。

    traefik的具体模型如下:

    为什么选择traefik?

    事实上在之前我对LB的选择一直更倾向于使用 HAProxy 。但是选择traefik主要是有以下特点让我们决定使用:

    • Golang编写,单文件部署,与系统无关,同时也提供小尺寸Docker镜像。
    • 支持Docker/Etcd后端,天然连接我们的微服务集群。
    • 内置Web UI,管理相对方便。
    • 自动配置ACME(Let's Encrypt)证书功能。
    • 性能尚可,我们也没有到压榨LB性能的阶段,易用性更重要。

    除了这些以外,traefik还有以下特点:

    • Restful API支持。
    • 支持后端健康状态检查,根据状态自动配置。
    • 支持动态加载配置文件和graceful重启。
    • 支持WebSocket和HTTP/2。

    除了上面提到的微服务化集群支持,一些AB测试阶段也可以通过frontend的路由特性进行动态分配,当然这些对HAProxy等软件都是标准支持的。

    traefik的配置

    traefik支持的配置方式支持文件方式进行配置,这个也是比较常见的配置方式,我们这里简单介绍一下。

    traefik支持的toml方式进行配置,官方提供了一个 示例的traefik.toml文件 用于演示配置。除此之外,后端服务一般是采用单独文件进行存储,比如演示配置中指定的rules.toml。

    具体一个例子,如果我们有两个后端,127.0.0.1:7727,127.0.0.1:7728,我们希望所有的Chrome用户都可以访问127.0.0.1:7727,其它人都访问127.0.0.1:7728,这样这个rules.toml应该如何配置呢?

    # rules.toml
    [backends]
      [backends.backend1]
        [backends.backend1.servers.server1]
        url = "http://127.0.0.1:7727"
      [backends.backend2]
        [backends.backend2.servers.server1]
        url = "http://127.0.0.1:7728"
    
    
    [frontends]
      [frontends.frontend1]
      entrypoints = ["http"]
      backend = "backend1"
        [frontends.frontend1.routes.test_1]
        rule = "HeadersRegexp: User-Agent, Chrome"
      [frontends.frontend2]
      entrypoints = ["http"]
      backend = "backend2"

    首先定义两个后端服务,每个后端服务可以支持多个服务单元,这里我们只有一个。前端frontends用于匹配请求落到哪个后端服务中。我们这里定义一个规则test_1,设置规则为根据HTTP请求头部正则进行分配:如果UserAgent中包含Chrome字样,则访问到127.0.0.1:7727。匹配的规则方式包含了以下几种方式:

    • Headers / HeaderRegexp : 头部匹配方式,分别对应按值和正则表达式两种方式。
    • Host / HostRegexp : 按照请求主机名进行匹配,与头部信息相似。
    • Method : 按照请求方式区分。
    • Path / PathStrip / PathPrefix / PathPrefixStrip : 按照路径区分后端。

    traefik与微服务集群

    这个有人已经写过相关的文章了,我在这里简单推荐一下: Microservices Bliss with Docker and Traefik ( 中文译文 )。我就不做额外的描述了。

     

    http://www.tuicool.com/articles/ZnuEfay

    展开全文
  • f consul-values.yml hashicorp hashicorp/consul 要咨询成员并检查各个节点,Consul建议先exec进入其中一个容器,然后使用CLI工具consul。要提供Consul提供的现成的Web UI,请运行kubectl port-forward service/...

    在讨论微服务架构和容器化时,一组经过生产验证的工具近年来引起了很大关注:服务网格。

    确实,微服务架构和Kubernetes(通常是K8S)已迅速成为可伸缩应用程序的规范,这使得管理服务之间的通信问题成为热门话题,并且服务网格成为一种有吸引力的解决方案。我本人在生产中使用了服务网格,特别是Linkerd,Istio和早期的Ambassador形式。但是,服务网格的作用到底是什么?最好使用哪一个?您怎么知道是否应该使用那一个?

    要回答这些问题,有助于理解为什么开发服务网格。从历史上看,传统的IT基础架构具有作为整体运行的应用程序。一种服务在一台服务器上运行;如果需要更多容量,解决方案是通过配置更大的机器来垂直扩展它。

    由于达到了这种方法的局限性,大型科技公司迅速采用了三层架构,将负载均衡器与应用程序服务器和数据库层分开。尽管该体系结构仍具有一定的可伸缩性,但他们决定将应用程序层分解为微服务。为了扩展应用程序,这些服务之间的通信对于监控和保护变得至关重要。

    为了允许服务间通信,这些公司开发了内部库:Twitter上的Finagle,Netflix上的Hystrix和Google上的Stubby(于2016年成为gRPC)。这些库旨在解决微服务架构引起的问题:服务之间的安全性,延迟,监控和负载均衡。但是,将大型库作为多种语言作为依赖项进行管理是复杂且耗时的。

    最后,该类型的库被更易于使用的轻量级代理所替代。此类代理在外部独立于应用程序层(对于应用程序可能是透明的),并且更易于更新、维护和部署。这样,服务网格就诞生了。

    什么是服务网格?

    服务网格是用于控制服务之间的通信的软件基础结构层。它通常由两个部分组成:

    • 在数据平面,它处理应用程序近通信。如前所述,通常将其与应用程序一起部署为一组网络代理。

    • 在控制平面,这是服务网的“大脑”。控制平面与代理交互以推送配置,确保服务发现并集中可观察性。

    服务网格围绕服务间通信具有三个主要目标:

    • 连接性

    • 安全

    • 可观察性

    连接性

    服务网格体系结构的这一方面允许服务发现和动态路由。它还涵盖了通信弹性,例如重试、超时、中断和速率限制。

    服务网格的主要特征是负载平衡。通过代理划分网格的所有服务都允许在服务之间实施负载平衡策略,例如轮询,随机请求和最少请求。这些策略是服务网格用来决定哪个副本将接收原始请求的策略,就像您在每个服务前面都装有很小的负载平衡器一样。

    最后,服务网格以流量转移和镜像的形式提供路由控制。

    安全

    在传统的微服务体系结构中,服务之间使用未加密的流量进行通信。如今,就安全性而言,未加密的内部流量被认为是一种不良做法,尤其是对于公有云基础架构和零信任网络而言。

    除了在无法直接控制硬件的情况下保护客户端数据的私密性之外,对内部流量进行加密还会在系统出现漏洞的情况下增加一层额外的复杂性。因此,所有服务网格都使用相互TLS(mTLS)加密进行服务间通信,即所有代理间通信。

    服务网格甚至可以强制执行复杂的授权策略矩阵,基于针对特定环境和服务的策略允许或拒绝流量。

    可观察性

    服务网格的目标是使服务间通信具有可见性。通过控制网络,服务网格可增强可观察性,提供七层度量,从而在流量达到某些可自定义阈值时自动发出警报。

    通常由第三方工具或Jaeger或Zipkin之类的插件支持,此类控件还允许通过注入HTTP头进行注入跟踪。

    服务网格的好处

    创建服务网格是为了抵消微服务体系结构所带来的一些运营负担。那些具有微服务架构经验的人知道,他们每天需要花费大量的工作来进行操作。要充分利用微服务的潜力,通常需要外部工具来处理集中式日志记录,配置管理和可伸缩性机制等。使用服务网格可标准化这些功能及其设置和集成。

    尤其是服务网格的可观察性,提供了极其通用的调试和优化方法。借助对服务之间的交换的详尽而完整的可见性,工程师(尤其是SRE)可以更快地解决可能的错误和系统配置错误。借助服务网格跟踪,他们可以跟踪从请求进入系统(在负载平衡器或外部代理处)到堆栈内部私有服务的请求。他们可以使用日志记录来映射请求并记录每个服务中遇到的延迟。最终深入了解系统性能指标。

    流量管理提供了强大的可能性,然后才能逐步发布服务的新版本:

    • 重新路由少量请求。

    • 更好的是,将生产请求到镜像新版本以通过实时流量测试其行为。

    • A / B测试任何服务或服务组合。

    服务网格简化了上述所有场景,从而更容易避免或减轻生产中的任何意外情况。

    Kubernetes服务网格比较

    在许多方面,服务网格是微服务体系结构的终极工具集。他们中的许多人都在顶级容器编排工具之一Kubernetes上运行。我们选择了当今在Kubernetes上运行的三个主要服务网格:Linkerd(v2),Istio和Consul Connect。我们还将讨论其他一些服务网格:Kuma,Traefik Mesh和AWS App Mesh。尽管目前在使用和社区方面不那么突出,但他们有足够的希望在这里进行评论并保持常规状态。

    关于Sidecar代理的快速说明

    并非所有的Kubernetes服务网格都采用相同的架构,但是一种常见的方法是利用sidecar模式。这涉及将代理(sidecar)附加到主应用程序,以拦截和管理应用程序的入站和出站网络流量。实际上,这是在Kubernetes中通过每个应用程序容器中的辅助容器完成的,该容器将遵循应用程序容器的生命周期。

    服务网格的sidecar方法有两个主要优点:

    • Sidecar代理与运行时甚至应用程序的编程语言无关。这意味着很容易在整个堆栈中启用要使用的服务网格的所有功能。

    • Sidecar具有与应用程序相同级别的权限和对资源的访问。Sidecar可以帮助监控主应用程序使用的资源,而无需将监控集成到主应用程序代码库中。

    但是,Sidecar是好运参半,因为它们的行为将直接影响应用程序:

    • Sidecar初始化可能会锁死应用程序的启动。

    • Sidecar代理会在您的应用程序顶部增加潜在的延迟。

    • Sidecar代理还会增加资源占用量,这可能会花费大量资金。

    鉴于这些优点和缺点,在服务网格社区中,sidecar方法经常成为争论的主题。也就是说,这里比较的六个服务网格中的四个使用Envoy Sidecar代理,而Linkerd使用其自己的Sidecar实现。Traefik Mesh在其设计中不使用边车。

    Linkerd

    Linkerd于2017年首次亮相,是市场上最古老的服务网格。Linkerd v1由Buoyant(由两名前Twitter工程师创立的公司)创建,它基于Finagle和Netty。

    由于Linkerd v1是一个完整的,可立即投入生产的服务网格,因此被描述为领先于时代。同时,在资源使用方面有点繁重。同样,文档方面的巨大差距也使得在生产中难以设置和运行。

    这样,Buoyant就有机会使用完整的生产模型,从中获得经验,并运用这种智慧。结果就是Conduit,这是Linkerd的完整重写,于2018年发布,并于当年晚些时候重命名了Linkerd v2。Linkerd v2带来了一些引人注目的改进。由于Buoyant很早就停止了对Linkerd v1的积极开发,因此本文其余部分中对Linkerd的提及均指v2。

    Linkerd是完全开源的,它用Rust编写的自制代理作为数据平面,而控制平面依赖于Go编写。

    连接性

    Linkerd代理具有重试和超时功能,但在撰写本文时,没有中断或延迟注入。入口支持广泛;Linkerd拥有与以下入口控制器的集成:

    • Traefik

    • Nginx

    • GCE

    • Ambassador

    • Gloo

    • Contour

    • Kong

    Linkerd中的服务配置文件提供增强的路由功能,为每个路由提供用户指标,重试调整和超时设置。至于负载均衡,Linkerd提供自动代理注入,其自己的仪表板以及对Grafana的本地支持。

    安全

    Linkerd中的mTLS支持非常方便,因为它的初始设置是自动的,并且它的每日自动密钥轮换也是自动的。

    可观察性

    开箱即用,可通过CLI观察Linkerd的统计信息和路由。在GUI方面,选项包括预制的Grafana仪表板和本机Linkerd仪表板。

    Linkerd可以插入Prometheus实例。

    可以通过使用OpenTelemetry(以前称为OpenCensus)作为收集器的插件来启用跟踪,而Jaeger可以自己进行跟踪。

    安装

    Linkerd安装是通过注入sidecar代理完成的,该代理是通过在Kubernetes中的资源中添加注释来完成的。有两种方法可以解决此问题:

    • 使用helm。(对于许多人来说,Helm是Kubernetes资源的首选配置和模板管理器。)

    • 安装Linkerd CLI,然后使用该命令行将Linkerd安装到集群中。

    第二种方法从下载并运行安装脚本开始:

    
    curl -sL https://run.linkerd.io/install | sh
    

    从那里开始,Linkerd CLI工具linkerd提供了一个有用的工具包,可以帮助安装其余的Linkerd并与应用程序集群和控制平面进行交互。

    linkerd check --pre将运行Linkerd安装所需的所有初步检查,并提供清晰准确的日志,说明为何潜在的Linkerd安装可能尚无法进行。如果不使用--pre,则此命令可用于安装后调试。

    下一步是通过运行以下命令在集群中安装Linkerd:

    linkerd install | kubectl apply -f -
    

    然后,Linkerd将安装许多不同的组件,而这些组件的资源占用却很小。因此,他们本身就有一种微服务方法:

    • linkerd-controller,提供CLI和仪表板与之交互的公共API

    • linkerd-identity,提供实现mTLS的证书颁发机构

    • linkerd-proxy-injector,它通过更改pod的配置来处理代理的注入

    • linkerd-web,它提供一个仪表板,可用于监视部署和Pod以及内部Linkerd组件

    Linkerd的大多数配置都基于CustomResourceDefinitions(CRD)。在开发Kubernetes附加软件时,这被认为是最佳实践-就像在Kubernetes集群中持久地安装插件一样。

    由于一些常见的误解,添加分布式跟踪(Linkerd用户实际上可能会或可能不会跟随它)需要添加linkerd-collector和linkerd-jaeger的另一步骤。为此,我们将首先创建一个配置文件:

    cat >> config.yaml << EOF
    tracing:
      enabled: true
    EOF
    

    要启用跟踪,我们将运行:

    linkerd upgrade --config config.yaml | kubectl apply -f -
    

    与任何基于Sidecar代理的服务网格一样,您将需要修改应用程序代码以启用跟踪。大部分工作只是添加一个客户端库来传播跟踪头。然后需要将其包含在每个服务中。

    Linkerd的流量拆分功能通过其符合Service Mesh Interface(SMI)的API公开,已经允许发布canary版本。但是要使它们自动化和流量管理,您还需要外部工具,例如Flagger。

    Flagger是一种渐进式交付工具,它将评估Linkerd所谓的黄金指标:请求量、成功率和等待时间分布。(最初,Google SRE使用 黄金信号一词,并包含第四个信号-饱和度,但Linkerd并未涵盖该信号,因为那将需要无法直接访问的指标(例如CPU和内存使用情况)。)Flagger在拆分流量时会跟踪这些指标使用反馈回路;因此,您可以实施自动化的,具有指标功能的金丝雀版本。

    在深入研究安装过程之后,很明显,要使Linkerd服务网格能够运行并利用通常需要的功能,很容易最终至少运行十多个服务。也就是说,Linkerd在安装时会比其他服务网格提供更多的服务。

    Linkerd服务网格摘要

    优点:

    Linkerd受益于其创建者的经验,两位曾在内部工具Finagle上工作的前Twitter工程师,后来从Linkerd v1中学习。作为最早的服务网格之一,Linkerd拥有一个蒸蒸日上的社区(其Slack有5,000多个用户,还有一个活动的邮件列表和Discord服务器)以及大量的文档和教程。Linkerd的2.9版已经很成熟,这一点已被Nordstrom,eBay,Strava,Expedia和Subspace等大公司采用。对于Linkerd,Buoyant提供了有偿的企业级支持。

    缺点:

    要使用Linkerd服务网格发挥其全部潜能,有一条相当强的学习曲线。Linkerd仅在Kubernetes容器中受支持(即,没有基于VM的“通用”模式)。Linkerd Sidecar代理不是Envoy。尽管这确实使Buoyant可以按照自己的意愿进行调整,但它消除了Envoy提供的固有可扩展性。这也意味着Linkerd缺少对断路,延迟注入和速率限制的支持。没有公开任何特定的API来轻松控制Linkerd控制平面。(不过,您可以找到gRPC API绑定。)

    自v1以来,Linkerd在可用性和易于安装方面取得了长足的进步。缺少正式公开的API是一个明显的遗漏。但是由于有了其他经过深思熟虑的文档,Linkerd中的开箱即用功能易于测试。

    Consul

    我们的下一个服务网格竞争者Consul Connect是一个独特的混合体。HashiCorp的Consul以其分布式结构的键值存储而闻名,这种存储已经存在了很多年。在Consul演变为一整套服务工具之后,HashiCorp决定在其之上构建服务网格:Consul Connect。

    确切地说,它具有混合性:

    Consul Connect数据平面基于以C ++编写的Envoy。Consul Connect的控制平面用Go编写。这是由Consul KV(键值存储)支持的部分。

    像大多数其他服务网格一样,Consul Connect通过在应用程序pod内注入sidecar代理来工作。在架构方面,Consul Connect基于代理和服务器。开箱即用,Consul Connect旨在使用三台或五台服务器作为StatefulSet指定的Pod Anti-affinity来具有高可用性(HA)。Pod反亲和力是确保分布式软件系统的Pod不会最终出现在同一节点(服务器)上的做法,从而在任何单个节点发生故障的情况下保证可用性。

    连接性

    没有什么可以使Consul Connect在这一领域脱颖而出。它提供的任何服务网做什么(这是相当多的),加上层七个特征为基于路径的路由、故障切换和负载均衡。

    安全

    与其他服务网格一样,Consul Connect提供基本的mTLS功能。它还具有Consul和Vault之间的本机集成(也由HashiCorp提供),可以用作CA提供程序来管理和签署群集中的证书。

    可观察性

    Consul Connect采用最常见的可观察性方法,将Envoy合并为Sidecar代理,以提供7层代理功能。将Consul Connect的UI配置为获取指标涉及更改内置配置文件,还需要启用Prometheus之类的指标提供程序。还可以配置一些Grafana仪表板以显示相关的特定于服务的指标。

    安装

    使用Helm图表将Consul Connect安装到Kubernetes集群中:helm repo add hashicorp https://helm.releases.hashicorp.com

    values.yaml如果要启用UI或使Consul Connect模块注入其sidecar代理,则需要修改默认值:helm install -f consul-values.yml hashicorp hashicorp/consul

    要咨询成员并检查各个节点,Consul建议先exec进入其中一个容器,然后使用CLI工具consul。要提供Consul提供的现成的Web UI,请运行kubectl port-forward service/hashicorp-consul-ui 18500:80

    Consul Connect摘要

    优点:

    • Consul Connect由HashiCorp支持;作为免费增值产品,还有一个具有附加功能的企业版,可提供企业级支持。就开发团队的经验而言,Consul是市场上最古老的工具之一。

    • Consul Connect拥有坚实的企业社区,并且众所周知,它可以在具有50,000个节点的基础架构上运行。此外,自2014年以来一直存在,使其成为相对于市场而言成熟的产品。

    • 依靠本机支持,Consul Connect在VM内运行良好。

    • 借助Consul Connect,有可能实现与顶级科技公司的服务前网格实施一样深入的应用程序集成。这要归功于公开了完整文档的库级API。

    缺点:

    • Consul Connect具有比其他服务网格更陡峭的学习曲线,并且需要更多的调整才能运行可视化的仪表板和指标。

    • HashiCorp的文档并不简单明了,让用户进行挖掘和尝试以正确配置它。

    • 流量管理文档很难找到,并且主要包含Envoy文档的链接,该文档没有特别提供有关Consul Connect流量管理的详细信息。

    • Consul Connect的SMI接口仍处于试验阶段。对于那些寻求企业级产品的人来说,Consul Connect是一个很好的选择。HashiCorp以其产品质量而闻名,Consul Connect也不例外。与其他服务网格相比,我在这里可以看到两个强大的优势:公司对企业版的强大支持以及适用于各种架构(不仅仅是Kubernetes)的工具。

    Istio

    2017年5月,谷歌,IBM和Lyft宣布了Istio。当Istio进入服务网格工具竞赛时,它在技术领域获得了很好的曝光。它的作者从1.9版开始就一直基于用户反馈添加了功能。

    Istio承诺在当时向竞争对手提供重要的新功能:自动负载均衡、故障注入等等。这引起了社区的广泛关注,但是,正如我们将在下面详述的那样,使用Istio绝非易事:Istio被公认为投入生产特别复杂。

    从历史上看,Istio项目经常在源代码更改方面反弹。一旦在控制平面上采用微服务架构,Istio现在(从版本1.5开始)又回到了单一架构。Istio重返集中化的理由是,微服务难以为操作员监控,代码库过于冗余,并且该项目已经达到组织成熟度–不再需要许多小团队在孤岛上工作。

    但是,一路走来,Istio因拥有数量最多的公开GitHub问题之一而声名狼藉。截至撰写本文时,bug的未结数量约为800个,已结bug的数量约为12,000个。尽管问题可能很多,但在这种情况下,它们确实代表了以前损坏的功能和资源失控所带来的有意义的改进。

    连接性

    与Consul Connect和Linkerd相比,Istio在流量管理方面非常强大。这要归功于子功能的广泛提供:请求路由、故障注入、流量转移、请求超时、断开以及控制到服务网格的入口和出口流量。虚拟服务和目标规则的概念使其在流量管理方面非常完整。

    但是,所有这些可能性都伴随着学习曲线,以及对Kubernetes集群上那些新资源的管理。

    安全

    Istio拥有一套全面的与安全性相关的工具,具有两个主轴:身份验证和授权。Istio可以在不同的范围内实施不同级别的策略:特定于工作负载,整个命名空间或网格范围。所有此类安全资源都通过Istio CRD(例如AuthorizationPolicy或)进行管理PeerAuthentication。

    除了标准的mTLS支持之外,还可以将Istio配置为接受或拒绝未加密的流量。

    可观察性

    在这里,Istio相当先进,提供多种遥测功能,可提供对服务网格的深入了解。指标基于四个黄金信号(等待时间,流量,错误和某种程度上的饱和度)。

    值得注意的是,Istio为控制平面本身提供了度量。它还提供分布式跟踪和访问日志,与Jaeger,Lightstep和Zipkin具有显式兼容性,以启用跟踪。

    没有本机仪表板,但对Kiali管理控制台有官方支持。

    安装

    安装非常简单,只需遵循官方步骤即可。Istio本身也作为beta功能集成到GKE中,但是GKE使用Istio 1.4.X,它是旧的微服务版本,而不是最新的整体版本。

    本地安装从下载最新版本开始:

    curl -L https://istio.io/downloadIstio | sh -

    之后cd到新创建的istio-文件夹,您可以将其添加到您的路径,所以你可以使用istioctl实用工具:export PATH=$PWD/bin:$PATH在这里,您可以通过istioctl以下方式将Istio安装到Kubernetes集群中:istioctl install

    这将使用default配置文件安装Istio 。istioctl配置文件允许您创建不同的安装配置,并在必要时在它们之间切换。但是,即使在单配置文件方案中,您也可以通过修改某些CRD来深度自定义Istio的安装。

    Istio资源将很难管理,你将需要管理CRDs-的几种VirtualService,DestinationRule以及Gateway在最低限度,以确保流量管理是否到位。

    • 一个VirtualService资源是声明的服务和不同的路由应用到请求的规则的配置。

    • 一个DestinationRule资源被用于分组和强制实施特定目标的流量策略。

    • Gateway创建了一个资源来管理入站和出站服务网格流量(即,其他Envoy代理,但在边缘而不是作为边车运行)。

    但让我们来看一个简单的例子显示了每个这些一起工作。假设我们有一个电子商务网站,其服务名为products。我们VirtualService可能看起来像这样:

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: products-route
      namespace: ecommerce
    spec:
      hosts:
      - products # interpreted as products.ecommerce.svc.cluster.local
      http:
      - match:
        - uri:
            prefix: "/listv1"
        - uri:
            prefix: "/catalog"
        rewrite:
          uri: "/listproducts"
        route:
        - destination:
            host: products # interpreted as products.ecommerce.svc.cluster.local
            subset: v2
      - route:
        - destination:
            host: products # interpreted asproducts.ecommerce.svc.cluster.local
            subset: v1
    

    相应的DestinationRule可以是:

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: products
    spec:
      host: products
      trafficPolicy:
        loadBalancer:
          simple: RANDOM # or LEAST_CONN or ROUND_ROBIN
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v3
        labels:
          version: v3
    

    最后,我们的Gateway:

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: cert-manager-gateway
      namespace: istio-system
    spec:
      selector:
        istio: ingressgateway
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - "*"
    

    有了这三个文件后,一个Istio安装就可以处理基本流量了。

    Istio服务网格摘要

    优点:

    • 在撰写本文时,在不同的服务网格中,Istio是最大的在线社区之一。作为其主要竞争对手之一,Stack Overflow的结果超过10倍,它是Web上最受关注的服务网格。

    • 它在GitHub贡献者同样超出了Linkerd。Istio支持Kubernetes和VM模式。后者是1.9版的beta版。

    缺点:

    Istio并非免费,有两种含义:

    • 就阅读文档,设置文档,使其正常工作和维护所需的时间而言,其要求很高。根据基础架构规模和服务数量,Istio将需要数周至数月的全职工作才能完全发挥作用并将其集成到生产中。

    • 它还增加了大量的资源开销:每秒每1000个请求(RPS)将需要350毫安(mCPU)的Envoy容器。甚至控制平面本身也会消耗资源。(以前,很难预测资源的使用情况,但是经过一番努力,istiod使用1个vCPU和1.5 GB的内存已经稳定下来了。)

    • 与Linkerd不同,它没有本机管理仪表板。

    • Istio需要使用其自己的入口网关。

    • Istio控制平面仅在Kubernetes容器内受支持(即,没有VM模式,与Istio的数据平面不同)。

    Istio是技术巨头齐心协力创建一个开源项目来应对他们所面临的挑战的一个很好的例子。整个Istio项目花了一些时间来构造自身(回想起微服务到整体架构的转变)并解决了许多最初的问题。如今,Istio完全可以满足人们对服务网格的所有期望,并且可以大大扩展。但是,所有这些可能性都对知识、工作时间和计算资源提出了苛刻的要求,以支持其在生产环境中的使用。

    Kuma快速评论

    由Kong创建并开放源代码,Kuma在2020年末达到1.0。在某种程度上,它是响应于第一个服务网格相当沉重且难以操作而创建的。

    它的功能列表表明它是非常模块化的。Kuma背后的想法是将其定位为与已经在Kubernetes或其他基础架构上运行的应用程序集成。

    • 在流量管理领域,Kuma提供了常见的服务网格功能,例如故障注入和断路。

    • 除了服务间mTLS加密之外,还可以通过数据平面代理令牌在Kuma中保护数据平面和控制平面之间的交换。

    • 在Kuma中,通过围绕度量标准,跟踪和日志记录的不同流量策略定义了可观察性。

    • 由于Kuma在控制平面的端口5653上运行了自己的DNS解析器,因此可以通过Kuma进行服务发现。

    • Kuma十分强调多网格功能:您可以轻松地将多个Kubernetes群集或VM环境结合到具有其多区域部署类型的常见Kuma群集中。

    • 对于现有的Kong用户,Kuma可以轻松地与Kong Gateway集成。

    Kuma的通用(非Kubernetes)版本要求将PostgreSQL作为依赖项,并且Kong的CTO特别反对支持SMI。但是Kuma最初是基于多云和多集群部署的思想开发的,其仪表板反映了这一点。

    尽管Kuma在服务网格领域还很年轻,但到目前为止很少有生产使用案例,但这是一个有趣且有希望的竞争者。

    Traefik Mesh快速评论

    Traefik Mesh(由Traefik Labs提供)最初名为Maesh,是服务网格工具竞赛中的另一个新来者。该项目的任务是通过易于使用和配置来使服务网格民主化。开发人员在深思熟虑的Traefik Proxy方面的经验使他们处于实现这一目标的首要位置。

    • Traefik Mesh中的流量管理功能包括断路和速率限制。

    • 在可观察性方面,Traefik Mesh具有本机OpenTracing支持和开箱即用的度量标准(标准安装自动包括Prometheus和Grafana),从而节省了设置时间。

    • 为了安全起见,除了mTLS之外,该规范还符合SMI要求,并且Traefik Mesh允许通过访问控制对流量许可进行微调。

    Traefik Mesh需要在群集上安装CoreDNS。(虽然从1.12开始,Azure默认使用CoreDNS,但在撰写本文时,GKE默认使用kube-dns,这意味着在这种情况下还涉及很多重要步骤。)它还缺乏多群集功能。

    就是说,Traefik Mesh在我们的服务网格比较中是独一无二的,因为它不使用边车注入。而是将其作为DaemonSet部署在所有节点上,充当服务之间的代理,从而使其具有非侵入性。总体而言,Traefik Mesh易于安装和使用。

    AWS App Mesh快速审阅

    在云提供商的世界中,AWS是第一个实现可与Kubernetes(尤其是EKS)以及其他服务一起插入的本机服务网格的服务商。AWS App Mesh于2018年11月发布,自那时以来AWS一直在对其进行迭代。AWS App Mesh的主要优势是预先存在的AWS生态系统和市场地位;整个AWS背后的大型社区将继续推动其使用和可用性。

    • AWS App Mesh中的流量管理包括在常见功能之上的断路。

    • 由于AWS App Mesh由AWS托管,因此它是一项完全托管的服务,这意味着不必担心资源使用或控制平面可用性。

    • 可以通过Prometheus或AWS X-Ray实现AWS App Mesh中的可观察性。

    该项目不是开源的,不支持SMI,并且在线上没有太多有关控制平面的HA标准的信息。AWS App Mesh的设置比其他Kubernetes本地服务网格更复杂,并且在线社区很少(Stack Overflow上有24个答案,GitHub上有400个星),但这是因为用户必须从AWS支持中受益。

    AWS App Mesh与AWS进行了本机集成,从EKS开始,并扩展到其他AWS服务,例如ECS(Fargate)和EC2。与Traefik Mesh不同,它具有多集群支持。另外,像大多数服务网格一样,它是基于Envoy注入的,该Envoy是经过大量测试的Sidecar代理。

    Kubernetes服务网格比较表

    这里介绍的六个Kubernetes服务网格选项有一些共同点:

    • 协议支持:它们都可与HTTP,HTTP / 2,gRPC,TCP和WebSockets一起使用。

    • 默认情况下,它们在代理之间均具有mTLS形式的基本安全性。

    • 通过设计,服务网格可提供某种形式的负载平衡。

    • 至少这六个工具在其流量管理功能中还至少包括一个请求重试选项。

    • 最后,服务发现是任何服务网格的核心功能。

    但是,在服务网格基础结构,流量管理,可观察性,部署和其他方面,肯定有一些值得强调的差异。

    基础设施

    流量管理

    可观察性

    OpenCensus和OpenTracing在2019年合并为OpenTelemetry,但您可能会发现Linkerd文章涉及OpenCensus,以及Istio和Traefik Mesh文章涉及OpenTracing。

    部署方式

    注意事项

    我们应该使用Kubernetes服务网格吗?

    现在,我们已经了解了什么是服务网格,它们如何工作以及它们之间的众多差异,我们可以问:我们是否需要服务网格?

    这是过去几年中SRE和云工程师面临的一个大问题。实际上,微服务给服务网格可以解决的网络通信带来了运营挑战。但是,在安装和操作方面,服务网格在大多数情况下会带来自身的挑战。

    我们可以看到,在许多项目中出现的一个问题是,服务网格在概念验证阶段和生产阶段之间存在差距。也就是说,对于公司而言,实现在各个方面都与生产相同的过渡环境是非常罕见的。由于服务网格涉及关键基础架构,因此与规模和边缘相关的影响可能会带来部署方面的意外。

    服务网格仍在大力发展和改进。对于部署频率较高的团队来说,这实际上可能是有吸引力的,这些团队已经掌握了保持最新版本并可以密切关注云原生工具的开发周期。

    但是,对于其他人而言,服务网格演进的速度可能更是一个陷阱。设置服务网格将很容易,但如果随后没有及时维护它。安全补丁可能无法应用,或者即使被记住,也可能以不推荐使用的功能或经过修改的依赖项集的形式带来计划外的问题。

    就在生产中建立服务网格的人力而言,这也是一笔可观的成本。任何团队评估此信息并了解服务网格的好处是否会超过初始设置时间,将是一个明智的目标。无论“简易”演示安装显示了什么,服务网格都是很难的。

    简而言之,服务网格可以解决大规模部署项目中常见的一些问题,但可能会引入其他问题,因此要准备投入时间和精力。在一个假设的基础结构中,该基础结构涉及25个微服务,并且每秒要处理5个查询,我建议至少有一个人(最好是两个人)专门工作至少一个月,以准备概念证明并验证关键方面,然后再考虑在生产环境中运行它。设置完成后,请预测是否需要频繁升级-它们将影响基础架构的核心组件,即网络通信。

    Kubernetes服务网格:可扩展应用程序架构中的(复杂)演进

    我们已经了解了什么是服务网格:一套工具,可以应对微服务架构引入的新挑战。通过流量管理,可观察性,服务发现和增强的安全性,服务网格可以揭示对应用程序基础架构的深入了解。

    市场上有多个参与者,有时是由GAFAM等组织提倡的,在某些情况下,它们是开源的或促进了他们自己的内部工具。尽管有两种不同的实现类型,但是服务网格将始终具有由代理构成的控制平面(系统的大脑)和数据平面,这些代理将拦截您的应用程序的请求。

    回顾三个最大的服务网格(Linkerd,Consul Connect和Istio),我们看到了他们选择实施的不同策略以及它们带来的优势。Linkerd是市场上最古老的服务网格,得益于其在Twitter上的创建者经验。就HashiCorp而言,它提供企业级的Consul Connect,并具有高水平的专业知识和支持。Istio最初在网络上引起了足够的关注,但现在已经发展成为一个成熟的项目,最终提供了功能完善的平台。

    但是,这些角色远非仅有这些角色,而是出现了一些鲜为人知的服务网格:Kuma,Traefik Mesh和AWS App Mesh等。来自Kong的Kuma的创建是为了使服务网格的想法“简单”并且可插入任何系统中,而不仅仅是Kubernetes。Traefik Mesh得益于已有的Traefik Proxy的经验,并做出了避免使用边车代理的罕见决定。最后但并非最不重要的一点是,AWS决定开发自己的版本的服务网格,但是它依赖可靠的Envoy Sidecar代理。

    实际上,服务网格仍然很难实现。尽管服务网格的好处引人注目,但它们的影响却在两个方面都截然不同:服务网格的失败可能使您的微服务无法相互通信,从而可能破坏整个堆栈。一个臭名昭著的例子是:Linkerd版本和Kubernetes版本之间的不兼容性在在线银行Monzo造成了全面的生产中断。

    尽管如此,整个行业都在围绕Kubernetes和诸如Microsoft带头的SMI之类的计划进行结构调整,SMI是Kubernetes上服务网格的标准接口。在众多其他项目中,Cloud Native Computing Foundation(CNCF)拥有基于Envoy的开放服务网格(OSM)计划,该计划最初也是由Microsoft引入的。服务网格生态系统仍然很热闹,我预测在未来几年会出现一个冠军,就像Kubernetes成为事实上的容器编排工具一样。

    推荐


    过早关注基础设施建设是万恶之源

    Kubernetes入门培训(内含PPT)

    从Ice到Kubernetes容器技术,微服务架构经历了什么?


    随手关注或者”在看“,诚挚感谢

    展开全文
  • 一、traefik 简介 1.1 简单认识 traefik代理 ... 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。i...

    一、traefik 简介

    1.1 简单认识 traefik代理

    Træfɪk 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。ingress方案需要使用下列的组件:

    1、反向代理负载均衡器

    负责加载 ingress control 、ingress生成的配置,并实现reload功能。
    2、ingress control

    ingress Controller 实质上是个监视器,Ingress Controller 通过不断地跟 kubernetes API 打交道,实时的获取后端 service、pod 的变化,比如新增和减少 pod,service 增加与减少等;当得到这些变化信息后,Ingress Controller 再结合下文的 Ingress 生成配置,然后更新反向代理负载均衡器,并刷新其配置,达到服务发现的作用。
    3、ingress

    ingress,就类似于互联网应用的负载均衡器(比如Apache/nginx之类的),是kubernetes集群外访问集群的入口,将用户的URL请求转发到不同的service上。其中还包括规则定义,即URL的路由信息,路由信息得的刷新由Ingress controller来提供。
    4、RBAC
    在开始之前,需要先了解一下什么是RBAC。RBAC(基于角色的访问控制)使用 rbac.authorization.k8s.io API 组来实现权限控制,RBAC 允许管理员通过 Kubernetes API 动态的配置权限策略。在 1.6 版本中 RBAC 还处于 Beat 阶段,如果想要开启 RBAC 授权模式需要在 apiserver 组件中指定 --authorization-mode=RBAC 选项。

    在 RBAC API 的四个重要概念:
    Role:是一系列的权限的集合,例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限
    ClusterRole: 跟 Role 类似,但是可以在集群中到处使用( Role 是 namespace 一级的)
    RoloBinding:把角色映射到用户,从而让这些用户继承角色在 namespace 中的权限。
    ClusterRoleBinding: 让用户继承 ClusterRole 在整个集群中的权限。
    参考链接:

    http://docs.traefik.cn/basics

    https://rootsongjc.gitbooks.io/kubernetes-handbook/content/practice/traefik-ingress-installation.html

    1.2 部署 Træfɪk

    因为我这里是作为kubernetes服务的暴露,因此你得有一个kubernetes集群。如果你没有,可以通过kubeadm/kops等方式快速部署一个kubernetes集群,具体使用那一种方式安装你的kubernetes集群,完全取决于你的爱好。

    给集群的节点打上labe;

    kubectl label nodes 192.168.2.11 edgenode=traefik-proxy
    kubectl label nodes 192.168.2.12 edgenode=traefik-proxy
    kubectl label nodes 192.168.2.13 edgenode=traefik-proxy
     kubectl get nodes --show-labels
    NAME           STATUS                     ROLES     AGE       VERSION   LABELS
    192.168.2.10   Ready,SchedulingDisabled   master    5d        v1.11.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.2.10,kubernetes.io/role=master
    192.168.2.11   Ready                      node      5d        v1.11.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,edgenode=traefik-proxy,kubernetes.io/hostname=192.168.2.11,kubernetes.io/role=node
    192.168.2.12   Ready                      node      5d        v1.11.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,edgenode=traefik-proxy,kubernetes.io/hostname=192.168.2.12,kubernetes.io/role=node
    192.168.2.13   Ready                      node      5d        v1.11.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,edgenode=traefik-proxy,kubernetes.io/hostname=192.168.2.13,kubernetes.io/role=node
    192.168.2.14   Ready,SchedulingDisabled   master    5d        v1.11.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.2.14,kubernetes.io/role=master

    准备所需配置文件:

    # cat ingress-rbac.yaml 
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: ingress
      namespace: kube-system
    
    ---
    
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: ingress
    subjects:
      - kind: ServiceAccount
        name: ingress
        namespace: kube-system
    roleRef:
      kind: ClusterRole
      name: cluster-admin
      apiGroup: rbac.authorization.k8s.io
    # cat traefik.yaml 
    apiVersion: extensions/v1beta1
    kind: DaemonSet
    metadata:
      name: traefik-ingress-lb
      namespace: kube-system
      labels:
        k8s-app: traefik-ingress-lb
    spec:
      template:
        metadata:
          labels:
            k8s-app: traefik-ingress-lb
            name: traefik-ingress-lb
        spec:
          terminationGracePeriodSeconds: 60
          hostNetwork: true
          restartPolicy: Always
          serviceAccountName: ingress
          containers:
          - image: traefik
            name: traefik-ingress-lb
            resources:
              limits:
                cpu: 200m
                memory: 30Mi
              requests:
                cpu: 100m
                memory: 20Mi
            ports:
            - name: http
              containerPort: 80
              hostPort: 80
            - name: admin
              containerPort: 8580
              hostPort: 8580
            args:
            - --web
            - --web.address=:8580
            - --kubernetes
          nodeSelector:
            edgenode: "traefik-proxy"  #需要安装traefik的标签

    下面给traefik配置上ui:

    # cat ui.yaml 
    apiVersion: v1
    kind: Service
    metadata:
      name: traefik-web-ui
      namespace: kube-system
    spec:
      selector:
        k8s-app: traefik-ingress-lb
      ports:
      - name: web
        port: 80
        targetPort: 8580
    ---
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: traefik-web-ui
      namespace: kube-system
    spec:
      rules:
      - host: tf.abcgogo.com #配置ui的域名
        http:
          paths:
          - path: /
            backend:
              serviceName: traefik-web-ui
              servicePort: web

    准备好配置文件后,执行命令:

    kubectl apply -f .

    检查是否执行成功:

    # kubectl get svc,deployment,pod --all-namespaces -o wide | grep traefik
    
    kube-system   service/traefik-web-ui         ClusterIP   10.68.166.109   <none>        80/TCP              4h        k8s-app=traefik-ingress-lb
    kube-system   pod/traefik-ingress-lb-2qbgd                1/1       Running   0          4h        192.168.2.12   192.168.2.12   <none>
    kube-system   pod/traefik-ingress-lb-9tc6n                1/1       Running   0          4h        192.168.2.11   192.168.2.11   <none>
    kube-system   pod/traefik-ingress-lb-fmfn6                1/1       Running   0          4h        192.168.2.13   192.168.2.13   <none>

    查看svc,ing状态:

    # kubectl describe svc,ing traefik-web-ui -n kube-system
    Name:              traefik-web-ui
    Namespace:         kube-system
    Labels:            <none>
    Annotations:       kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"traefik-web-ui","namespace":"kube-system"},"spec":{"ports":[{"name":"web","por...
    Selector:          k8s-app=traefik-ingress-lb
    Type:              ClusterIP
    IP:                10.68.166.109
    Port:              web  80/TCP
    TargetPort:        8580/TCP
    Endpoints:         192.168.2.11:8580,192.168.2.12:8580,192.168.2.13:8580
    Session Affinity:  None
    Events:            <none>
    
    Name:             traefik-web-ui
    Namespace:        kube-system
    Address:          
    Default backend:  default-http-backend:80 (<none>)
    Rules:
      Host            Path  Backends
      ----            ----  --------
      tf.abcgogo.com  
                      /   traefik-web-ui:web (192.168.2.11:8580,192.168.2.12:8580,192.168.2.13:8580)
    Annotations:
      kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{},"name":"traefik-web-ui","namespace":"kube-system"},"spec":{"rules":[{"host":"tf.abcgogo.com","http":{"paths":[{"backend":{"serviceName":"traefik-web-ui","servicePort":"web"},"path":"/"}]}}]}}
    
    Events:  <none>

    使用部署traefik节点的node ip: port就可以访问了,
    traefik(一) kubernetes 部署 traefik
    当然刚才配置了域名,可以直接使用域名访问,前提是对域名做好了dns解析。
    traefik(一) kubernetes 部署 traefik

    自定义一个ingress:

    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-svc
    spec:
      template:
        metadata:
          labels:
            name: nginx-svc
            namespace: default
    spec:
      selector:
        run: ngx-pod
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
    ---
    apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
      name: ngx-pod
    spec:
      replicas: 4
      template:
        metadata:
          labels:
            run: ngx-pod
        spec:
          containers:
          - name: nginx
            image: nginx:1.10
            ports:
            - containerPort: 80
    ---
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: ngx-ing
      annotations:
        kubernetes.io/ingress.class: traefik
    spec:
      rules:
      - host: traefik.abcgogo.com
        http:
          paths:
          - backend:
              serviceName: nginx-svc
              servicePort: 80,

    traefik(一) kubernetes 部署 traefik
    补充说明:
    如果您将traefik部署为deployment
    https://raw.githubusercontent.com/containous/traefik/master/examples/k8s/traefik-deployment.yaml),则应检查返回的NodePort kubectl describe svc traefik-ingress-service -n kube-system并将其用作您的URL(http: //traefik-ui.minikube:xxx

    (您不必将traefik-web-ui更改为NodePort)

    如果您使用了DeamonSet
    https://raw.githubusercontent.com/containous/traefik/master/examples/k8s/traefik-ds.yaml),请使用http://域名

    如果您想traefik-web-ui直接访问最简单的方法是: minikube service traefik-web-ui --url
    linux下配置hosts本地解析:echo "$(my master node ip) traefik-ui.minikube" | sudo tee -a /etc/hosts

    转载于:https://blog.51cto.com/m51cto/2328917

    展开全文
  • 目前支持 Docker、Swarm、Mesos/Marathon、 Mesos、Kubernetes、Consul、Etcd、Zookeeper、BoltDB、Rest API 等等后端模型。 要使用 traefik,我们同样需要部署 traefik 的 Pod,我们将 traefik 部署到master节点上...
  • 想象一下,您已经在协调器(如Swarm或Kubernetes)或服务注册表(如etcd或consul)的帮助下部署了一堆微服务。 现在,您希望用户访问这些微服务,并且需要反向代理。 传统的反向代理要求您配置将路径和子域连接到每...
  • 开源项目-EmileVauge-traefik.zip,Modern HTTP reverse proxy that supports etcd, docker, consul and more
  • <div><p>Træfɪk is a modern HTTP reverse proxy and load balancer made to deploy microservices with ease. It supports several backends (Docker, Swarm, Mesos/Marathon, Consul, Etcd, Zookeeper, BoltDB, ...
  • <div><p>Hello , I could setup everything(Traefik,Consul,Swarmprom,Swarmpit,Portainer) perfect with this guide . But the problem occurs when I deploy new stacks . For eg., wordpress . I get404 page not...
  • Traefik是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。它支持多种后台(Rancher、Docker、Swarm、Kubernetes、Marathon、Mesos、Consul、Etcd、Zookeeper、BoltDB、RestAPI、file…)来自动...
  • 翻译:The basics of Traefik概念入口点前端修改组匹配组 概念 我们再次从概述中举一个例子: 假设你已经在你的基础服务中部署了一系列的微服务。你可能用了一个服务注册器(如:etcd或consul)或者一个编排器...
  • or is consul template required for that on traefik ? <p>I have an install using marathon: <pre><code> --- # CHECK SECURITY - when customizing you should leave this in. If you # take it out and for...
  •  traefik 是一个前端http反向代理服务器以及负载均衡器,支持多种微服务后端(Docker,Swarm,Kubernetes,Marathon,Consul,Etcd,Rancher,Amazon ECS等);同 nginx 等相比,traefik 能够自动感...
  • "Consul": null, "ConsulCatalog": null, "Etcd": null, "Zookeeper": null, "Boltdb": { "Watch": true, "Filename": "", "Constraints": [], "Endpoint": "/Users/tochti/Tmp/traefik.db", "Prefix": "/...
  • Træfɪk 是一个新型的http反向代理、... 它支持多种后端 (Docker, Swarm, Mesos/Marathon, Consul, Etcd, Zookeeper, BoltDB, Rest API, file...) ,可以对配置进行自动化、动态的管理. 标签:Traefik
  • HTTP proxy is done with traefik through the <code>consul_catalog</code> provider within traeifk. Consul services are exported by their name to a specific domain. <p>I'm not totally sure on how ...
  • 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。 特性一览 它非常快 无需安装其他依...
  • 1、Traefik 介绍 在日常工作中,我们经常使用 Nginx、Apache 等工具作为反向代理、负载均衡,而 Træfik 是一个为了让部署微服务更加便捷而诞生的 HTTP 反向代理、负载均衡工具。它支持多种后台 (Docker、Swarm、...
  • http反向代理以及处理的软件在现在虽然是有很多的... 主要功能traefik是一个新型的http反向代理、负载均衡软件,能轻易的部署微服务,它支持多种后端 (Docker, Swarm, Mesos/Marathon, Consul, Etcd, Zookeeper, BoltDB
  • 《kubernetes-1.8.0》13-addon-traefik

    千次阅读 2017-11-30 17:59:06
    《kubernetes-1.8.0》13-addon-traefik 《kubernetes 1.8.0 测试环境安装部署》 时间:2017-11-30 一、traefix介绍trarfik是一个类似ingress-nginx的http反向代理和负载均衡服务。支持Docker, Swarm mode, ...
  • 上篇懒得写了索性转载了一篇nginx-ingress的,本篇我们来看神器Traefik,我个人是比较看好和偏向与Traefik的,它轻便易用而且还有界面。... 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, E...
  • traefik## 简介 traefik是一款开源的反向代理与负载均衡工具。软件定位是做负载均衡器,提供好用的负载均衡服务,不要老拿它跟nginx对比。它最大的优点是能够与常见的微服务系统直接整合,可以实现自动化动态配置。 ...

空空如也

空空如也

1 2 3 4
收藏数 68
精华内容 27
关键字:

consultraefik