Klog

由于收到某退役学长的鞭策，忽然就想学习一丢数论 来补充一下虎哥基础数论中没有出现的东西 本文转载须联系作者，并标明出处 定义 Miller-Rabin素数测试，又称米勒-拉宾素性检验，是一种素数判定法则，利用随机化算法判断一个数是合数还是可能是素数。 卡内基梅隆大学的计算机系教授Gary Lee Miller首先提出了基于广义黎曼猜想的确定性算法，由于广义黎曼猜想并没有被证明，其后由以色列耶路撒冷希伯来大学的Michael O. Rabin教授作出修改，提出了不依赖于该假设的随机化算法。（摘自百度百科） 用处&背景 根据上面的定义可以显然的看到，这个算法的主要目的就是进行单个素数的判定 在前期学习当中，我们也学习过单个素数的判定 复杂度为 \(O(\sqrt n)\) ，代码如下 bool isPrime(int x) { if (x < 2) return false; for (int i = int(sqrt(x+0.5)); i >= 2; --i) { if (x % i == 0) return false; } return true; } 那么利用Miller-Rabin（简称MR）算法 还有优秀的龟速乘（快速加）以及快速幂 复杂度可以达到O(klog_n) MR的复杂度在百科中给出了一大堆 \(log\) 像这样： 使用快速傅里叶变换能够将这个时间推进到 \(O

由于收到某退役学长的鞭策，忽然就想学习一丢数论 来补充一下虎哥基础数论中没有出现的东西 本文转载须联系作者，并标明出处 定义 Miller-Rabin素数测试，又称米勒-拉宾素性检验，是一种素数判定法则，利用随机化算法判断一个数是合数还是可能是素数。 卡内基梅隆大学的计算机系教授Gary Lee Miller首先提出了基于广义黎曼猜想的确定性算法，由于广义黎曼猜想并没有被证明，其后由以色列耶路撒冷希伯来大学的Michael O. Rabin教授作出修改，提出了不依赖于该假设的随机化算法。（摘自百度百科） 用处&背景 根据上面的定义可以显然的看到，这个算法的主要目的就是进行单个素数的判定 在前期学习当中，我们也学习过单个素数的判定 复杂度为 \(O(\sqrt n)\) ，代码如下 bool isPrime(int x) { if (x < 2) return false; for (int i = int(sqrt(x+0.5)); i >= 2; --i) { if (x % i == 0) return false; } return true; } 那么利用Miller-Rabin（简称MR）算法 还有优秀的龟速乘（快速加）以及快速幂 复杂度可以达到O(klog_n) MR的复杂度在百科中给出了一大堆 \(log\) 像这样： 使用快速傅里叶变换能够将这个时间推进到 \(O

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 导读： 描述“富者愈富，穷者愈穷”的马太效应，以及经济学中的帕累托法则，其背后的数学模型是什么？在统计学中，它们可以被抽象成幂律分布。 我们在城市规模中看到的模式：大多数人类居住地区的规模达不到以百万来计数，但少数地区能达到数百万人规模。在数字王国里，大多数网站的访问量很低，但少数网站的访问量非常庞大。在文学领域，大多数书籍几乎无人阅读，但少数书籍畅销异常。 所有这些都让我们回忆起“富者愈富，穷者愈穷”的现象。 在语言学中，这种现象被称为Zipf定律，以哈佛的语言学家George Kingsley Zipf的名字命名，他观察到在一种语言中第i位最常见的单词出现的频率正比于1/i。Zipf定律指出，在一个n个单词的语料库中，遇到第i位最常见单词的概率为 数Hn在数学领域出现非常频繁，值得为它起一个名字——第n位调和数（harmonic number）。这个名字源自何处？它源于音乐中的泛音或称和声。一根弦以一个基波长震动，同时还以1/2，1/3，1/4，…的谐波长震动：这对应一个无穷和，当n=∞时，它被称为调和级数（harmonic series）。 由于Zipf定律给出了一个事件的概率，因此也用它命名了对应的概率分布。 在表11-1中，你可以看到一个英语语料库（布朗语料库

【题解】【原创题目】薇尔莉特 出题人： 辰星凌 验题人：无 题目传送门： 薇尔莉特 【题目描述】 给出一个 \(n\) 行 \(m\) 列的矩阵（最初全为 \(0\) ），有 \(T\) 个操作，每次操作选出一个子矩阵，将其中的所有元素都对 \(x\) 进行一次 \(or\) ，求最后的矩阵。 【分析】 【Solution #1】 纯暴力，没有坑点，按照题意模拟一下就可以了。 时间复杂度： \(O(Tn^2)\) 。 分数： \(20pt\) 。 【Code #1】 #include<algorithm> #include<iostream> #include<cstdio> #define Re register int #define LL long long using namespace std; const int N=503,P=1e9+7; int n,m,a,b,c,d,x,T,HYJ,Ans1,Ans2,A[N][N]; inline void in(Re &x){ int f=0;x=0;char c=getchar(); while(c<'0'||c>'9')f|=c=='-',c=getchar(); while(c>='0'&&c<='9')x=(x<<1)+(x<<3)+(c^48),c=getchar(); x=f?-x:x; } int main()

我们通过 kubectl describe [资源] 命令，可以在看到Event输出，并且经常依赖event进行问题定位，从event中可以分析整个POD的运行轨迹，为服务的客观测性提供数据来源，由此可见，event在Kubernetes中起着举足轻重的作用。 event并不只是kubelet中都有的，关于event的操作被封装在 client-go/tools/record 包，我们完全可以在写入自定义的event。 现在让我们来一步步揭开event的面纱。 <a name="EBJdC"></a> Event定义 其实event也是一个资源对象，并且通过apiserver将event存储在etcd中，所以我们也可以通过 kubectl get event 命令查看对应的event对象。 以下是一个event的yaml文件： apiVersion: v1 count: 1 eventTime: null firstTimestamp: "2020-03-02T13:08:22Z" involvedObject: apiVersion: v1 kind: Pod name: example-foo-d75d8587c-xsf64 namespace: default resourceVersion: "429837" uid: ce611c62-6c1a-4bd8-9029

昨天我们介绍了k8s中资源插件机制的核心关键组件，今天我们继续来看下各个组件是如何进行通信的，以及k8s中针对事件处理背后的关键设计 1.PluginManager PluginManager是一个上层组件，其内部包含了上篇文章中的关键组件，并且协调其内部数据流，而且还提供针对不同插件的具体的控制器 1.1 核心数据结构 核心结构里面其实就是按照数据流来进行设计的，首先需要一个感知插件desiredStateOfWorldPopulator用于感知后端服务的创建或者删除，然后将感知到的事件加入到desiredStateOfWorld期望状态缓存，由reconciler负责期进行底层的注册和下线，并且将结果存储到actualStateOfWorld实际状态缓存 type pluginManager struct { // 插件感知 desiredStateOfWorldPopulator *pluginwatcher.Watcher // 协调器插件 reconciler reconciler.Reconciler // 实际状态缓存 actualStateOfWorld cache.ActualStateOfWorld // 期望状态缓存 desiredStateOfWorld cache.DesiredStateOfWorld } 1.2 初始化

PLEG(PodLifecycleEventGenerator)主要是用于周期性检测Pod的运行状态，从而对比Pod前后状态生成事件从而触发kubelet进行Pod容器状态的校证,让我们一起来初探下其内部实现机制 1. 图解设计 1.1 Pod事件生成 Pod事件生成主要是根据对应Pod前后的状态对比来实现，首先通过runtime来获取当前节点的所有Pod的列表，并将对应的状态进行保存，这样在下一个轮训周期就可以通过前后状态的对比去发现状态发生改变的Pod的容器，并且产生对应的事件 1.2 事件通知与状态同步 Pod事件生成之后会通过管道将对应的事件同步给状态同步线程，状态同步线程感知到Pod的变更事件后，会与Pod的目标状态进行对比同步，并调用Runtime来进行最终校证操作的执行，同时在下个轮询周期中又会重新从Runtime获取状态，从而不断校证Pod的状态，直至目标状态 2. Pod记录 Pod记录其实就是一个map，并通过podRecord来保存前后轮询周期Runtime返回的Pod的信息 type podRecord struct { old *kubecontainer.Pod current *kubecontainer.Pod } type podRecords map[types.UID]*podRecord 3. Pod事件生成器 3.1 获取Pod状态

在Kubernetes中，通常kube-schduler和kube-controller-manager都是多副本进行部署的来保证高可用，而真正在工作的实例其实只有一个。这里就利用到 leaderelection 的选主机制，保证leader是处于工作状态，并且在leader挂掉之后，从其他节点选取新的leader保证组件正常工作。 不单单只是k8s中的这两个组件用到，在其他服务中也可以看到这个包的使用，比如 cluster-autoscaler 等都能看得到这个包的，今天就来看看这个包的使用以及它内部是如何实现的。 <a name="u0Ihj"></a> 使用 以下是一个简单使用的例子，编译完成之后同时启动多个进程，但是只有一个进程在工作，当把leader进程kill掉之后，会重新选举出一个leader进行工作，即执行其中的 run 方法： /* 例子来源于client-go中的example包中 */ package main import ( "context" "flag" "os" "os/signal" "syscall" "time" "github.com/google/uuid" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" clientset "k8s.io/client-go/kubernetes" "k8s

kubernetes调度器之前已经分析过SchedulerCache、ScheduleAlgorithm、SchedulerExtender、Framework等核心数据结构，也分析了优选、调度、抢占流程的核心实现，本文是本系列目前打算的最后一章, 也是当前阶段对调度的学习的一个总结 整个系列文档我已经已经更新到语雀上了地址是，谢谢大家分享加微信一起交流 https://www.yuque.com/baxiaoshi/tyado3/ 1. Binder Binder负责将调度器的调度结果，传递给apiserver,即将一个pod绑定到选择出来的node节点 1.1 构建binder 在scheduler/factory中会构建一个默认的binder func getBinderFunc(client clientset.Interface, extenders []algorithm.SchedulerExtender) func(pod *v1.Pod) Binder { defaultBinder := &binder{client} return func(pod *v1.Pod) Binder { for _, extender := range extenders { if extender.IsBinder() && extender.IsInterested(pod)

k8s目前主要支持CPU和内存两种资源，为了支持用户需要按需分配的其他硬件类型的资源的调度分配，k8s实现了设备插件框架(device plugin framework)来用于其他硬件类型的资源集成，比如现在机器学习要使用GPU等资源，今天来看下其内部的关键实现 1. 基础概念 1.1 集成方式 1.1.1 DaemonSet与服务 当我们要集成本地硬件的资源的时候，我们可以在当前节点上通过DaemonSet来运行一个GRPC服务，通过这个服务来进行本地硬件资源的上报与分配 1.1.2 服务注册设计 当提供硬件服务需要与kubelet进行通信的时候，则首先需要进行注册，注册的方式，则是通过最原始的底层的socket文件，并且通过Linux文件系统的inotify机制，来实现服务的注册 1.2 插件服务感知 1.2.1 Watcher Watcher主要是负责感知当前节点上注册的服务，当发现新的要注册的插件服务，则会产生对应的事件，注册到当前的kubelet中 1.2.2 期望状态与实际状态 这里的状态主要是指的是否需要注册，因为kubelet与对应的插件服务是通过网络进行通信的，当网络出现问题、或者对应的插件服务故障，则可能会导致服务注册失败，但此时对应的服务的socket还依旧存在，即对应的插件服务依旧存在 此时就会有两种状态：期望状态与实际状态，