Traefik Middlewares简介官方文档 Traefik Middlewares 是一个处于路由和后端服务之前的中间件，在外部流量进入 Traefik，且路由规则匹配成功后，将流量发送到对应的后端服务前，先将其发给中间件进行一系列处理（类似于过滤器链 Filter，进行一系列处理），例如，添加 Header 头信息、鉴权、流量转发、处理访问路径前缀、IP 白名单等等，经过一个或者多个中间件处理完成后，再发送给后端服务，这个就是中间件的作用。 Traefik内置了很多不同功能的Middleware，主要是针对HTTP和TCP，这里挑选几个比较常用的进行演示。 重定向-redirectScheme官方文档 我们定义的 whoami 这个应用，我们可以通过 https://whoami.od.com/tls 来访问到应用，但是如果我们用 http 来访问的话呢就不行了，就会 404 了，因为我们根本就没有简单 80 端口这个入口点，所以要想通过 http 来访问应用的话自然我们需要监听下 web 这个入口点： 123456789101112131415cat > tls-h ...
ingressRoute简介kubernetes 中使用 Traefik ingress 的 ingressRoute 代理 http、https、tcp、udp。 官方文档 三种方式Traefik 创建路由规则有多种方式，比如： 原生 Ingress 写法 使用 CRD IngressRoute 方式 使用 GatewayAPI 的方式 相较于原生 Ingress 写法，ingressRoute 是 2.1 以后新增功能，简单来说，他们都支持路径 (path) 路由和域名 (host) HTTP 路由，以及 HTTPS 配置，区别在于 IngressRoute 需要定义 CRD 扩展，但是它支持了 TCP、UDP 路由以及中间件等新特性，强烈推荐使用 ingressRoute 匹配规则 规则 描述 Headers(key, value) 检查headers中是否有一个键为key值为value的键值对 HeadersRegexp(key, regexp) 检查headers中是否有一个键位key值为正则表达式匹配的键值对 Host(example.com, boy ...
RBAC 讲解在K8S中支持授权有AlwaysDeny、AlwaysAllow、ABAC、Webhook、RBAC、Node共6种模式，从1.6版本起，K8S默认启用RBAC访问控制策略，目前RBAC已作为稳定的功能，管理员可以通过 Kubernetes API 动态配置策略来启用RBAC，需要在 kube-apiserver 中添加参数--authorization-mode=RBAC。 1234cat /opt/kubernetes/cfg/kube-apiserver.yaml... - --authorization-mode=Node,RBAC... AlwaysDeny：表示拒绝所有请求，一般用于测试。 AlwaysAllow：允许接收所有请求。如果集群不需要授权流程，则可以采用该策略，这也是Kubernetes的默认配置。 ABAC（Attribute-Based Access Control）：基于属性的访问控制。表示使用用户配置的授权规则对用户请求进行匹配和控制。 Webhook：通过调用外部REST服务对用户进行授权。 RBAC：Role-Based Ac ...
Containerd 命令行工具 nerdctl前面我们介绍了可以使用 ctr 操作管理 containerd 镜像容器，但是大家都习惯了使用 docker cli，ctr 使用起来可能还是不太顺手，为了能够让大家更好的转到 containerd 上面来，社区提供了一个新的命令行工具：nerdctl。nerdctl 是一个与 docker cli 风格兼容的 containerd 客户端工具，而且直接兼容 docker compose 的语法的，这就大大提高了直接将 containerd 作为本地开发、测试或者单机容器部署使用的效率。 安装安装nerdctl同样直接在 GitHub Release 页面下载对应的压缩包解压到 PATH 路径下即可： 12345678910111213141516171819202122cd /server/tools# 如果没有安装 containerd，则可以下载 nerdctl-full-<VERSION>-linux-amd64.tar.gz 包进行安装wget https://github.com/containerd/nerdct ...
虚拟化运维
未读容器概述在学习 Containerd 之前我们有必要对 Docker 的发展历史做一个简单的回顾，因为这里面牵涉到的组件实战是有点多，有很多我们会经常听到，但是不清楚这些组件到底是干什么用的，比如 libcontainer、runc、containerd、CRI、OCI 等等。 Docker从 Docker 1.11 版本开始，Docker 容器运行就不是简单通过 Docker Daemon 来启动了，而是通过集成 containerd、runc 等多个组件来完成的。虽然 Docker Daemon 守护进程模块在不停的重构，但是基本功能和定位没有太大的变化，一直都是 CS 架构，守护进程负责和 Docker Client 端交互，并管理 Docker 镜像和容器。现在的架构中组件 containerd 就会负责集群节点上容器的生命周期管理，并向上为 Docker Daemon 提供 gRPC 接口。 当我们要创建一个容器的时候，现在 Docker Daemon 并不能直接帮我们创建了，而是请求 containerd 来创建一个容器，containerd 收到请求后，也并不会直接去操 ...
SecretSecret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。 由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。 Secret 类似于 ConfigMap 但专门用于保存机密数据。 注意: 默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。 此外，任何有权限在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何 Secret； 这包括间接访问，例如创建 Deployment 的能力。 为了安全地使用 Secret，请至少执行以下步骤： 为 Secret 启用 ...
ConfigMapConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pods 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。 ConfigMap 将你的环境配置信息和 容器镜像 解耦，我们知道许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求，这样就便于配置信息的修改。 ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过1MiB(这其实是ETCD的要求哈哈哈)。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷 或者使用独立的数据库或者文件服务。 创建ConfigMapConfigMap 资源对象使用 key-value 形式的键值对来配置数据，这些数据可以在 Pod 里面使用，如下所示的资源清单： 123456789101112kind: ConfigMapapiVersion: v1metadata: name: cm-demo namespace: defaultdata: data.1: hello data.2: world confi ...
虚拟化运维
未读Linkerd 介绍Linkerd 是 Kubernetes 的一个完全开源的服务网格实现。它通过为你提供运行时调试、可观测性、可靠性和安全性，使运行服务更轻松、更安全，所有这些都不需要对你的代码进行任何更改。 Linkerd 通过在每个服务实例旁边安装一组超轻、透明的代理来工作。这些代理会自动处理进出服务的所有流量。由于它们是透明的，这些代理充当高度仪表化的进程外网络堆栈，向控制平面发送遥测数据并从控制平面接收控制信号。这种设计允许 Linkerd 测量和操纵进出你的服务的流量，而不会引入过多的延迟。为了尽可能小、轻和安全，Linkerd 的代理采用 Rust 编写。 功能概述 自动 mTLS：Linkerd 自动为网格应用程序之间的所有通信启用相互传输层安全性 (TLS)。 自动代理注入：Linkerd 会自动将数据平面代理注入到基于 annotations 的 pod 中。 容器网络接口插件：Linkerd 能被配置去运行一个 CNI 插件，该插件自动重写每个 pod 的 iptables 规则。 仪表板和 Grafana：Linkerd 提供了一个 Web 仪表板，以及预配置的 ...
虚拟化运维
未读Istio 可观察性前面我们学习了 Istio 中的流量管理功能，本节我们来学习如何配置 Istio来自动收集网格中的服务遥测。Istio为网格内所有的服务通信生成详细的遥测数据，这种遥测技术提供了服务的可观察性，使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及Istio组件进行交互。 网站会自动生成以下类型的遥测数据，以提供对整个服务网格的可观察性: 指标:Istio 基于 4 个监控的黄金标识(延迟、流量、错误、饱和)生成了一系列服务指标，Isti 还为网格控制平面提供了更详细的指标，除此以外还提供了一组默认的基于这些指标的网格监控仪表板。 延迟表示服务一个请求所需的时间。这个指标应该分成成功请求（如 HTTP 200）和失败请求（如 HTTP 500）的延迟。 流量是衡量对系统的需求有多大，它是以系统的具体指标来衡量的。例如，每秒的 HTTP 请求，或并发会话，每秒的检索量，等等。 错误用来衡量请求失败的比率（例如 HTTP 500）。 饱和度衡量一个服务中最紧张的资源 ...
实例架构该应用由四个单独的微服务构成。 这个应用模仿在线书店的一个分类，显示一本书的信息。 页面上会显示一本书的描述，书籍的细节（ISBN、页数等），以及关于这本书的一些评论。 Bookinfo 应用分为四个单独的微服务： productpage. 这个微服务会调用 details 和 reviews 两个微服务，用来生成页面。 details. 这个微服务中包含了书籍的信息。 reviews. 这个微服务中包含了书籍相关的评论。它还会调用 ratings 微服务。 ratings. 这个微服务中包含了由书籍评价组成的评级信息。 reviews 微服务有 3 个版本： v1 版本不会调用 ratings 服务。 v2 版本会调用 ratings 服务，并使用 1 到 5 个黑色星形图标来显示评分信息。 v3 版本会调用 ratings 服务，并使用 1 到 5 个红色星形图标来显示评分信息。 Bookinfo 是一个异构应用，几个微服务是由不同的语言编写的。这些服务对 Istio 并无依赖，但是构成了一个有代表性的服务网格的例子：它由多个服务、多个语言构成，并且 review ...
Ingress Gateway简介传统上，Kubernetes使用Ingress控制器来处理从外部进入集群的流量。使用Istio时，情况不再如此。 Istio已用新的Gateway和VirtualServices资源替换了熟悉的Ingress资源。它们协同工作，将流量路由到网格中。在网格内部，不需要Gateway，因为服务可以通过集群本地服务名称相互访问。 Istio流量分发控制环境准备 主机名 IP 角色 k8s-master eth0:10.1.1.100、docker：172.17.100.0/24 K8S-master k8s-node1 eth0:10.1.1.120、docker：172.17.120.0/24 K8S-node k8s-node2 eth0:10.1.1.130、docker：172.17.130.0/24 K8S-node nginx-proxy eth0:10.1.1.11 代理节点 场景模型图目前我们实现了后台服务层面，前端front调用后端service的流量策略，现在实现下客户访问前端的流量 ...
虚拟化运维
未读Envoy简介什么是Envoy envoy 是作为微服务服务架构中以独立进程方式实现高级网络功能的，轻量级的7层服务代理程序，通常以sidecar的方式运行在应用程序的周边，也可以作为网络的边缘代理来运行。 envoy 的特性 进程外体系结构 ，L3/L4过滤器体系结构，HTTP L7过滤器体系结构， 一流的HTTP/2支持， HTTP/3支持(目前为alpha)，HTTP L7路由，gRPC支持，服务发现和动态配置，健康检查，高级负载平衡，前端/边缘代理支持， 一流的可观察性 服务网格细节剖析宏观分析执行的操作： 使用istioctl为pod注入了sidecar 创建了virtualservice和destinationrule 如何最终影响到了pod的访问行为？ 宏观角度nginx的配置中，可以提供类似如下的配置片段实现按照权重的转发： 因为nginx是代理层，可以转发请求，istio也实现了流量转发的效果，肯定也有代理层，并且识别了前面创建的虚拟服务中定义的规则。 1$ istioctl kube-inject -f front-t ...
