-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
373 lines (206 loc) · 28.3 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>开心BOY</title>
<link href="https://hackerain.me/atom.xml" rel="self"/>
<link href="https://hackerain.me/"/>
<updated>2024-02-23T02:18:46.881Z</updated>
<id>https://hackerain.me/</id>
<author>
<name>hackerain</name>
</author>
<generator uri="https://hexo.io/">Hexo</generator>
<entry>
<title>Kubernetes controller-runtime 介绍</title>
<link href="https://hackerain.me/2023/11/18/kubernetes/kube-controller-runtime.html"/>
<id>https://hackerain.me/2023/11/18/kubernetes/kube-controller-runtime.html</id>
<published>2023-11-18T00:00:00.000Z</published>
<updated>2024-02-23T02:18:46.881Z</updated>
<summary type="html"><p>我们在做CRD开发时，除了要写CRD定义之外，最重要的是实现CRD对应的Controller，这样CRD才能真正有用，而不论什么CRD，它的Controller的逻辑框架是大致一样的，主要就是监听CRD资源的变化事件，然后触发Reconcile逻辑去执行对应的动作，确保实际状态跟CRD的定义状态保持一致，此外，还有一些其他通用功能，比如监控、选主、Wehbook等，这种开发范式现在称之为<code>Operator</code>，在万物皆可CRD的云原生时代，这种通用需求早已被剥离出来，成为单独的第三方库，即<a href="https://github.com/kubernetes-sigs/controller-runtime">controller-runtime</a>，而<a href="https://github.com/operator-framework/operator-sdk">operator-sdk</a>也封装的是 <code>controller-runtime</code>，方便进行operator的开发，可见其重要性，本篇文章就对 <code>controller-runtime</code> 的概念、原理以及核心逻辑进行下介绍。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes API Codec 解析</title>
<link href="https://hackerain.me/2023/11/12/kubernetes/kube-versioning-codec.html"/>
<id>https://hackerain.me/2023/11/12/kubernetes/kube-versioning-codec.html</id>
<published>2023-11-12T00:00:00.000Z</published>
<updated>2023-11-12T11:00:19.131Z</updated>
<summary type="html"><h2 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h2><p>在 <a href="https://hackerain.github.io/2023/10/28/kubernetes/kube-versioning.html">Kubernetes API 多版本和序列化</a> 这篇文章中，介绍了API多版本的功能和实现原理，其中Codec就是用来做序列化工作的，它主要用在两个地方：一个是通过HTTP协议跟客户端进行交互时，会对传输的数据进行序列化和反序列化，将字节流类型的数据转换成对应的API对象，或者是将API对象转换成对应格式的数据返回给客户端；一个是用在存储层的，即API对象存储到数据库时，也需要经过编码的，即经过序列化，默认是存储成 protobuf格式的数据，然后从数据库读出来数据时，又会反序列化为对应的API对象，下面我们来分析下Codec的实现机制。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes API Scheme 解析</title>
<link href="https://hackerain.me/2023/11/11/kubernetes/kube-versioning-scheme.html"/>
<id>https://hackerain.me/2023/11/11/kubernetes/kube-versioning-scheme.html</id>
<published>2023-11-11T00:00:00.000Z</published>
<updated>2024-02-23T05:17:27.350Z</updated>
<summary type="html"><h2 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h2><p>在 <a href="https://hackerain.github.io/2023/10/28/kubernetes/kube-versioning.html">Kubernetes API 多版本和序列化</a> 这篇文章中，介绍了API多版本的功能和实现原理，其中Scheme就是其实现原理的一项重要机制，在平时的开发中也经常会遇到，本篇文章就对其进行下分析。</p>
<p>Scheme起到了一个类型（Type）注册中心的作用，在API Server内部，全局只有一个Scheme实例，各个版本的API资源，会将他们的类型，注册到Scheme中来，同时，也会将如何进行类型转换的方法注册到Scheme中来，后续在Handler中进行版本转换以及序列化时，则会使用Scheme中注册的类型创建对应版本的对象，以及使用注册的类型转换的方法对不同版本的对象进行转换。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes API 多版本和序列化</title>
<link href="https://hackerain.me/2023/10/28/kubernetes/kube-versioning.html"/>
<id>https://hackerain.me/2023/10/28/kubernetes/kube-versioning.html</id>
<published>2023-10-28T00:00:00.000Z</published>
<updated>2023-11-12T11:36:49.181Z</updated>
<summary type="html"><h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>三年前在分析Kubernete APIServer时，就经常遇到两个东西，一个是Scheme，一个是Codec，当时对它们并不是很理解，也没有去细究，但是后来越来越多的能够遇见它们，尤其是在做Kubernetes API相关的开发时，Scheme的出镜率很高，于是查了下资料才知道，原来他们跟Kubernetes的API多版本和序列化有关，而API多版本又属于Kubernetes API的重要特性，它跟一般应用的多版本API还不太一样，有它自己的特色，因此搞懂它的相关概念和实现原理是相当有必要的。从前面介绍apiserver的系列文章上也可以看到，因为Kubernetes要处理很多种资源，可以说是包罗万象，所以它做了很多的抽象，而API多版本则是在这些抽象之上再度抽象的艺术，因此还是比较难以理解的，但是这些设计都是随着时间的推移逐渐演进出来的，有它的合理性，甚至当理解了它的机制之后，会发现它的设计之美，仿佛是一件艺术品。毕加索说，艺术是揭示真理的谎言，就让我们拨开API多版本的层层迷雾，去探寻下它的本质。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Elasticsearch大文本字段(large text field)优化方案</title>
<link href="https://hackerain.me/2022/09/26/elasticsearch/elasticsearch_large_text_field.html"/>
<id>https://hackerain.me/2022/09/26/elasticsearch/elasticsearch_large_text_field.html</id>
<published>2022-09-26T00:00:00.000Z</published>
<updated>2023-03-11T15:45:44.734Z</updated>
<summary type="html"><h2 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h2><p>在全文检索的场景下，经常会有text类型的字段存储的数据量比较大，比如一个pdf文档或者是一本书的内容，可能会有几兆，几十兆，上百兆的大小，单个字段的内容过大，会对集群性能以及稳定性造成比较大的影响，因此本文档针对该场景给出优化建议。</p></summary>
<category term="elasticsearch" scheme="https://hackerain.me/tags/elasticsearch/"/>
</entry>
<entry>
<title>UMI框架解析</title>
<link href="https://hackerain.me/2022/08/07/umi/umi.html"/>
<id>https://hackerain.me/2022/08/07/umi/umi.html</id>
<published>2022-08-07T10:52:55.000Z</published>
<updated>2023-03-11T15:45:44.747Z</updated>
<summary type="html"><h2 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h2><p>最近打算自己写一个运维管理平台，给我们内部使用，对于一个运维+后端程序员来说，写前端无疑是最大的挑战了，前端的知识栈真是庞大又杂乱，只掌握了最基础的html+css+js来说是远远不够的，前端发展了这么几十年，每一个领域都有一大堆的标准、组件、框架，比如css有less、sass等扩展，js领域又有react, vue等框架，还有typescript这种带类型的js，光ts的语法就可以复杂到令人发指，此外，还有很多现成的ui库，像阿里的antd，国外的mui，本以为react就已经是学习的终点了，但是还有umi这种基于react的前端框架，这还没完，还有再上一层的基于umi的antd pro框架，一层接一层，而且很多公司还在热衷于创造新的框架，这些各个方面各个维度的框架组件，多到让新踏入这个领域的小白无所适从。然而虽然学习成本增加了，但是这种越来越上层的框架组件，是无数前辈大佬的经验总结，能够让前端开发变得快速高效标准，尤其是对我这种小白来说，遵循这些优秀的框架标准，就可以继承这些经验，少走很多弯路，专注于做业务逻辑的开发。</p></summary>
<category term="umi" scheme="https://hackerain.me/tags/umi/"/>
</entry>
<entry>
<title>OpenStack Ussuri-Victoria-Wallaby版本新功能介绍</title>
<link href="https://hackerain.me/2021/11/19/openstack/openstack_uvw_highlight.html"/>
<id>https://hackerain.me/2021/11/19/openstack/openstack_uvw_highlight.html</id>
<published>2021-11-19T22:12:55.000Z</published>
<updated>2023-03-11T15:45:44.744Z</updated>
<summary type="html"><h2 id="社区目标"><a href="#社区目标" class="headerlink" title="社区目标"></a>社区目标</h2><p>每个Release，社区都会定义几个社区目标，期望所有项目能够实现，这有利于对OpenStack下众多的项目能够有统一整体性，而不是各自发展各自的。OpenStack 从Ussuir到Victoria到Wallaby版本，社区定义了如下几个社区目标：</p>
<ul>
<li><a href="https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html">Drop Python 2.7 Support</a></li>
<li><a href="https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html">Migrate RBAC Policy Format from JSON to YAML</a></li>
<li><a href="https://governance.openstack.org/tc/goals/selected/wallaby/migrate-to-privsep.html">Migrate from oslo.rootwrap to oslo.privsep</a></li>
</ul></summary>
<category term="openstack" scheme="https://hackerain.me/tags/openstack/"/>
</entry>
<entry>
<title>OpenStack Stein-Train版本新功能介绍</title>
<link href="https://hackerain.me/2021/11/19/openstack/openstack_rst_highlight.html"/>
<id>https://hackerain.me/2021/11/19/openstack/openstack_rst_highlight.html</id>
<published>2021-11-19T22:03:55.000Z</published>
<updated>2023-03-11T15:45:44.743Z</updated>
<summary type="html"><h2 id="社区目标"><a href="#社区目标" class="headerlink" title="社区目标"></a>社区目标</h2><p>每个Release，社区都会定义几个社区目标，期望所有项目能够实现，这有利于对OpenStack下众多的项目能够有统一整体性，而不是各自发展各自的。OpenStack Stein到Train版本，社区定义了如下几个社区目标：</p></summary>
<category term="openstack" scheme="https://hackerain.me/tags/openstack/"/>
</entry>
<entry>
<title>Kubernetes Kubelet CSI 机制解析</title>
<link href="https://hackerain.me/2021/10/16/kubernetes/kube-kubelet-csi.html"/>
<id>https://hackerain.me/2021/10/16/kubernetes/kube-kubelet-csi.html</id>
<published>2021-10-16T00:00:00.000Z</published>
<updated>2023-10-26T16:17:25.300Z</updated>
<summary type="html"><p>在CSI之前，Kubernetes本身就内置了很多插件去对接第三方存储，如果内置插件不满足需求，还可以通过FlexVolume机制，去编写自己的存储插件，然后被动态的加载到Kubernetes中，也就是说Kubernetes并不存在像对接容器运行时那种代码侵入性不好维护的问题，那为什么还要再制定一套CSI机制去对接第三方存储呢？其实CSI是一个更通用的存储对接方案，它不仅仅是针对Kubernetes的，而是针对所有的容器编排系统，比如Mesos也支持CSI，而且CSI是通过RPC机制进行交互的，跟语言无关，这样就给存储厂商带来极大的便利，写一次CSI插件，就可以适配到各种容器编排系统，不用为每种容器编排系统单独开发存储插件，这在CSI协议的目标中做了清晰的描述：</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Kubelet CNI 机制解析</title>
<link href="https://hackerain.me/2021/09/20/kubernetes/kube-kubelet-cni.html"/>
<id>https://hackerain.me/2021/09/20/kubernetes/kube-kubelet-cni.html</id>
<published>2021-09-20T00:00:00.000Z</published>
<updated>2023-10-26T16:17:25.298Z</updated>
<summary type="html"><h2 id="CNI简介"><a href="#CNI简介" class="headerlink" title="CNI简介"></a>CNI简介</h2><p>这里说Kubelet CNI，其实说法有些不准确，在<a href="https://hackerain.github.io/2021/08/15/kubernetes/kube-kubelet-overview.html">Kubernetes Kubelet机制概述</a>中就介绍过，Kubelet并没有直接跟CNI交互，而是通过容器运行时跟外部网络进行交互的，换句话说，CNI解决的是容器网络插件化的问题，跟Kubernetes这种容器编排系统并没有直接关系，但是有很多文章都说Kubelet支持了CNI，包括Kubernets官方的文档<a href="https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/">Network Plugins</a>，其实这里是特指的Docker，因为Docker本身并不支持CNI，kubelet将对Docker网络环境的创建和删除，通过CNI的方式，放在了dockershim中，如果Kubernetes移除了对Docker的支持，就会移除dockershim，那么kubelet对CNI的支持也就会移除，这样两者就完全没有关系了。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Kubelet CRI 机制解析</title>
<link href="https://hackerain.me/2021/09/07/kubernetes/kube-kubelet-cri.html"/>
<id>https://hackerain.me/2021/09/07/kubernetes/kube-kubelet-cri.html</id>
<published>2021-09-07T00:00:00.000Z</published>
<updated>2023-10-26T16:17:25.299Z</updated>
<summary type="html"><h2 id="CRI机制简介"><a href="#CRI机制简介" class="headerlink" title="CRI机制简介"></a>CRI机制简介</h2><p>CRI机制早在2016年的1.5版本就发布出来了，官方在这篇<a href="https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/">博文</a>中做了介绍，引入CRI的目的是为了让Kubernetes能够对接多种Container Runtime，而不仅限于Docker这一种。我们知道Docker曾经是容器领域的王者，它的出现开启了容器化时代，紧随其后，又出了很多种其他的容器技术，并且随着容器技术的流行，自然而然产生了对容器编排的需求，于是又涌现了一批容器编排的技术，而Kubernetes就是其中的佼佼者，凭借其强大的社区力量和先进的设计理念，很快独领风骚，在众多竞争者中脱颖而出。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Kubelet 机制概述</title>
<link href="https://hackerain.me/2021/08/15/kubernetes/kube-kubelet-overview.html"/>
<id>https://hackerain.me/2021/08/15/kubernetes/kube-kubelet-overview.html</id>
<published>2021-08-15T00:00:00.000Z</published>
<updated>2023-03-11T15:45:44.739Z</updated>
<summary type="html"><p>距离上一篇文章，已经过去了将近9个月的时间，2021年第一篇文章，竟然是到8月份了，真没想到这个kubelet竟然拖了我这么长时间。研究api以及scheduler的日夜还历历在目，不知不觉就过了这么长时间，现在突然写起来，恍如隔世的感觉，这一方面说明kubelet相比其他组件确实要更复杂一些，另一方面说明最近这一段时间我有些懈怠了，感觉有50%的时间在忙其他事情，25%的时间在研究kubelet，然后25%的时间在懈怠。不过还好，经过这么长时间断断续续的研究，记了很多笔记，梳理清楚了其大致脉络，对kubelet有了一个比较全面的认知，尤其是跟框架有关的，比如CRI，CNI，CSI等各种Plugin机制，知道了这些框架的原理，不论是做插件开发还是运维，都能够按图索骥，快速找到问题所在，然后再深入到具体的细节中。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Scheduler Scheduling Framework</title>
<link href="https://hackerain.me/2020/12/21/kubernetes/kube-scheduler-framework.html"/>
<id>https://hackerain.me/2020/12/21/kubernetes/kube-scheduler-framework.html</id>
<published>2020-12-21T00:00:00.000Z</published>
<updated>2023-10-26T16:17:25.301Z</updated>
<summary type="html"><h2 id="简介"><a href="#简介" class="headerlink" title="简介"></a>简介</h2><p>在<a href="https://hackerain.github.io/2020/12/19/kubernetes/kube-scheduler-overview.html">Kubernetes Scheduler机制概览</a>中就介绍过<a href="https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md">Scheduling Framework</a>这个新的调度框架，它通过<code>Plugins以及Extension Points</code>的方式对调度框架进行了重构，通过在各个预定义的扩展点，插入Plugin的方式，扩展Scheduler的功能，核心的调度算法逻辑，也都放到了Plugin中，如果默认的调度器中的Plugin不能满足需求，可以自己写插件，但是要重新编译代码。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Scheduler性能优化之Cache</title>
<link href="https://hackerain.me/2020/12/20/kubernetes/kube-scheduler-cache.html"/>
<id>https://hackerain.me/2020/12/20/kubernetes/kube-scheduler-cache.html</id>
<published>2020-12-20T00:00:00.000Z</published>
<updated>2023-10-26T16:17:25.300Z</updated>
<summary type="html"><h2 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h2><p>在<a href="https://hackerain.github.io/2020/12/19/kubernetes/kube-scheduler-overview.html">Kubernetes Scheduler机制概览</a>中就介绍过Cache的作用，它的主要作用是加速调度过程中查询pod和node等信息的速度，此外，还有Snapshot机制，即为了保持调度时数据的一致性，对缓存打的快照。</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Scheduler机制概览</title>
<link href="https://hackerain.me/2020/12/19/kubernetes/kube-scheduler-overview.html"/>
<id>https://hackerain.me/2020/12/19/kubernetes/kube-scheduler-overview.html</id>
<published>2020-12-19T00:00:00.000Z</published>
<updated>2023-10-26T16:17:25.302Z</updated>
<summary type="html"><h2 id="简介"><a href="#简介" class="headerlink" title="简介"></a>简介</h2><blockquote>
<p>在 Kubernetes 项目中，默认调度器的主要职责，就是为一个新创建出来的 Pod，寻找一个最合适的节点（Node）。</p>
<p>而这里“最合适”的含义，包括两层：</p>
<ol>
<li>从集群所有的节点中，根据调度算法挑选出所有可以运行该 Pod 的节点；</li>
<li>从第一步的结果中，再根据调度算法挑选一个最符合条件的节点作为最终结果。</li>
</ol>
<p>所以在具体的调度流程中，默认调度器会首先调用一组叫作 Predicate 的调度算法，来检查每个 Node。然后，再调用一组叫作 Priority 的调度算法，来给上一步得到的结果里的每个 Node 打分。最终的调度结果，就是得分最高的那个 Node。</p>
</blockquote></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Kubernetes Informer机制解析</title>
<link href="https://hackerain.me/2020/12/11/kubernetes/kube-clientgo-informer.html"/>
<id>https://hackerain.me/2020/12/11/kubernetes/kube-clientgo-informer.html</id>
<published>2020-12-11T00:00:00.000Z</published>
<updated>2023-11-16T13:50:36.219Z</updated>
<summary type="html"><p>Kubernetes的控制器模式是其非常重要的一个设计模式，整个Kubernetes定义的资源对象以及其状态都保存在etcd数据库中，通过apiserver对其进行增删查改，而各种各样的控制器需要从apiserver及时获取这些对象以及其当前定义的状态，然后将其应用到实际中，即将这些对象的实际状态调整为期望状态，让他们保持匹配。因此各种控制器需要和apiserver进行频繁交互，需要能够及时获取对象状态的变化，而如果简单的通过暴力轮询的话，会给apiserver造成很大的压力，且效率很低，因此，Kubernetes设计了Informer这个机制，用来作为控制器跟apiserver交互的桥梁，它主要有两方面的作用：</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
<entry>
<title>Glance多后端功能介绍</title>
<link href="https://hackerain.me/2020/11/12/openstack/glance-multistore.html"/>
<id>https://hackerain.me/2020/11/12/openstack/glance-multistore.html</id>
<published>2020-11-12T16:24:55.000Z</published>
<updated>2023-10-26T16:17:25.302Z</updated>
<summary type="html"><p>所谓Glance多后端，其实是针对Cinder的多后端功能对比的，我们知道在Cinder中，cinder-volume后面可以接多个存储后端，并且通过cinder types来选择使用哪个存储后端，Cinder中的这个功能很早就有了，因为Cinder要纳管多种存储，对外提供统一的接口，这个功能是刚需。但是对于Glance来说，类似Cinder的这种Glance多后端就没那么刚了，没有多后端也是可以用的，拿Ceph作为后端存储来说，如果镜像只是存在其中一个存储池A的话，要在另外的存储池B中建虚拟机，发现不能执行rbd clone操作，那么它会将该镜像下载到本地，然后再传到存储池B中，而且下载下来的镜像会缓存到本节点，只要在该节点下载过一次，后面在该节点再使用相同的镜像建虚拟机，就不需要再下载了，这种方式虽然效率低一些，但是不影响使用。但是毕竟不完美啊，所以社区一直到R版，才实现了这个功能，到T版算是生产可用，但是仍然有一些bug还在修复，不过不影响使用。</p></summary>
<category term="openstack" scheme="https://hackerain.me/tags/openstack/"/>
</entry>
<entry>
<title>Glance Interoperable Image Import功能介绍</title>
<link href="https://hackerain.me/2020/11/11/openstack/glance-interoperable-image-import.html"/>
<id>https://hackerain.me/2020/11/11/openstack/glance-interoperable-image-import.html</id>
<published>2020-11-11T23:35:55.000Z</published>
<updated>2023-03-11T15:45:44.740Z</updated>
<summary type="html"><p>Glance最核心的功能就是镜像管理，我们最常做的操作就是管理员给Glance上传一个镜像，然后大家就都可以从这个镜像创建虚拟机了，这在私有云场景下，没有任何问题。但是在公有云场景下，需要考虑的问题就比较多了，像“应用市场”就是可以让普通用户上传自己制作的镜像，并且共享给其他人，这一方面是请求量比在私有云场景大了很多，可能同时有很多人在传镜像，而且镜像一般都很大，如果不做优化，Glance API可能很快就卡死了；另一方面是安全性问题，普通用户是不可信的，管理员要对其上传的镜像做各种安全性、合法性检查；其他的，像管理员可能需要对用户上传的镜像自动做类型转换，以及打一些元数据标签之类的；所以，Glance的核心功能虽然简单，但是随着需求的不断提出，它还是经历过了一个比较“漫长”的演进过程。</p></summary>
<category term="openstack" scheme="https://hackerain.me/tags/openstack/"/>
</entry>
<entry>
<title>Keystone Fernet Token解析</title>
<link href="https://hackerain.me/2020/11/09/openstack/keystone-fernet-token.html"/>
<id>https://hackerain.me/2020/11/09/openstack/keystone-fernet-token.html</id>
<published>2020-11-09T22:35:55.000Z</published>
<updated>2023-03-11T15:45:44.741Z</updated>
<summary type="html"><h2 id="Token的一点历史"><a href="#Token的一点历史" class="headerlink" title="Token的一点历史"></a>Token的一点历史</h2><p>Keystone在早期的版本中，其认证Token有好几种类型，最早期的也是当时最成熟的是UUID类型的Token，它将token以及其元数据存储在数据库中，以一个UUID来标识一个Token，这种方式一个明显的问题就是当Token量很大时，会往数据库中写大量的Token，一个中等集群，往往数据库中有十几G的数据都是Token，需要定期清理，否则会拖慢其他请求；后来发展出了基于公私钥非对称加密的PKI/PKIZ Token，这种Token不需要存数据库，Token元数据直接被编码到Token ID中，而且因为是非对称的，甚至都不需要跟Keystone交互，本地就可以完成验证以及解析Token，但是这种Token，因为Token元数据都在Token ID中，随着集群大小以及复杂度的变化，其长度也会变化，有时会变得非常长，超过了HTTP对Header的长度限制，再加上公私钥的管理也比较复杂，所以PKI体系的Token基本没有被用起来；于是就有了Fernet Token，它可以看成是UUID和PKI折中的一种方案，它有以下几个特点：</p></summary>
<category term="openstack" scheme="https://hackerain.me/tags/openstack/"/>
</entry>
<entry>
<title>Kubernetes APIServer扩展机制原理</title>
<link href="https://hackerain.me/2020/10/08/kubernetes/kube-apiserver-extensions.html"/>
<id>https://hackerain.me/2020/10/08/kubernetes/kube-apiserver-extensions.html</id>
<published>2020-10-08T00:00:00.000Z</published>
<updated>2023-10-28T14:12:29.408Z</updated>
<summary type="html"><p>终于来到了这一篇，APIServer的扩展机制，前面介绍的那几篇，可以说都是在给这篇铺平道路，先来回顾下：</p></summary>
<category term="kubernetes" scheme="https://hackerain.me/tags/kubernetes/"/>
</entry>
</feed>