日志收集架构日志对于调试问题和监视集群情况也是非常有用的。而且大部分的应用都会有日志记录，对于传统的应用大部分都会写入到本地的日志文件之中。对于容器化应用程序来说则更简单，只需要将日志信息写入到 stdout 和 stderr 即可，容器默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件之中，同样也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。 但是，通常来说容器引擎或运行时提供的功能不足以记录完整的日志信息，比如，如果容器崩溃了、Pod 被驱逐了或者节点挂掉了，仍然也希望访问应用程序的日志。所以，日志应该独立于节点、Pod 或容器的生命周期，这种设计方式被称为 cluster-level-logging，即完全独立于 Kubernetes 系统，需要自己提供单独的日志后端存储、分析和查询工具。 Kubernetes 日志收集Kubernetes 集群本身不提供日志收集的解决方案，一般来说有主要的 3 种方案来做日志收集： 在每个节点上运行的节点级日志收集代理。 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器 ...

Prometheus简介Prometheus 最初是 SoundCloud 构建的开源系统监控和报警工具，是一个独立的开源项目，于 2016 年加入了 CNCF 基金会，作为继 Kubernetes 之后的第二个托管项目。Prometheus 相比于其他传统监控工具主要有以下几个特点： 具有由 metric 名称和键/值对标识的时间序列数据的多维数据模型 有一个灵活的查询语言 不依赖分布式存储，只和本地磁盘有关 通过 HTTP 的服务拉取时间序列数据 也支持推送的方式来添加时间序列数据 还支持通过服务发现或静态配置发现目标 多种图形和仪表板支持 Prometheus 由多个组件组成，但是其中有些组件是可选的： Prometheus Server：用于抓取指标、存储时间序列数据 exporter：暴露指标让任务来抓 pushgateway：push 的方式将指标数据推送到该网关 alertmanager：处理报警的报警组件 adhoc：用于数据查询 大多数 Prometheus 组件都是用 Go 编写的，因此很容易构建和部署为静态的二进制文件。下图是 Prometheu ...

APISIX高级使用Apache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能、可扩展的微服务 API 网关，目前已经是 Apache 顶级项目。提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B 测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等。可以使用 APISIX 来处理传统的南北流量以及服务之间的东西向流量。 重定向-redirect官方文档 现在当我们访问 http://whoami.boysec.cn/tls 或者 http://whoami.boysec.cn/tls/ 的时候都可以得到正常的结果，一般来说我们可能希望能够统一访问路径，比如访问 /tls 子路径的时候可以自动跳转到 /tls/ 以 Splash 结尾的路径上去。同样要实现该需求我们只需要使用一个名为 redirect 的插件即可，该插件是 URI 重定向插件，可配置的属性如下所示： 名称 类型 必选项 默认值 有效值 描述 http_to_https boolean 否 false ...

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 ...