APISIXApache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能、可扩展的微服务 API 网关，目前已经是 Apache 顶级项目。提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B 测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等。可以使用 APISIX 来处理传统的南北流量以及服务之间的东西向流量。 APISIX 基于 Nginx 和 etcd，与传统 API 网关相比，APISIX 具有动态路由和热加载插件功能，避免了配置之后的 reload 操作，同时 APISIX 支持 HTTP(S)、HTTP2、Dubbo、QUIC、MQTT、TCP/UDP 等更多的协议。而且还内置了 Dashboard，提供强大而灵活的界面。同样也提供了丰富的插件支持功能，而且还可以让用户自定义插件。 上图是 APISIX 的架构图，整体上分成数据面和控制面两个部分，控制面用来管理路由，主要通过 etcd 来实现配置中心，数据面用来处理客户端请求，通过 APISIX 自身来 ...
Pods调度我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们希望一些机器学习的应用只跑在有 GPU 的节点上；但是有的时候我们的服务之间交流比较频繁，又希望能够将这服务的 Pod 都调度到同一个的节点上。这就需要使用一些调度方式来控制 Pod 的调度了，主要有两个概念：亲和性和反亲和性，亲和性又分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。 定向调度(nodeSelector)如果要实现定向调度，首先的第一步就是要为Node节点搭上标签（Label），我们知道 label 标签是 kubernetes 中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的 Service 对象通过 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。可以使用kubectl label命令： 12345# 添加label标签kubectl label nod ...
Traefik自动申请证书Traefik实现自动申请HTTPS证书要使用Let’s Encrypt自动生成证书，需要使用ACME。需要在静态配置中定义 “证书解析器”，Traefik负责从ACME服务器中检索证书。 然后，每个 “路由器 “被配置为启用TLS，并通过tls.certresolver配置选项与一个证书解析器关联。 Traefik的ACME验证方式主要有以下三种： tlsChallenge httpChallenge dnsChallenge 如果使用tlsChallenge，则要求Let’s Encrypt到 Traefik 443 端口必须是可达的。如果使用httpChallenge，则要求Let’s Encrypt到 Traefik 80端口必须是可达的。如果使用dnsChallenge，则需要对应的providers。 部署cert-manager借助 Kubernetes，我们获得了一个强大且可扩展的平台来解决许多复杂的场景。cert-manager是一个功能强大的解决方案，可以帮助我们自动化和管理与 TLS 证书相关的几乎所有内容。它提供了一套针对各种场景的 ...
简介traefik 的路由规则就可以实现 4 层和 7 层的基本负载均衡操作，使用 IngressRoute IngressRouteTCP IngressRouteUDP 资源即可。但是如果想要实现 加权轮询、流量复制 等高级操作，traefik抽象出了一个 TraefikService 资源。此时整体流量走向为：外部流量先通过 entryPoints 端口进入 traefik，然后由 IngressRoute/IngressRouteTCP/IngressRouteUDP 匹配后进入 TraefikService，在 TraefikService 这一层实现加权轮循和流量复制，最后将请求转发至kubernetes的service。 除此之外traefik还支持7层的粘性会话、健康检查、传递请求头、响应转发、故障转移等操作。 灰度发布官方文档 Traefik2.0 的一个更强大的功能就是灰度发布，灰度发布也称为金丝雀发布（Canary），主要就是让一部分测试的服务也参与到线上去，经过测试观察看是否符号上线要求。 比如现在我们有两个名为 appv1 和 appv2 ...
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 仪表板，以及预配置的 ...
