互联网服务发展至今，作为开发者阵营的我们，已经用实践证明了前后端分离开发模式正在逐渐成为越来越多互联网公司构建服务和应用的方式。 前后端分离优势多多，其中一个很重要的优势是：对于后台服务（系统）来讲，只需提供一套统一的API接口，可被多个客户端所复用，分工和协作被细化，大大提高了效率。 与此同时带来的一些副作用便是： 接口文档管理混乱。之前很多公司管理API接口，有用Wiki的，有Word文档的，有Html的，经常遇到问题是接口因变了，比如增加参数，参数名变了，参数被删除了等都没有及时更新文档的情况 接口测试没有保障。毕竟前端开发依赖后端接口，如果前后端开发不同步，接口及时测试成了问题，因此需要随时提供一套可用的API接口数据测试服务。 资源分散，难以共享。每个开发者维护自己的一套测试接口集合，无法共用他人接口集合，开发过程中充斥着大量重复造数据、填接口的工作，效率不高 其他问题。除此之外还有可能碰到诸如 文档导出、接口分类规划、操作便利性等一系列问题。 基于此情况，因此本文接下来就来推荐几个常用的 API管理系统，帮助前后端分离开发模式下提升效率和可靠性，我想总有一个适合阁下吧☁️ Swagger Swagger 是一种用于描述、构建和可视化 RESTful API 的开源工具集。它提供了一系列功能，包括 API 文档自动生成、API 调试和可视化等。下面是使用 Swagger 的一般步骤： 定义 API 规范：使用 Swagger 规范（通常是 OpenAPI 规范）编写 API 的定义和描述。这些规范使用 YAML 或 JSON 格式表示，并描述了 API 的路径、参数、操作、响应等信息。 编写 Swagger 文档：根据 API 的定义和描述编写 Swagger 文档。您可以使用 Swagger 编辑器或其他文档工具来创建和编辑 Swagger 文档。 自动生成文档：使用 Swagger 工具和插件，将 Swagger 文档与代码（如后端服务代码）集成在一起，并生成 API 文档。这些工具可以根据 Swagger 文档自动生成可交互式的 API 文档和UI界面。 调试和测试：使用 Swagger 提供的内置功能，可以在 Swagger UI 中直接进行 API 调试和测试。通过 Swagger UI，您可以轻松地发送请求，查看响应并检查请求和响应的详细信息。 项目地址： 点我进入 ...

OpenEBS存储使用 OpenEBS 是一种模拟了 AWS 的 EBS、阿里云的云盘等块存储实现的基于容器的存储开源软件。OpenEBS 是一种基于 CAS(Container Attached Storage) 理念的容器解决方案，其核心理念是存储和应用一样采用微服务架构，并通过 Kubernetes 来做资源编排。其架构实现上，每个卷的 Controller 都是一个单独的 Pod，且与应用 Pod 在同一个节点，卷的数据使用多个 Pod 进行管理。 OpenEBS 有很多组件，可以分为以下几类： 控制平面组件 - 管理 OpenEBS 卷容器，通常会用到容器编排软件的功能 数据平面组件 - 为应用程序提供数据存储，包含 Jiva 和 cStor 两个存储后端 节点磁盘管理器 - 发现、监控和管理连接到 Kubernetes 节点的媒体 与云原生工具的整合 - 与 Prometheus、Grafana、Fluentd 和 Jaeger 进行整合。 控制平面 OpenEBS 上下文中的控制平面是指部署在集群中的一组工具或组件，它们负责： 管理 kubernetes 工作节点上可用的存储 配置和管理数据引擎 与 CSI 接口以管理卷的生命周期 与 CSI 和其他工具进行接口，执行快照、克隆、调整大小、备份、恢复等操作。 集成到其他工具中，如 Prometheus/Grafana 以进行遥测和监控 集成到其他工具中进行调试、故障排除或日志管理 OpenEBS 控制平面由一组微服务组成，这些微服务本身由 Kubernetes 管理，使 OpenEBS 真正成为 Kubernetes 原生的。由 OpenEBS 控制平面管理的配置被保存为 Kubernetes 自定义资源。控制平面的功能可以分解为以下各个阶段： ...

Traekfik是什么 Traefik 是一种开源 边缘路由器，它使您发布服务成为一种有趣而轻松的体验。它代表您的系统接收请求并找出哪些组件负责处理它们。 Traefik 的与众不同之处在于，除了它的许多功能之外，它还可以自动为您的服务发现正确的配置。当 Traefik 检查您的基础架构时，奇迹就会发生，它会在其中找到相关信息并发现哪个服务服务于哪个请求。 Traefik 原生兼容所有主要的集群技术，例如 Kubernetes、Docker、Docker Swarm、AWS、Mesos、Marathon，等等；并且可以同时处理很多。（它甚至适用于在裸机上运行的遗留软件。） 使用 Traefik，无需维护和同步单独的配置文件：一切都自动实时发生（无需重启，无连接中断）。使用 Traefik，您可以花时间为系统开发和部署新功能，而不是配置和维护其工作状态。 边缘路由器 Traefik 是一个Edge Router，这意味着它是您平台的大门，它拦截并路由每个传入请求：它知道确定哪些服务处理哪些请求的所有逻辑和每条规则（基于path，host，标头，等等…）。 自动服务发现 传统上边缘路由器（或反向代理）需要一个配置文件，其中包含到您的服务的每条可能路径，Traefik 从服务本身获取它们。部署您的服务，您附加信息告诉 Traefik 服务可以处理的请求的特征。 首先，当启动 Traefik 时，需要定义 entrypoints（入口点），然后，根据连接到这些 entrypoints 的路由来分析传入的请求，来查看他们是否与一组规则相匹配，如果匹配，则路由可能会将请求通过一系列中间件转换过后再转发到你的服务上去。在了解 Traefik 之前有几个核心概念我们必须要了解： Providers 用来自动发现平台上的服务，可以是编排工具、容器引擎或者 key-value 存储等，比如 Docker、Kubernetes、File Entrypoints 监听传入的流量（端口等…），是网络入口点，它们定义了接收请求的端口（HTTP 或者 TCP）。 Routers 分析请求（host, path, headers, SSL, …），负责将传入请求连接到可以处理这些请求的服务上去。 Services 将请求转发给你的应用（load balancing, …），负责配置如何获取最终将处理传入请求的实际服务。 Middlewares 中间件，用来修改请求或者根据请求来做出一些判断（authentication, rate limiting, headers, …），中间件被附件到路由上，是一种在请求发送到你的服务之前（或者在服务的响应发送到客户端之前）调整请求的一种方法。 部署Traefik Traefik的配置可以使用两种方式：静态配置和动态配置 静态配置：在 Traefik 中定义静态配置选项有三种不同的、互斥的即你只能同时使用一种）方式。 在配置文件中 在命令行参数中 作为环境变量 动态配置：Traefik从提供者处获取其动态配置：无论是编排器、服务注册表还是普通的旧配置文件。 # 使用Helm的方式进行部署Traefik2.9.x [root@Online-Beijing-master1 ~]# helm repo add traefik https://traefik.github.io/charts [root@Online-Beijing-master1 ~]# helm repo update [root@Online-Beijing-master1 yaml]# helm fetch traefik/traefik [root@Online-Beijing-master1 yaml]# tar -zxf traefik-21.1.0.tgz 修改一下value.yaml中的部分内容，改动大概如下部分的内容 deployment: initContainers: # The "volume-permissions" init container is required if you run into permission issues. # Related issue: https://github.com/traefik/traefik/issues/6825 - name: volume-permissions image: busybox:1.35 command: ["sh", "-c", "touch /data/acme.json && chmod -Rv 600 /data/* && chown 65532:65532 /data/acme.json"] volumeMounts: - name: data mountPath: /data websecure: port: 8443 hostPort: 443 expose: true exposedPort: 443 protocol: TCP web: port: 8000 hostPort: 80 expose: true exposedPort: 80 protocol: TCP service: enabled: false ingressRoute: dashboard: enabled: false nodeSelector: node.kubernetes.io/traefik-manager: 'true' tolerations: - key: "node-role.kubernetes.io/master" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" 创建一个traefik-v2的名称空间 [root@Online-Beijing-master1 yaml]# kubectl create ns traefik-v2 部署Traefik [root@Online-Beijing-master1 yaml]# helm install traefik ./traefik -f ./traefik/values.yaml --namespace traefik-v2 [root@Online-Beijing-master1 yaml]# kubectl get pods traefik-67b8896675-4xdrx -n traefik-v2 -o yaml 其中 entryPoints 属性定义了 web 和 websecure 这两个入口点的，并开启 kubernetesingress 和 kubernetescrd 这两个 provider，也就是我们可以使用 Kubernetes 原本的 Ingress 资源对象，也可以使用 Traefik 自己扩展的 IngressRoute 这样的 CRD 资源对象 ...

本地存储 前面我们有通过 hostPath 或者 emptyDir 的方式来持久化我们的数据，但是显然我们还需要更加可靠的存储来保存应用的持久化数据，这样容器在重建后，依然可以使用之前的数据。但是存储资源和 CPU 资源以及内存资源有很大不同，为了屏蔽底层的技术实现细节，让用户更加方便的使用，Kubernetes 便引入了 PV 和 PVC 两个重要的资源对象来实现对存储的管理。 PersistentVolume PV 的全称是：PersistentVolume（持久化卷），是对底层共享存储的一种抽象，PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS、hostPath 等，都是通过插件机制完成与共享存储的对接。 PersistentVolumeClaim PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。 但是通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求，而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了，此外 StorageClass 还可以为我们自动生成 PV，免去了每次手动创建的麻烦。 HostPath 我们上面提到了 PV 是对底层存储技术的一种抽象，PV 一般都是由管理员来创建和配置的，我们首先来创建一个 hostPath 类型的 PersistentVolume。Kubernetes 支持 hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟附带网络的存储，但是需要注意的是在生产集群中，我们不会使用 hostPath，集群管理员会提供网络存储资源，比如 NFS 共享卷或 Ceph 存储卷，集群管理员还可以使用 StorageClasses 来设置动态提供存储。因为 Pod 并不是始终固定在某个节点上面的，所以要使用 hostPath 的话我们就需要将 Pod 固定在某个节点上，这样显然就大大降低了应用的容错性。 ...

<!doctype html> 十七孔桥1 十七孔桥 嘎嘎牛快艇1 嘎嘎牛快艇2

什么是Ingress Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。 Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。 下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例： Ingress 其实就是从 Kuberenets 集群外部访问集群的一个入口，将外部的请求转发到集群内不同的 Service 上，其实就相当于 nginx、haproxy 等负载均衡代理服务器，可能你会觉得我们直接使用 nginx 就实现了，但是只使用 nginx 这种方式有很大缺陷，每次有新服务加入的时候怎么改 Nginx 配置？不可能让我们去手动更改或者滚动更新前端的 Nginx Pod 吧？那我们再加上一个服务发现的工具比如 consul 如何？貌似是可以，对吧？Ingress 实际上就是这样实现的，只是服务发现的功能自己实现了，不需要使用第三方的服务了，然后再加上一个域名规则定义，路由信息的刷新依靠 Ingress Controller 来提供。 Ingress Controller 可以理解为一个监听器，通过不断地监听 kube-apiserver，实时的感知后端 Service、Pod 的变化，当得到这些信息变化后，Ingress Controller 再结合 Ingress 的配置，更新反向代理负载均衡器，达到服务发现的作用。其实这点和服务发现工具 consul、 consul-template 非常类似。 现在可以供大家使用的 Ingress Controller 有很多，比如 traefik、nginx-controller、Kubernetes Ingress Controller for Kong、HAProxy Ingress controller，当然你也可以自己实现一个 Ingress Controller，现在普遍用得较多的是 traefik 和 nginx-controller，traefik 的性能较 nginx-controller 差，但是配置使用要简单许多，我们这里会重点给大家介绍 nginx-controller 以及 traefik 的使用。 ...

如果在集群规模较大并发较高的情况下我们仍然需要对 DNS 进行优化，典型的就是大家比较熟悉的 CoreDNS 会出现超时5s的情况。 超时原因 在 iptables 模式下（默认情况下），每个服务的 kube-proxy 在主机网络名称空间的 nat 表中创建一些 iptables 规则。 比如在集群中具有两个 DNS 服务器实例的 kube-dns 服务，其相关规则大致如下所示： (1) -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES <...> (2) -A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU <...> (3) -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-LLLB6FGXBLX6PZF7 (4) -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -j KUBE-SEP-LRVEW52VMYCOUSMZ <...> (5) -A KUBE-SEP-LLLB6FGXBLX6PZF7 -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.32.0.6:53 <...> (6) -A KUBE-SEP-LRVEW52VMYCOUSMZ -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.32.0.7:53 我们知道每个 Pod 的 /etc/resolv.conf 文件中都有填充的 nameserver 10.96.0.10 这个条目。所以来自 Pod 的 DNS 查找请求将发送到 10.96.0.10，这是 kube-dns 服务的 ClusterIP 地址。 由于 (1) 请求进入 KUBE-SERVICE 链，然后匹配规则 (2)，最后根据 (3) 的 random 随机模式，跳转到 (5) 或 (6) 条目，将请求 UDP 数据包的目标 IP 地址修改为 DNS 服务器的实际 IP 地址，这是通过 DNAT 完成的。其中 10.32.0.6 和 10.32.0.7 是我们集群中 CoreDNS 的两个 Pod 副本的 IP 地址。 ...

使用Kubeadm创建一个高可用的Etcd集群 默认情况下，kubeadm 在每个控制平面节点上运行一个本地 etcd 实例。也可以使用外部的 etcd 集群，并在不同的主机上提供 etcd 实例。 这两种方法的区别在 高可用拓扑的选项 页面中阐述。 这个任务将指导你创建一个由三个成员组成的高可用外部 etcd 集群，该集群在创建过程中可被 kubeadm 使用。 准备开始 三个可以通过 2379 和 2380 端口相互通信的主机。本文档使用这些作为默认端口。不过，它们可以通过 kubeadm 的配置文件进行自定义。 每个主机必须安装 systemd 和 bash 兼容的 shell。 每台主机必须安装有容器运行时、kubelet 和 kubeadm 每个主机都应该能够访问 Kubernetes 容器镜像仓库 (registry.k8s.io)， 或者使用 kubeadm config images list/pull 列出/拉取所需的 etcd 镜像。 本指南将把 etcd 实例设置为由 kubelet 管理的静态 Pod。 一些可以用来在主机间复制文件的基础设施。例如 ssh 和 scp 就可以满足需求。 本次容器运行时采用Containerd作为Runtime 将Kubelet配置为Etcd的服务启动管理器 你必须在要运行 etcd 的所有主机上执行此操作。 cat << EOF > /usr/lib/systemd/system/kubelet.service.d/20-etcd-service-manager.conf [Service] ExecStart= ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock Restart=always EOF 启动kubelet ...

ConfigMap ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pods 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。 ConfigMap 将你的环境配置信息和 容器镜像 解耦，便于应用配置的修改。 ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过1MiB(这其实是ETCD的要求哈哈哈)。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷 或者使用独立的数据库或者文件服务。 这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是 配置的片段格式。 通过Key和Value这种键值对来进行写入数据 apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # 类属性键；每一个键都映射到一个简单的值 player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # 类文件键,一般用来保存一个文件到指定目录 game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true 你可以使用四种方式来使用 ConfigMap 配置 Pod 中的容器： 在容器命令和参数内 容器的环境变量 在只读卷里面添加一个文件，让应用来读取 编写代码在 Pod 中运行，使用 Kubernetes API 来读取 ConfigMap 通过环境变量的方式使用ConfigMap 首先我们创建一个Deployment然后通过Env环境变量的方式进行使用ConfigMap ...

HorizontalPodAutoscaler HPA官方文档 在Kubernetes 中HorizontalPodAutoscaler自动更新工作负载资源 （例如 Deployment 或者 StatefulSet）， 目的是自动扩缩工作负载以满足需求。 水平扩缩意味着对增加的负载的响应是部署更多的 Pod。 这与垂直(Vertical)扩缩不同，对于 Kubernetes， 垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。 如果负载减少，并且Pod的数量高于配置的最小值，HorizontalPodAutoscaler 会指示工作负载资源（Deployment、StatefulSet 或其他类似资源）缩减。 水平Pod自动扩缩不适用于无法扩缩的对象: 例如DemonSet这种 我们可以简单的通过 kubectl autoscale 命令来创建一个 HPA 资源对象，HPA Controller默认30s轮询一次（可通过 kube-controller-manager 的--horizontal-pod-autoscaler-sync-period 参数进行设置），查询指定的资源中的 Pod 资源使用率，并且与创建时设定的值和指标做对比，从而实现自动伸缩的功能。 HorizontalPodAutoscaler 是如何工作的 Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 参数设置（默认间隔为 15 秒）。 在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 控制器管理器找到由 scaleTargetRef 定义的目标资源，然后根据目标资源的 .spec.selector 标签选择 Pod， 并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标） 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，控制器获取每个 Pod 中的容器资源使用情况， 并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。 接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。 如果 Pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用原始值，而不是使用率。 如果 Pod 使用对象指标和外部指标（每个指标描述一个对象信息）。 这个指标将直接根据目标设定值相比较，并生成一个上面提到的扩缩比例。 在 autoscaling/v2 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。 HorizontalPodAutoscaler的常见用途是将其配置为从聚合 API （metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io）获取指标。 metrics.k8s.io API 通常由名为Metrics Server的插件提供，需要单独启动。有关资源指标的更多信息， 请参阅 Metrics Server。 ...