LinkinStar's Blog

在 k8s 中当我们需要持久化存储一些数据的使用，会使用到的就是 PV 和 PVC，但 PV 和 PVC 都是需要手动创建的话会很麻烦，特别是当有 StatefulSet 应用存在的时候，如果你需要手动对每个 pod 都创建一个 PVC 和 PV 就非常麻烦，于是 StorageClass 就是来解决这个问题的。 准备首先你需要一个 nfs 或其他存储，这里我以 nfs 为例进行部署 我们先来梳理一下思路和几个需要的东西： nfs 是我们最终的存储 nfs-client 是用来动态创建 pv 和 pvc 的，我们称为 provisioner StorageClass 关联到对应的 provisioner 就可以使用 statefulset（或别的资源）需要配置 storageClassName 进行使用 部署创建 ServiceAccount创建对应需要使用的 ServiceAccount，因为需要操作 pv 和 pvc 123456789101112131415161718192021222324252627282930313233343536373839404142apiVe ...

每次当我们发布新版本的时候总是慌兮兮，一方面是担心有 bug，另一方面其实重启应用会带来一些抖动，可能有几秒钟或者几个请求的不正常，从而担心用户在这段时间内的操作。那么如何在应用重启的过程中尽可能的保证不会带来抖动，从而平滑又优雅的重启呢？ 本文只针对于应用版本更新时，进行版本发布时进行的重启操作，从而导致的相关问题的解决。不涉及由于应用本身 panic 导致的重启，也不涉及蓝绿发布或回滚等操作。当前版本更新是在 k8s 中进行的重启操作，访问负载均衡交由 k8s 的 service 处理，再上层的网关层面的负载则不在本次讨论范围内。 通过本文你可以学到： go 应用优雅退出所需要做的事情 go 应用优雅退出 k8s 所需要的配置 k8s 应用关闭时 pod 的生命周期 测试程序先写一个最简单的测试程序（当然有很多压测工具都能满足需求，但是我还是想自己弄个最简单的，不想搞复杂），当然这个测试程序不能满足所有使用场景和情况，如并发的一些场景等，只是为了展现出固定的问题。 1234567891011121314151617181920212223242526272829package ...

很早之前我有写过有关 defer 的博客，现在看来起标题的时候有点蠢，有点标题党，(https://www.linkinstars.com/post/48e6221e.html) 其中主要是注重与 defer 的使用，避免使用上的问题，对于 defer 具体实现其实只是点了一下，而今天就让我们详细看看 defer 究竟是如何实现的。 前置知识点 在阅读本文之前你可能需要有两个基础知识前提 defer 的基本使用规则 逃逸分析：https://www.linkinstars.com/post/1ceb1a77.html 函数调用规约：https://www.linkinstars.com/post/fecd400.html 因为在 1.14 之后 defer 是有优化过的(https://golang.org/doc/go1.14#runtime)，所以需要注意，本文使用的 go 版本是 1.17 引子问题 编译器是如何处理 defer 关键字的？ defer 的执行顺序是怎么样实现的？ defer 数据结构首先我们来看看 defer 究竟是长什么样子 12345678910 ...

函数调用规约？如果你是第一次听到这个名词可能会有疑惑，这是在说什么？难道两个函数之间调用还需要约定什么吗？难道不是定好入参出参就可以了吗？没错函数的调用规约其实就是：我在调用其他函数的时候我的参数和返回值要如何分布？ 那么其实在 golang 底层函数的调用还是有很多细节的，比如你的入参放在哪里？返回值存放在哪里？相信看完这篇你就都明白了。 栈 首先我们定一下基调，因为我们今天讨论的是函数调用规约，所以我们今天的主角是栈，没有堆什么事，也就是说，所有变量都默认分配在栈上，不考虑逃逸的情况 栈的样子先来看看我们今天主角的样子： 我们今天说的要说的栈，其实应该叫调用栈 call stack 而不是我们平常说的数据结构中栈。栈的增长方向是从高位地址到地位地址向下进行增长的，栈底是我们的高地址，而栈顶是我们的低地址，栈的作用是存放程序执行过程中使用的局部变量。 调用规约说简单也简单，说复杂也复杂，这里准备由浅入深，首先用一张图来直接描述 go 里面的函数调用规约究竟是怎么样的 左边是调用者栈情况，右边是被调用者栈情况 可以看到调用者栈里有本地的一些变量、当前调用函数的返回值、调用函数 ...

在 go 中当我们需要延迟一段时间后执行，或者需要间隔固定时间去执行某个行为的时候就需要使用到 timer，那么 timer 到底是如何实现的呢？我们今天就来看看 timer 里面是什么样的。 同时因为 1.14 版本前后 timer 的实现有很大的区别，我们顺便来了解一下之前的版本和现在的版本有什么样的不一样，到底做了什么样的优化。 前置知识点有以下的知识点支持才能更好的理解今天的分析 需要有 GMP 模型的基础 需要有 go 调度相关的基础 需要有数据结构中’堆‘的基础 ticker要看 timer 可以先从 ticker 入手，ticker 其实我们经常使用到，ticker 顾名思义就是每次间隔一段时间触发一次，下面我们就来看看它的具体实现 带着问题 Ticker 如果当前时间到了，没有及时处理，下一次时间到了，会保留吗？是都在后面排队，还是直接被丢弃了？ NewTicker() 和 Tick() 有什么区别？使用上需要注意什么？ 数据结构123456// A Ticker holds a channel that delivers ``ticks'' ...

sync.Cond 作为 go 标准库提供的一个并发原语，但是可能你从来没听过，可见它使用场景挺少的，但是我们需要有这个知识储备，只有储备了之后才能在需要用的时候用出来。 其实如果你之前和我一样接触过 java，那么其实对于这个并发原语其实应该很熟悉，其实就是常说的等待通知机制，也就是 wait 方法和 notify 方法。 使用我们首先从使用的角度的出发，先来看看 cond 是如何使用的 三个方法首先我用最白话的方式描述一下 cond 的三个方法 Wait 当前调用者等待执行，直到被唤醒，调用该方法时需要加锁 Signal 唤醒一个调用者 Broadcast 唤醒所有调用者 一把锁一个队列cond 初始化需要传入一个锁，用于并发控制，调用 wait 的时候需要加锁 cond 内部维护着一个队列，等待调用者排队等待 使用我们创建两个 goroutine 使用 cond 等待执行任务，然后使用 signal 方法唤醒试试 123456789101112131415161718192021222324252627282930package mainimport ( "f ...

你在实际业务中是否有遇到过下面这样的场景： 订单十分钟没有支付，自动取消 用户注册成功后无任何操作，一天后自动提醒 预定票之后，在出发之前的一天自动提醒用户 这样类似的场景经常会发生在实际的业务中，它们总有一个共性，就是当前并不是马上触发，而是需要过一段时间才进行触发，当触发时间到达时才进行具体的执行。那么问题就来了，为了实现这样的功能，我们如何更加灵活的实现呢？ 为什么使用延迟队列我们以 订单十分钟过期 场景举例： 方案 1：为当前订单创建一个定时器，定时器时间到了之后自动去查询当前订单状态，如果没有支付，则进行取消操作 方案 2：设定一个总的定时器，每一分钟检查一次，当检查发现过期的订单就直接进行取消操作 方案 3：如果你有一个延迟队列，你只需将任务丢进去，等到了对应的时间，这个任务会出队，然后出队的时候进行订单过期时间判断 方案比较正所谓抛弃场景谈方案都是耍流氓：我的观点也很明确，这三种方案都有自己所试用的场景。 方案 1如果全局只有一个用户，并且这个订单又是那种量比较小的，可能每天有个 30 个已经撑死了，这样的后台的系统，可能都谈不上需要高可用的情况，那么方案 ...

之前我们解决了跨主机间容器间通信的问题，但是这也只能说我们铺好了路，村里通路了，但是其实作为 k8s 来说，还有好多其他的问题等待着我们解决。今天我们就通过这些问题来看看 k8s 的 CNI 的设计。CNI 到底究竟是个什么东西，到底是不是和你想的一样那么困难。 问题IP 分配我们知道 k8s 整个集群里面有许多的 pod 那么 IP 怎么分配呢？总不能分配着之后出现 IP 冲突了吧。k8s 集群里面是不是能不有一个类似 DHCP 的东西来管这个 IP 地址分配呢？ 流量转发当流量打到宿主机上时，应该有一个什么设备来快速将请求转到对应的 pod 才对吧？那么谁来做这个事情呢？ 那为了解决上面的问题，我们一步步出发。 k8s 网络模型首先有关 k8s 的网络模型，官网有下面的描述：（https://kubernetes.io/zh/docs/concepts/cluster-administration/networking/） 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有Pod通信 备 ...

你是否之前看过 k8s 的网络部分，第一次看是否会觉得很困难？或者说你有没有想过为什么 k8s 要这样设计它的网络，跨主机之间的网络通信究竟是怎么实现的？今天就来搞一篇干货，其实想写这个很久了，但是一直拖延症，这次正好碰到了一个新的点想让我仔细重新审视一下。 本文可能需要你有以下知识基础： docker基本原理 k8s基本架构 网络基础知识 本文不想引出过多细节的概念，因为网络本身确实有很多细节，每一个细节其实都可以写一篇，如果篇幅过长就会让人觉得没有重点，于是本文的重点将会放在从外部的大视角来看跨主机的网络通信，其中的细节先挖坑，后面慢慢填。 引子问题我们知道 k8s 往往会有很多主机进行集群的部署，k8s 要管理很多 pod，而这些 pod 里面有很多容器，每个容器都是一个小的服务，服务与服务之间往往需要互相访问，而 pod 并不总是在同一宿主机上，那么问题来了：k8s 是如何做到让服务之间能够互相访问的呢？这里网络的链路到底是怎么走的？ 时刻记住，本文将围绕这个问题展开。 假设和思考如果说每个容器都绑定一个宿主机的端口来进行通信，那么一旦容器很多就要占用非常多的宿主机的端 ...

我们知道 golang 的 map 并发会有问题，所以 go 官方在 sync 包中加入了一个 sync.map 来作为一个官方的并发安全的 map 实现。 如果你了解过 java 中常用的一个并发安全的 map 叫做 ConcurrentHashMap 就会知道它有两个亮点设计：一是当链表长度过长的时候会转换为红黑树的实现，还有一个就是分段锁。得益于这两个设计也导致 java 中实现的代码非常复杂，偷笑。 那么 go 里面是如何设计的呢？今天我们就来看看它是怎么实现的。 PS: 本文 go 源码基于版本1.16.2，我觉得当有了泛型之后这个库十有八九是要改的…. 数据结构定义123456type Map struct { mu Mutex read atomic.Value // readOnly dirty map[interface{}]*entry misses int} 123456// readOnly is an immutable struct stored atomically in the Map.r ...