发表于

DEMO-APPLICATION

请先将示例应用部署配置文件git clone到本地.

1
(base) ➜ git clone https://github.com/aoxn/wdrip.git

示例应用一： 文件共享服务器

filebrowser 应用提供文件共享服务，存储使用阿里云OSS存储系统。因此需要配置阿里云ACCESS_KEY_ID和ACCESS_KEY_SEC与REGION。
请先git clone 代码到本地，安装filebrowser的脚本位于hack/example/filebrowser.sh

1
2
3
4
5
6
7
8
9
10
11
(base) ➜ export REGION=cn-hangzhou
(base) ➜ export ACCESS_KEY_ID=xxxx
(base) ➜ export ACCESS_KEY_SECRET=yyyyy
(base) ➜ export KUBECONFIG=~/.kube/config.wdrip
(base) ➜ bash hack/example/filebrowser.sh
(base) ➜
(base) ➜ kubectl get svc
NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
filebrowser   LoadBalancer   172.19.4.156   47.110.243.41   80:31295/TCP   22d
kubernetes    ClusterIP      172.19.0.1     <none>          443/TCP        22d

阅读全文 »

发表于

准备工作

安装wdrip
下载最新版本wdrip.当前版本0.1.1

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
(base) ➜ curl -sSL --retry 3 https://host-wdrip-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/wdrip/install.sh |bash
(base) ➜ ls -lht /usr/local/bin/wdrip

# use wdrip -h to see wdrip help command
(base) ➜ wdrip -h

wdrip creates and manages infrastructure agnostic Kubernetes clusters
            _         _
           | |       (_)
 _ _ _   __| |  ____  _  ____
| | | | / _  | / ___)| ||  _ \
| | | |( (_| || |    | || |_| |
 \___/  \____||_|    |_||  __/
                        |_|


wdrip creates and manages infrastructure agnostic Kubernetes clusters and empower strong auto heal ability and easy recovery

Usage:
  wdrip [command]

Available Commands:
  bootstrap   Bootstrap a Kubernetes cluster
  build       Kubernetes cluster build package
  ......

Use "wdrip [command] --help" for more information about a command.
阅读全文 »

发表于

复原力

复原力一词来源于微软创新研究院，全称是社会复原力，它研究的是通过大规模部署可以适应未来各种变数以及不确定性的创新技术来应对社会的各种潜在危机，从而增强社会复原力。如COVID-19、全球气候变暖、环境污染，探索在危机来临前中后的创新技术储备，快速应对方法，快速复原的能力。是一种从无序和混乱中回归秩序的能力。这也是运维所要解决的问题，让系统回归秩序。

本文探索的是云原生时代下容器基础设施在面临各种危机时的复原力问题，即基础设施复原力。

阅读全文 »

发表于 | 分类于 ， ，

Kubernetes API设计哲学

kubernetes API设计时遵循了如下几个特征，声明式的API设计、水平触发的reconcile、异步的pull模式

声明式（Declarative）

用户指定的是期望达到的状态，而不是操作命令。
Kubernetes API设计的理念如下： 用户将一个资源对象的期望状态通过描述文件的方式发送给API接口，然后API接口通过不间断的操作使资源对象达到并稳定在期望的状态之上。例如，用户将一个具有多个副本、及指定版本的deployment发送到API接口时，API首先对该资源对象做校验然后进行持久化存储，接下来一个reconcile操作会取回该资源并执行该资源的定义操作，直到该资源的实际状态与定义的期望状态一致。期间如果实际状态被意外更改，仍然会被reconcile到期望状态。

reconcile
reconcile是一组预定义的循环操作(通常的实现是controller-manager)，watch storage上资源对象的期望状态的变化，并对比资源的本地实际状态，执行相关操作使资源最终达到该期望的一致状态，具有幂等性。

水平触发（Level trigger）

Kubernetes API是基于水平触发的实现，系统会驱动资源达到当前所期望的状态，而不管在此之前被设置了哪些不同的期望状态，以当前为基准。例如对当前正在进行rollout的deployment更改其镜像，会促使系统放弃执行当前未完成的rollout,转而进入新的desired state reconcile 流程，即切换到最新的修改上。

异步性（Asynchronous）

Kubernetes API接口异步的执行资源的desired state reconcile操作。这意味着创建资源的API请求会在完成校验并存储后立刻返回给调用方而不会立刻执行任何的资源创建动作。这也会导致许多创建中的错误不会在这个阶段返回给用户。解决的方式是定义良好的事件通知机制，资源reconcile过程中产生的错误信息写入到资源关联的事件中，用户通过watch事件了解创建过程。

Reference

Building and using Kubernetes API

发表于 | 分类于 ，

问题一：

每个用户进程都有自己的页全局目录及页表，然后内核代表进程在内核态执行，此时如果内核代码修改了内核页表，那么这些修改是如何传递到其他用户进程的？毕竟所有用户进程维护自己的页表，同时关于内核线性空间的页表还必须相同，这个是如何做到的？

阅读全文 »

发表于 | 分类于 ，

进程切换流程

进程的切换只会发生在内核精心定义的点上：schedule()函数。从本质上来说进程的切换由两个步骤完成，或两个标志性动作：

  • 1.切换页全局目录来安装一个新的地址空间，cr3寄存器。
    这里请考虑这样一个问题，一旦页全局目录被切换成其他进程的，那么eip在取下一条指令时通过页表映射的方式还能正常的取到当前执行流的下一条指令吗？毕竟两个进程的页全局目录、页表大部分情况肯定会不一样。
    答案是：进程切换发生在内核态，所有代码的引用的地址空间大于0xC0000000,这部分页表属于主内核页表，而所有进程具有相同的主内核页表（至于为何具有相同主内核也表，见下一节），所以指令可以正常取并执行。
  • 2.切换内核态堆栈与硬件上下文。
    那么切换时的现场保护问题，尤其是SS段寄存器和esp寄存器的保护 。由于进程的切换发生在内核态，通常在进入内核态中断发生时，硬件上下文会被自动保存。
阅读全文 »

发表于 | 分类于 ，

问题描述

关于实模式与保护模式的基础可以参考《深入理解linux内核》，或相关博文。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1.实模式下的寻址方式
      cs <<4 + ip
2.保护模式下的寻址方式
      base(index(cs)) +eip
3.x86实模式进入保护模式的代码
       lgdt  GdtPtr        //加载 GDTR
       cli                       //关中断
                                 //打开地址线A20等
                                 //下面准备切换到保护模式
       mov   %cr0，%eax
       or       0x1,%eax
       mov   %eax,%cr0 //将cr0的PE位置1，进入保护模式

       jmp   dword SelectorSode32:0x0

问题:
当打开cr0的PE位的瞬间，处理器进入保护模式，寻址方式改变。此时cs的值并没有改变，并且打开cr0瞬间处理器对cs的解释方式完全不一样，那么问题来了，如何确保在进入保护模式后下一条指令被顺利执行？

阅读全文 »

发表于 | 分类于 ，

本文用于搭建一个基于haproxy和keepalived的高可用的私有docker registry

部署结构

  • haproxy keepalived 主：221.228.86.4
  • haproxy keepalived 备：221.228.86.5
  • docker registry 1： 221.228.86.6
  • docker registry 2： 221.228.86.67
  • VIP : 221.228.86.70
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
                    221.228.86.100
             +-----------VIP----------+   
             |                        |
             |                        |
           Master                   Backup
        221.228.86.4             221.228.86.6
        +----------+             +----------+
        | HAProxy  |             | HAProxy  |
        |keepalived|             |keepalived|
        +----------+             +----------+
             |  
             v  
    +--------+---------+ 
    |        |         |
    |        |         |
    v        v         v
+------+  +------+  +------+
| WEB1 |  | WEB2 |  | WEB3 |
+------+  +------+  +------+
阅读全文 »