Istio-限流配置

Istio Envoy Proxy 在微服务架构中，系统通常会通过 Istio IngressGateway 对外提供统一入口。当系统流量突然增加（例如活动流量、爬虫攻击、接口被刷等情况）时，如果没有限流机制，后端服务可能会出现以下问题： * 接口被高频调用，导致服务 CPU 或数据库压力过大 * 突发流量导致系统雪崩或级联故障 * 某些核心 API 被恶意刷接口，影响正常用户访问 因此，需要在 网关层统一进行限流控制，在请求进入后端服务之前进行流量治理。 Istio 基于 Envoy Proxy 实现流量管理能力，可以通过 Envoy RateLimit + Redis 实现全局限流，对特定接口或路径进行访问频率控制。 什么时候会用到 Istio 限流 通常在以下场景中会配置 Istio 限流 /api/login /api/send-code /api/
— 6 min read

Polaris Mesh

PolarisMesh 提供了完整的微服务治理能力，是腾讯开源的一站式云原生服务治理平台。平台围绕 服务注册与发现、流量治理、容错保护以及配置管理 等核心能力，为微服务架构提供稳定可靠的运行基础。通过 PolarisMesh，服务实例可以自动完成注册与发现，同时结合智能负载均衡策略，实现请求在多实例之间的合理分配，从而提升系统整体的稳定性与吞吐能力。 PolarisMesh支持多语言、多框架的云原生服务治理平台 服务管理、流量管理、故障容错、配置管理、可观测性 GitHub 查看文档 立即体验 一站式服务治理平台 北极星为服务治理提供一站式解决方案，覆盖服务注册中心、服务网格和配置中心的功能，提供业务监控、流量监控、事件中心和操作记录等全方位的可观测性能力，帮助用户快速构建微服务架构。 支持异构技术栈和环境 通过 Proxyless 和 Proxy 两种形态实现服务发现和治理，提供多语言 SDK、开发框架、Java Agent 和网格代理等接入方式，支持虚拟机、容器和混合云等部署环境，满足不同业务场景和开发模式。 支持常用开发框架 提供
— 6 min read

阿里 ask 集群

前言 阿里云ASK（Alibaba Cloud ACK）集群是阿里云提供的托管式Kubernetes服务。它基于开源的Kubernetes项目，为用户提供了一个简便易用、弹性伸缩、高可用性和安全可靠的容器化部署和管理平台，相当于无服务器Kubernetes容器服务。您无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划，并且根据应用配置的CPU和内存资源量进行按需付费。ASK集群提供完善的Kubernetes兼容能力，同时降低了Kubernetes使用门槛，让您更专注于应用程序，而不是管理底层基础设施。 什么是容器服务 Serverless 版ACK Serverless_容器服务 Kubernetes 版 ACK-阿里云帮助中心本文介绍阿里云容器服务 Serverless 版的产品简介、核心优势、与ACK集群对比、应用场景、核心功能等信息，帮助您快速了解ACK Serverless集群。 ASK集群中的Pod基于阿里云弹性容器实例ECI运行在安全隔离的容器运行环境中。每个Pod容器实例底层通过轻量级虚拟化安全沙箱技术完全强隔离，容器实例间互不影响。 A
— 4 min read

初探 Server-Mesh

前言 本次技术分享只做技术宏观思维与认知上的分享，具体配置细节与部署不在此次讨论范围。 讨论点： 1、微服务的局限性 2、了解 Server-Mesh 功能与实现方式 3、目前基于 Server-Mesh 而实现的 Serverless 我们最熟悉，最常用的 Java，Spring-Cloud，Spring-Cloud-Alibaba 等技术体系，归属于传统微服务的架构设计，此设计存在SDK强耦合问题，每次底层SDK版本的更新极大可能影响到业务层面的服务稳定性。SDK与代码环境强耦合，就会存在居多限制，不能完整的运用市面上不同语言与其对应的生态组件来做更擅长的领域，例如：灵活快速的Go，Python语言并对应其携程，爬虫，神经网络等等组件。严谨并且0垃圾回收的Rust语言，更适合企业级中间件高效率低内存占用场景。所以每种语言有它各自的优势与生态环境，以更长远的发展来看，大体量的龙头企业将会把业务部署与实现落地到不同的语言上进行迭代是一种趋势。 传统微服务体系图： 并且如今JVM引以为傲的跨操作系统优势，其特性也被K8S，Docker，Containerd，CRI-O，K
— 19 min read

安全容器运行时 Kata

前言 传统的轻量级容器是基于Linux namespace和cgroup进行容器隔离，在带来轻量，简洁，高效的同时，也带来了安全的隐患。 事实上容器虽然提供一个与系统中的其它进程资源相隔离的执行环境，但是与宿主机系统是共享内核的，如果其中某一个容器被攻击，从而导致把宿主机的内核给攻掉了，那么其他的容器势必都会崩溃。后果不堪设想。 那么有没有什么容器技术及安全又比较高效率的呢？于是便出现了 Kata 容器技术。 Kata Containers - Open Source Container Runtime SoftwareKata Containers is an open source container runtime, building lightweight virtual machines that seamlessly plug into the containers ecosystem.An OpenInfra Project Kata 实际上是通过创建轻量级虚拟机实现容器之间的资源隔离，再在虚拟机中运行容器运行时，这样就使容器在专用内核中运行，
— 4 min read

Istio 之流量镜像

通过在k8s集群中部署Istio作为Service Mesh架构，利用它本身的Envoy代理转发流量的特性，轻松的支持了流量镜像的功能，只需要在配置文件中简单加上几个配置即可完成流量镜像，此功能非常强大，如用得当可以更好的服务生产环境的业务需求。流量镜像也被称作影子流量，把客户端打入的请求进行复制并转发到其他容器进行处理，但镜像的流量不会响应数据给客户端，如此一来流量镜像的价值就变得非常清晰，我们可以用流量镜像做数据记录，风控分析，线上异常操作跟踪，并且对于原来的业务代码是完全透明的，毕竟在流量进入容器前已经进行了流量的镜像，并通过部署其他容器服务进行处理。极大的增强了业务的横向扩展能力。 镜像此任务演示了 Istio 的流量镜像/影子功能。Istio阅读大约需要 3 分钟 页面测试 针对流量镜像的典型的使用场景： 1、测试环境：测试版本的容器服务可以使用生产实例的真实流量，不会影响正常生产的关键路径。例如预发布环境就可以更好的进行实时测试校验，减少发布后出现的各种异常情况，给开发团队更好的上线信心 😂，上线几乎可以做到清晰明了，不用熬夜加班发版。 2、数据采集：同步收集请求
— 2 min read

Helm 包管理工具

众所周知，k8s可以在多个node节点上管理容器资源，但每个容器需要对应的pod-yaml文件来进行管理。 我们先说问题：如果在一个namespace中有几十个pod需要进行配合部署，例如 mysql 集群，kafka集群，但部署kafka集群又需要先部署 zookeeper集群，应用程序又需要Redis 集群，以及一些MQ队列集群，还有应用程序自身的部署，微服务可能多达50-100个甚至更多的应用。 这样的场景让你来写 yaml 配置文件 我想你可能是拒绝的，就算你部署了一次，好不容易部署完成了，但异地机房集群还要再次部署怎么办? 更何况怎么做到多个不同机房中集群的配置信息完全一致？ 所以这里的问题很明显了，我们需要一个可以集中管理所有 yaml 配置文件并且可以复用的工具。 于是 Helm 就诞生了，他的定位类似于 CentOS 中的 Yum 包管理工具，又或者是 Debian中的 apt 包管理工具，只不过这次的包管理是基于 k8s 环境。 Heml 中的每个包都称为一个Chart，一个Chart是一个目录。 应用发布者可以通过Helm打包应用，管理应用依赖关系，管理
— 2 min read

Kubernetes Pod Yaml文件解析

此文件相关配置查询(此文件只做参考,以查询为准) kubectl explain 为文档查询命令如：kubectl explain pod.spec.volumes apiVersion: v1 //版本 kind: pod //类型，pod metadata: //元数据 name: String //元数据，pod的名字 namespace: String //元数据，pod的命名空间 labels: //元数据，标签列表 - name: String //元数据，标签的名字 annotations: //元数据,自定义注解列表 - name: String //元数据,自定义注解名字 spec: //pod中容器的详细定义 containers: //pod中的容器列表，可以有多个
— 5 min read

Kubernetes 部署 Istio

前言 kubernetes 虽然已经解决了运维上的大部分问题，拥有着优秀的自动运维机制。例如：动态扩容，调度，镜像管理，容器宕机重启，计算节点监控等问题。但k8s在应用层上的监控与流量管理，应用之间的相互调用调用协调，注册中心，配置中心等功能并未提供。 于是便出现了基于Service-Mech架构的代表产品Istio。 Istio 是 Google、IBM、Lyft 三家联合开发的框架，主要作用于在 k8s 环境中微服务之间流量控制、连接、保护、设置和观测服务。使得我们开发微服务时可以抛弃掉繁琐、复杂、维护性低、强耦合性的底层微服务SDK。 Istio架构 在架构上Istio分为数据平面与控制平面。 数据平面的核心思维就是Sidecar（边车模式），在同一个pod中，添加proxy代理容器，接管我们的业务容器流量，在不对业务代码有任何入侵的前提下，从而实现各种功能，例如：负载均衡、流量加密、监控、策略（灰度发布、蓝绿发布）、熔断、降级、远程服务调用、
— 5 min read

kubectl 常用命令

kubectl --help ：帮助信息 kubectl delete Deployments -n <命名空间> kubectl get nodes ：查看集群节点数 kubectl get pod -n <命名空间> ：查看对应命名空间下pod信息 kubectl get pods -A 查看所有pod kubectl get namespace ：查看命名空间 kubectl get pod --all-namespace 查看所有命名下的pod kubectl apply -f ：应用pod配置文件，设置资源 kubectl delete -f ：取消应用pod配置文件，删除资源 kubectl create 通过yaml/json 文件或者标准输入创建一个资源对象 kubectl drain
— 1 min read

K8S Kubeadm 搭建流程

前言 将最近搭建的K8S流程，以及遇到的部分问题，作为笔记进行记录。 部署环境 搭建版本：kubernetes-1.24.4 （HA） 容器运行时：containerd-1.6.8 操作系统：CentOS7 前置条件 1、集群节点计算资源必须是2h-cpu 2g-ram以上的机器，节点内网或公网需要可达。 2、每个机器的hostname，mac地址不能相同，唯一性product_uuid，通过hostname可以访问对应节点，需要配置/etc/hosts文件。 3、kubernates 1.24版本后默认的容器运行时不再使用Docker，改为 Containerd 容器运行时，如果需要使用docker则需要安装cri-dockerd。 4、 HA架构必须存在3个master控制平面节点，架构如下图：（高可用分为堆叠etcd，外部etcd）。 外部etcd 优点：其中失去控制平面实例或者 etcd 成员的影响较小，并且不会像堆叠的 HA
— 11 min read

关于Serverless架构

背景 Serverless（无服务器架构）近年来逐渐成为云计算领域的一个热门方向。它的核心理念是：开发者无需关心服务器的部署、运维和扩容，只需要专注于业务逻辑的开发。 在传统架构中，一个系统上线通常需要准备服务器、部署环境、配置网络、监控资源以及处理扩容问题，这些工作都需要额外的运维成本。而在 Serverless 架构中，这些基础设施全部由云厂商负责管理，开发者只需要编写函数代码并部署即可运行。 Serverless上云 Serverless 通常以 云函数（Function as a Service，FaaS） 的形式提供。例如阿里云函数计算（FC）、AWS Lambda、腾讯云 SCF 等。开发者只需要上传代码，当有请求触发时，平台会自动运行函数，并根据实际的调用次数和运行时间进行计费。 这种模式带来的最大变化是：应用可以按需运行，而不是长期占用服务器资源。 例如在一些业务场景中： * 定时任务处理 * Webhook 事件触发 * 图片处理 * 数据转换 这些任务并不需要持续运行的服务器，
— 4 min read

K3S 集群搭建

最近学习了K8S集群的部署，期间使用了很多的部署方式，例如官方给出的 kubeadm [https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/] 工具，青云的KK工具一键部署，也有github上开源免费或收费的一键部署工具，都尝试过，但最后选择了K3S-up [https://github.com/alexellis/k3sup] 来进行集群的部署。 相对于K8S来说，K3S系统容器数量少，轻量级，并且默认使用 containerd 作为容器运行时，内部的 ingress 使用的是 go 语言开发的 traefik，集成了SQLite 代替 Etcd，但在多个master节点中最好使用 Etcd 组件，来保证数据一致性，从而可以HA。 本次搭建选用阿里云6台共享性服务器。 3台master（2核4g） 3台worker（2核4g） 并搭建
— 3 min read

随心笔记

技术无止境 创新不停驻