江中散人
在移动前端、微服务后端均有五年+的研发实施与团队管理经验,秉持着“云原生体系是信息科技驱动业务与第三代企业管理变革的终极解决方案”理念,对运用云原生体系(云/容器、微服务、DevOps)推动企业数字化转型(运维、研发、研发管理三位一体)的落地推进形成了一整套成体系的方案落地与转型推进思路,当选CNCF、信通院、华为云牵头组织的全球性云原生专业交流组织创原会2022年度MVP,排名第7位(7/31/308).擅长技术积淀与培训分享,相关技术博客积累超10年,技术领域涵盖云原生(容器/计算/存储/网络/微服务/DevOps)、产品设计、IOS开发、Android开发、Hybrid混合开发等领域
展开
-
【云原生进阶之容器】第六章容器网络6.5.3--Calico安装与部署
Typha:在节点数比较多的情况下,Felix可通过Typha直接和Etcd进行数据交互,不通过kube-apiserver,既降低其压力。创建 /etc/NetworkManager/conf.d/calico.conf 文件可以防止 NetworkManager 干扰接口。Calico v3.24 支持的(测试过的) k8s 版本有:v1.22, v1.23, v1.24。//由于我的环境是kube-router需要将以前的数据清理下,如果遇到问题需要清理也可以按照如下步骤。原创 2023-04-18 18:00:00 · 345 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.7.1--阿里云Terway网络模式综述
Terway是阿里云开源的基于专有网络VPC的容器网络接口CNI(Container Network Interface)插件,支持基于Kubernetes标准的网络策略来定义容器间的访问策略,开源地址:https://github.com/AliyunContainerService/terway。您可以通过使用Terway网络插件实现Kubernetes集群内部的网络互通。本文介绍如何使用阿里云容器服务Kubernetes版ACK集群的Terway网络插件。原创 2023-04-21 18:00:00 · 563 阅读 · 1 评论 -
【云原生进阶之容器】第六章容器网络6.6.2--Cilium部署
部署Cilium非常简单,可以通过单独的yaml文件部署全部组件(目前我使用了这个方式部署了1.7.1版本),也可以通过Helm Chart一键完成。重要的是部署环境和时机:官方建议所有部署节点都使用Linux最新稳定内核版本,这样所有的功能都能启用。作为一个Kubernetes网络组件,它应该在部署Kubernetes其他基础组件之后,才进行部署。原创 2023-04-20 18:00:00 · 505 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.6.1--Cilium网络方案概述
Cilium作为一款Kubernetes CNI插件,从一开始就是为大规模和高度动态的容器环境而设计,并且带来了API级别感知的网络安全管理功能,通过使用基于Linux内核特性的新技术——BPF,提供了基于Service/Pod/Container作为标识,而非传统的IP地址,来定义和加强容器和Pod之间网络层、应用层的安全策略。因此,Cilium不仅将安全控制与寻址解耦来简化在高度动态环境中应用安全性策略,而且提供传统网络第3层、4层隔离功能,以及基于http层上隔离控制,来提供更强的安全性隔离。原创 2023-04-19 18:00:00 · 484 阅读 · 1 评论 -
【云原生进阶之容器】第六章容器网络6.5.2--Calico网络架构详述
Calico最优先的网络设置是使用BGP与物理网络对等的Non-overlay网络模式,实现Pod IP可在集群外部路由。如果无法将BGP对等连接到物理网络,但集群位于独立的L2网络中,也可以运行Non-overlay模式,只是在集群中的节点之间对等BGP,应用外部缺少Pod IP的路由,无法在集群外路由。或者设置为Overlay模式下的VXLAN或IP-in-IP,并使用跨子网Overlay模式来优化L2子网内的性能。原创 2023-04-17 18:00:00 · 542 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.5.1--Calico网络方案综述
Calico是一个用于容器、虚拟机和基于本地主机的工作负载的开源网络和网络安全解决方案。Calico支持广泛的平台,包括Kubernetes、OpenShift、Docker EE、OpenStack和bare metal服务。Calico将灵活的网络功能与随处运行的安全实施相结合,提供了一个具有本地Linux内核性能和真正的云本地可伸缩性的解决方案。原创 2023-04-16 18:00:00 · 491 阅读 · 1 评论 -
【云原生进阶之容器】第六章容器网络6.4.3--Flannel网络模式
Flannel通过在每一个节点上启动一个叫做flanneld的进程,负责每一个节点上的子网划分,并将相关的配置信息(如各个节点的子网网段、外部IP等)保存到etcd中,而具体的网络包转发交给具体的backend实现。flanneld可以在启动时通过配置文件指定不同的backend进行网络通信,Flannel支持三种backend:UDP、VXLAN、host-gw。目前VXLAN是官方最推崇的一种backend实现方式;host-gw一般用于对网络性能要求比较高的场景,但需要基础网络架构的支持。原创 2023-04-15 17:30:00 · 756 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.4.2--Flannel的安装与部署
本篇将着重介绍Flannel的安装与部署,以及常见操作命令原创 2023-04-14 18:00:00 · 421 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.4.1--Flannel组网方案综述
Flannel是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络(Overlay Network)工具,其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网。这次的分享内容将从Flannel的介绍、工作原理及安装和配置三方面来介绍这个工具的使用方法。原创 2023-04-13 18:00:00 · 469 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.3--CNI及各CNI网络解决方案简述
CNI是Container Network Interface的缩写,是一个标准的通用的接口。linux 容器技术和容器网络不断发展,以适应在不同环境中运行的各种应用程序的需求。为了在一端实现各种网络解决方案与另一端不同容器运行时和容器编排平台之间的集成,而不是重复使网络可插入的努力,容器网络接口 ( CNI ) 的创建是为了在容器执行和网络层之间定义一个标准化的通用接口。CNI 项目是云原生计算基金会 (CNCF) 的一部分,其规范描述了如何为 Linux 容器配置网络接口。原创 2023-04-08 17:00:00 · 474 阅读 · 0 评论 -
【云原生进阶之容器】第六章容器网络6.2--K8S网络模型
一个K8S集群的网络通讯,主要涉及以下4个方面的通信:1. 容器与容器之间的直接通信;2. Pod与Pod之间的通信;3. Pod到Service之间的通信;4. 集群外部与内部组件之间的通信。原创 2023-04-07 18:30:00 · 425 阅读 · 4 评论 -
【云原生进阶之容器】第六章容器网络6.1--Docker网络模型
Docker实现的容器技术中,针对网络这一块他抽象出一个模型来,就叫CNM(Container Networking Model),相当于只实现了一个框架,具体的实现可以使用原生Docker的,也可以自己实现然后接入本框架。其中libnetwork是Docker团队将Docker的网络功能从Docker的核心代码中分离出来形成的一个单独的库,libnetwork通过插件的形式接入CNM为Docker提供网络功能。原创 2023-04-06 18:30:00 · 335 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.6--容器运行时之gVisor
gVisor是一款新型容器沙箱解决方案,其能够为容器提供安全的隔离措施,同时继续保持远优于虚拟机的轻量化特性。gVisor能够与Docker及Kubernetes实现集成,从而在生产环境中更轻松地建立起沙箱化容器系统。原创 2023-04-05 18:30:00 · 404 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.5--容器运行时之Kata Containers
Kata Containers是一个新的开源项目,它提供了与虚拟机工作负载隔离的Linux容器的速度和性能。它被设计为与OCI镜像兼容的体系结构,并与Kubernetes的容器运行时接口(CRI)兼容。Kata Containers托管在Apache 2许可下的Github上,并由OpenStack基金会管理。Kata Container项目是两个现有的开源项目合并——Intel Clear Containers和Hyper runV。原创 2023-04-04 18:30:00 · 557 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.8--容器热迁移
容器使用 CRIU (Checkpoint Restore in Userspace)技术进行容器的迁移,它是一个 Linux 软件工具,使用此工具,可以冻结正在运行的应用程序,并将其导出为磁盘上的文件集合。然后,可以使用这些文件来恢复应用程序,恢复之后程序和被冻结的时候状态一致。使用 Checkpoint 和 Restore 功能,将进程组(传统容器从本质上来讲就是系统中的一个或者一组进程)冻结与恢复。原创 2023-04-12 18:00:00 · 517 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.7--容器逃逸原理
容器逃逸,是指“流氓”容器尝试突破正常隔离环境限制,借助一些手段获得容器所在的直接宿主机、宿主机上的其他容器或集群内其他主机、其他容器的某种权限下的命令执行能力,进行恶意攻击或执行越权访问的行为。容器逃逸漏洞可能打穿容器节点,甚至整个集群。原创 2023-04-11 18:30:00 · 695 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.4--容器运行时之Firecracker
AWS 开源了 Firecracker,一种利用 KVM 的新虚拟化技术,专门用于创建和管理多租户容器以及基于函数的服务。你可以在几分之一秒内在非虚拟化环境中启动轻量级微虚拟机(microVM),充分利用传统虚拟机提供的安全性和工作负载隔离,同时兼具容器的资源效率。Firecracker 是一种采用基于 Linux 内核的虚拟机 (KVM) 技术的开源虚拟机监控程序(VMM)。Firecracker 允许您创建微型虚拟机,即 microVM。Firecracker 坚持精简主义的设计原则,原创 2023-04-03 18:30:00 · 336 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.3.2--runC原理解读
runC可以启动并管理符合OCI标准的容器。简单地说,runC需要利用OCI bundle创建一个独立的运行环境,并执行指定的程序。在Linux平台上,这个环境就是指各种类型的Namespace以及Capability等等配置。runC由Go语言实现,当前(2018.12)最新版本是v1.0.0-rc6,代码的结构可分为两大块,一是根目录下的go文件,对应各个runC命令,二是负责创建/启动/管理容器的libcontainer,可以说runC的本质都在libcontainer。原创 2023-04-02 18:30:00 · 377 阅读 · 1 评论 -
【云原生进阶之容器】第五章容器运行时5.3.1--runC简介与使用
随着容器技术发展的愈发火热,Linux基金会于2015年6月成立OCI(Open Container Initiative)组织,旨在围绕容器格式和运行时制定一个开放的工业化标准。该组织一成立便得到了包括谷歌、微软、亚马逊、华为等一系列云计算厂商的支持。而runC就是Docker贡献出来的,按照该开放容器格式标准(OCF, Open Container Format)制定的一种具体实现。原创 2023-04-01 18:30:00 · 694 阅读 · 0 评论 -
【云原生布道系列】第三篇:“软”饭“硬”吃的计算
援引一段《虚拟化技术发展编年史》中针对虚拟化技术的定义:在计算机科学中,虚拟化技术(Virtualization)是一种资源管理(优化)技术,将计算机的各种物理资源(例如CPU、内存、磁盘空间,以及网络适配器等 I/O 设备)予以抽象、转换,然后呈现出一个可供分割并任意组合为一个或多个(虚拟)计算机的配置环境。虚拟化技术打破了计算机内部硬件实体结构不可分割的物理障碍,使用户能够以更灵活、更精细化的配置方式来使用硬件资源,即现下常提到的硬件变的软件“可定义”了。原创 2023-03-31 18:00:00 · 891 阅读 · 0 评论 -
【云原生进阶之容器】第五章容器运行时5.2节--容器运行时接口规范CRI
在 CRI 出现之前,Docker 作为第一个容器运行时,Kubelet 通过内嵌的 dockershim 操作 Docker API 来操作容器,进而达到一个面向终态的效果。在这之后,又出现了一种新的容器运行时rkt与hyber.sh。于是便有了将容器运行时的操作抽象出一个接口,将 Kubelet 代码与具体的容器运行时的实现代码解耦开,这就是Container Runtime Interface (CRI)。原创 2023-04-01 18:30:00 · 448 阅读 · 5 评论 -
【云原生进阶之容器】第五章容器运行时5.1节--容器运行时总述
容器运行时接口(CRI),顾名思义,用来在 Kubernetes 扩展容器运行时,从而用户可以选择自己喜欢的容器引擎。CRI 是基于 gPRC 的,用户不需要关心内部通信逻辑,而只需要实现定义的接口就可以,包括RuntimeService和ImageService: RuntimeService负责管理Pod和容器的生命周期,而ImageService负责镜像的生命周期管理。CRI 的推出为容器社区带来了新的繁荣,cri-o、frakti、cri-containerd 等一系列容器运行时为不同场景而生。原创 2023-01-16 18:00:00 · 1062 阅读 · 0 评论 -
【云原生进阶之容器】第四章Operator原理4.4节--Operator深入实践
Operator-SDK 是 Operator Framework 的组件,用于创建 Kubernetes 本机应用程序所需的代码。Operator Framework 是一个开放源代码工具包,使用有效、自动化和可扩展的方式管理 Kubernetes 本地应用程序。原创 2023-01-15 18:00:00 · 1186 阅读 · 0 评论 -
【云原生进阶之容器】第四章Operator原理4.3节--Operator模式
Kubernetes Operator概念是由CoreOS的工程师于2016年提出的,它是在Kubernetes集群上构建和驱动每个应用程序的高级原生方法,需要特定领域的知识。通过与Kubernetes API的密切合作,它提供了一种一致的方法来自动处理所有应用程序操作流程,而无需任何人工响应。换句话说,Operator是打包,运行和管理Kubernetes应用程序的一种方式。原创 2023-01-14 18:00:00 · 1069 阅读 · 0 评论 -
【云原生进阶之容器】第四章Operator原理4.2节--CRD
CRD全称是CustomResourceDefinition,在Kubernetes 中一切都可视为资源,Kubernetes 1.7 之后增加了对 CRD 自定义资源二次开发能力来扩展 Kubernetes API,通过 CRD 我们可以向 Kubernetes API 中增加新资源类型,而不需要修改 Kubernetes 源码来创建自定义的 API server,该功能大大提高了 Kubernetes 的扩展能力。原创 2023-01-13 18:00:00 · 1148 阅读 · 0 评论 -
【云原生进阶之容器】第四章Operator原理4.1节--定制资源(Custom Resource)
资源(Resource)是Kubernetes API中的一个端点, 其中存储的是某个类别的API 对象的一个集合。 例如内置的Pod资源包含一组 Pod 对象。定制资源(Custom Resource)是对 Kubernetes API 的扩展,不一定在默认的 Kubernetes 安装中就可用。 定制资源所代表的是对特定 Kubernetes 安装的一种定制。不过,很多 Kubernetes 核心功能现在都用定制资源来实现,这使得 Kubernetes 更加模块化。原创 2023-01-12 18:00:00 · 1141 阅读 · 0 评论 -
【云原生进阶之容器】第三章List-Watch机制3.1节-- List-Watch机制剖析
Kubernetes 是通过 List-Watch 的机制进行每个组件的协作,保持数据同步的,每个组件之间的设计实现了解耦。用户是通过 kubectl 根据配置文件,向 APIServer 发送命令,在 Node 节点上面建立 Pod 和 Container。APIServer 经过 API 调用,权限控制,调用资源和存储资源的过程,实际上还没有真正开始部署应用。这里需要 Controller Manager、Scheduler 和 kubelet 的协助才能完成整个部署过程。原创 2023-01-11 18:00:00 · 582 阅读 · 0 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.8节--Resync机制
为什么需要 Resync 机制呢?因为在处理 SharedInformer 事件回调时,可能存在处理失败的情况,定时的 Resync 让这些处理失败的事件有了重新 onUpdate 处理的机会。主要的目的是为了不丢数据,处理 resync 机制还有边缘触发与水平获取的设计,一起来保证不丢事件、数据同步并能及时响应事件。原创 2023-01-10 18:00:00 · 467 阅读 · 0 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.7节--Indexer剖析
Indexer是client-go用来存储资源对象并自带索引功能的本地存储,Reflector从DeltaFIFO中将消费出来的资源对象存储至Indexer。Indexer中的数据与Etcd集群中的数据保持完全一致。client-go可以很方便地从本地存储中读取相应的资源对象数据,而无须每次都从远程Etcd集群中读取,这样可以减轻Kubernetes API Server和Etcd集群的压力。原创 2023-01-09 18:00:00 · 603 阅读 · 0 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.6节--Informer controller
DeltaFIFO 是一个非常重要的组件,真正让他发挥价值的,便是 Informer 的 controller。虽然 Kubernetes 源码中的确用的是 controller 这个词,但是此 controller 并不是 Deployment Controller 这种资源控制器。而是一个承上启下的事件控制器(从 API Server 拿到事件,下发给 Informer 进行处理)。原创 2023-01-08 18:00:00 · 720 阅读 · 0 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.5节--DeltaFIFO剖析
DeltaFIFO是K8s中用来存储处理数据的Queue,相较于传统的FIFO,它不仅仅存储了数据保证了先进先出,而且存储有K8s 资源对象的类型,它的作用是保证Reflector和Indexer之间对象同步。其是连接Reflector(生产者)和indexer(消费者)的重要通道。原创 2023-01-06 18:00:00 · 1912 阅读 · 2 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.4节--Informer机制剖析
client-go 包中一个非常核心的工具就是 informer,informer 可以让与 kube-apiserver 的交互更加优雅。Informer 另外一块内容在于提供了事件 handler 机制,并会触发回调,这样 Controller 就可以基于回调处理具体业务逻辑。原创 2023-01-05 21:10:06 · 527 阅读 · 0 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.3节--Reflector分析
Reflector 是保证 Informer 可靠性的核心组件,在丢失事件,收到异常事件,处理事件失败等多种异常情况下需要考虑的细节很多。单独的listwatcher缺少重新连接和重新同步机制,有可能出现数据不一致问题。其对事件响应是同步的,如果执行复杂的操作会引起阻塞,需要引入队列。Reflector可以成为反射器,将etcd中的数据反射到存储(DeltaFIFO)中。Reflector通过其内部的List操作获取所有资源对象数据,保存到本地存储,之后Watch监视资源变化,触发对应事件处理。原创 2023-01-04 00:07:17 · 1298 阅读 · 1 评论 -
【云原生进阶之容器】第二章Controller Manager原理2.2节--client-go剖析
Kubernetes 官方从 2016 年 8 月份开始,将 Kubernetes 资源操作相关的核心源码抽取出来,独立出来一个项目 client-go,Kubernetes中使用client-go作为Go语言的官方编程式交互客户端库,提供对api server服务的交互访问。原创 2022-12-30 18:00:00 · 822 阅读 · 1 评论 -
【云原生进阶之容器】第二章——Kubernetes概述
kubernetes,是一个全新的基于容器技术的分布式架构领先方案,是谷歌严格保密十几年的秘密武器--Borg系统的一个开源版本,于2014年9月发布第一个版本,2015年7月发布第一个正式版本,简称k8s。其提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理 / 虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。原创 2022-12-23 18:00:00 · 501 阅读 · 0 评论 -
【云原生进阶之容器】第二章Controller Manager原理剖析--2.1节Controller Manager综述
一般来说,智能系统和自动系统通常会通过一个“操作系统”不断修正系统的工作状态。在Kubernetes集群中,每个Controller都是这样的一个"操作系统",它们通过APIServer 提供的(List-Watch)接口实时监控集群中特定资源的状态变化,当发生各种故障导致某资源对象的状态变化时,Controller会尝试将其状态调整为期望的状态。Controller Manager是Kubernetes中各种操作系统的管理者,是集群内部的管理控制中心,也是Kubernetes自动化功能的核心。原创 2022-12-28 21:42:24 · 547 阅读 · 2 评论 -
【云原生进阶之容器】第一章Docker核心技术1.10节——Docker网络模型设计
Docker实现的容器技术中,针对网络这一块他抽象出一个模型来,就叫CNM(Container Networking Model),相当于只实现了一个框架,具体的实现可以使用原生Docker的,也可以自己实现然后接入本框架。其中libnetwork是Docker团队将Docker的网络功能从Docker的核心代码中分离出来形成的一个单独的库,libnetwork通过插件的形式接入CNM为Docker提供网络功能。原创 2022-12-22 18:00:00 · 1148 阅读 · 1 评论 -
【云原生进阶之容器】第一章Docker核心技术1.8节——DockerFile解析
Dockerfile 是一个文本文件,其内包含了一条条的指令(Instruction),每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。有了 Dockerfile,当我们需要定制自己额外的需求时,只需在 Dockerfile 上添加或者修改指令,重新生成 image 即可,省去了敲命令的麻烦。原创 2022-12-20 18:00:00 · 424 阅读 · 0 评论 -
【云原生进阶之容器】第一章Docker核心技术1.9节——docker-compose容器编排
Compose是用来编排和管理多容器应用的工具,使用它,你可以通过定义一个YAML文件来定义你的应用的所有服务,然后通过一条命令,你就可以创建并启动所有的服务。原创 2022-12-21 18:00:00 · 289 阅读 · 0 评论 -
【云原生进阶之容器】第一章Docker核心技术1.7节——Docker镜像技术剖析
镜像就是一个可执行独立运行的软件包,包含应用运行所必须的文件和依赖包。镜像可以理解为类或者模板,只要在容器的环境下开箱即用。docker镜像是采用分层的方式构建的,每个镜像都由一系列的"镜像层"组成。分层结构是docker镜像如此轻量的重要原因。当需要修改容器镜像内的某个文件时,只对处于最上方的读写层进行变动,不覆写下层已有文件系统的内容,已有文件在只读层中的原始版本仍然存在,但会被读写层中的新版本所隐藏。原创 2022-12-19 18:15:00 · 621 阅读 · 0 评论