Polaris Mesh

PolarisMesh是腾讯开源的一款用于构建微服务架构的组件，它提供了一种轻量级、高性能的服务网格解决方案。基于Go语言开发，对比同类产品Nacos，其功能的完善度，产品交互的体验上来说完善度要高上不少，并且对云原生的支持更加友好，微服务可以进行 无SDK集成接入。 PolarisMesh一个支持多语言、多框架的云原生服务发现和治理中心, 提供高性能SDK和无侵入Sidecar两种接入方式PolarisMesh 微服务治理 PolarisMesh提供了丰富的微服务治理功能，包括服务注册与发现、负载均衡、流量控制、熔断降级、服务限流等。这些功能可以帮助开发者更好地管理和控制微服务之间的通信和交互。 高性能代理 PolarisMesh内置了高性能的代理组件，可以实现快速的请求转发和响应处理。通过使用该代理，可以减少网络延迟，提高系统的吞吐量和响应速度。 多协议支持 PolarisMesh支持多种常见的通信协议，如HTTP、gRPC等，使得不同类型的微服务可以无缝地进行通信。这样，您可以选择适合您应用程序需求的协议，而不需要进行繁琐的配置和集成工作。
— 2 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

随心笔记

技术无止境 创新不停驻