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分为数据平面与控制平面。 数据平面的核心思维就是Sidecar(边车模式),在同一个pod中,添加proxy代理容器,接管我们的业务容器流量,在不对业务代码有任何入侵的前提下,从而实现各种功能,例如:负载均衡、流量加密、监控、策略(灰度发布、蓝绿发布)、熔断、降级、远程服务调用、配置中心、注册中心等常用的微服务功能(但不负责分布式事务的管理,这个按道理确实也不属于Istio应该接管的范畴)。 控制平面则负责管理和配置代理来路由流量。此外控制平面配置
5 min read

kubectl 常用命令

kubectl --help :帮助信息 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 驱逐节点pod kubectl describe 显示一个或多个资源对象的详细信息 kubectl logs
1 min read

K8S Kubeadm 搭建流程

搭建版本: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 [https://github.com/Mirantis/cri-dockerd]。 4、 HA架构必须存在3个master控制平面节点,架构如下图:(高可用分为堆叠etcd,外部etcd)。 外部etcd 优点:其中失去控制平面实例或者 etcd 成员的影响较小,并且不会像堆叠的
11 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

随心笔记

hi 欢迎留言,共同探讨IT技术~