Custom Resource 的入口

请求是这样分发到 api 扩展点的：

例如我们有 （Custom Resource）CR

1
2
3
4
5
6
7
8

apiVersion: cnat.programming-kubernetes.info/v1alpha1
kind: At
metadata:
  name: example-at
spec:
  schedule: "2019-07-03T02:00:00Z"
status:
  phase: "pending"

相应的 CustomResourceDefinition (CRD) 会是这样：

API 入口

Client Sets

接收变更通知和缓存（Informers and Caching）

Client Sets可以 watch 变更，但一般我们用更高级的 Informers，因为它有缓存、索引等功能。

• Lister ：被应用调用，返回缓存中的数据列表
• Informer：监听器

Informer 有两个功能

Concept

umbrella chart

you can also create a chart with dependencies to other charts (a.k.a. umbrella chart) which are completely external using the requirements.yaml file.

versioning

Simple 1-1 versioning

Chart versus application versioning

参考

https://codefresh.io/docs/docs/new-helm/helm-best-practices/

前言

最近由于工作需要，重新系统回顾 Kubernetes 的编程。发现《Programming Kubernetes》这书写得比较系统。于是边学，边记录一些重点。

Controller

Controller Loop

本文状态：草稿

配置例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

算法

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

currentMetricValue 为相关 pod 的 metric 平均数。

什么是同步原语

共享内存，多进程/线程的运行期设计模式已成主流的今天，你有好奇一下，进程/线程间的怎么同步的吗？大部分人知道，我们用的开发语言，或类库函数库，已经提供了看起来很漂亮的封装。然而在漂亮的面子工程后面，大部分归根到底是要内核 或/和 CPU 硬件去完成这些同步的。而反过来，只要我们理解了内部原理，你就可以快速理解那些漂亮的面子工程，和他们可能的性能问题，进而选择一个适合你的“面子工程”。而这些内部原理，就是同步原语。

按比例分配分配新旧版本流量

VirtualService:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

DestinationRule :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN

根据请求源 pod 的 label 路由

使用 sourceLabels 规则，可以根据源 pod 的 label 进行路由。这里用了 version 这个 label。即根据pod的应用版本进行路由。
这样的路由规则实际是使用于发起调用方的 sidecar。

bpftrace 简介

bpftrace 简单使用

查询可以跟踪的内核函数，以 sleep 为关键字

1
2
3
4
5
6
7
8

$ bpftrace -l '*open*'

tracepoint:syscalls:sys_exit_open_tree
tracepoint:syscalls:sys_enter_open
...
kprobe:vfs_open
kprobe:tcp_try_fastopen
...

跟踪所有 sys_enter_open() 系统调用

1

$ bpftrace -e 'tracepoint:syscalls:sys_enter_open{ printf("%s %s\n", comm,str(args->filename)); }' | grep vi

然后在另外一个终端中

1

$ vi /etc/hosts

可以看到在 bpftrace 终端中输出：

From [Understanding The Linux Kernel]

Page Frame 回收

之前我们了解到，Linux 倾向用最多的内存做 Page Cache。这使我们不得不考虑如何在内存不足前回收内存。问题是，回收内存的程序本身也可能有 IO 操作，也可能需要内存。

简介

page cache 存放的数据的类型

• 普通的文件
• 目录数据
• 直接读取自 block device file 的数据
• 已经被swap out的用户进程内存的数据（可以强制内核在page cahce中保留一些已经被swap out的数据）
• 归属于一些特殊 filesystem 的内存 page，如用于进程间通讯的 shm filesystem

page cache 的标识体系

page cache 中的每个 page 均归属于文件. 这个文件 — 或更精确来说，是文件的 inode 被称为 page 的owner.

address_space 数据结构

Page cahce 的核心数据结构是 addrees_space。一般来说，每个 inode （Kernel 用来存放文件元信息的内存中的数据结构，可以视为一个文件的描述信息）中包含一个 addrees_space 。

$ pip install md-translate

export

md-translate -s Google -S en -T zh-CN ./java-native-mem.md

Ref

https://github.com/ilyachch/md_docs-trans-app

https://shaharmike.com/cpp/vtable-part2/