本文将介绍如何搭建最简单的私有镜像仓库——Docker Registry。

首先，你需要使用 docker pull 命令拉取镜像：

1

# docker pull registry

然后，我们需要做一个端口映射，对外暴露端口，这样 Docker Registry 才能提供服务。它的容器内端口是 5000，简单起见，我们在外面也使用同样的 5000 端口，所以运行命令：

1

# docker run -d -p 5000:5000 registry

架构图

本文我将尝试用Kubernetes集群上搭建一个WordPress网站，他们的内部逻辑关系如下：

搭建步骤

编排 MariaDB 对象

MariaDB需要4个环境变量，比如数据库名、用户名、密码等，在Docker里我们是在命令行里使用参数--env，而在Kubernetes里我们就应该使用ConfigMap，为此需要定义一个maria-cm对象：

ClickHouse简介

• ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS);
• 列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍);

安装部署

在线

1
2
3
4
5
6
7
8
9
10
11

# 更新
$ sudp apt update
# 安装
$ sudo apt-get install clickhouse-client clickhouse-server
# 开启服务
$ sudo service clickhouse-server start
# 客户端连接
# 默认无密码，执行
clickhouse-client 
# 有密码的话，执行
clickhouse-client --password 123456

定义

全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的Ingress 服务。

所以，Ingress 的功能其实很容易理解：所谓 Ingress，就是 Service 的“Service”。

假如我现在有这样一个站点：https://cafe.example.com，其中https://cafe.example.com/coffee对应的是“咖啡点餐系统”，而https://cafe.example.com/tea对应的是茶水点餐系统，这两个系统，分别由名叫coffee和tea两个Deployment来提供服。

那么，我如何能使用 Kubernetes 的 Ingress 来创建一个统一的负载均衡器，从而实现当用户访问不同的域名时，能够访问到不同的 Deployment 呢？
上述功能，在 Kubernetes 里就需要通过 Ingress 对象来描述：

Kubernetes网络模型

Kubernetes 是通过一个叫作 CNI 的接口，维护了一个单独的网桥来代替 docker0。
这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。

在这里，Kubernetes 为 Flannel 分配的子网范围是 10.244.0.0/16。
这个参数可以在部署的时候指定，比如：

1

kubeadm init --pod-network-cidr=10.244.0.0/16

注：也可以在部署完成后，通过修改 kube-controller-manager 的配置文件来指定。

Flannel介绍

要理解容器“跨主通信”的原理，就一定要先从Flannel这个项目开始。

Flannel 项目是 CoreOS 公司主推的容器网络方案。事实上，Flannel 项目本身只是一个框架，真正为我们提供容器网络功能的，是 Flannel 的后端实现。目前，Flannel 支持三种后端实现（种容器跨主网络的主流实现方法。），分别是：

• VXLAN
• host-gw
• UDP

UDP模式

概念

网络栈

包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。

注意：作为一个容器，它可以声明直接使用宿主机的网络栈（–net=host），即：不开启 Network Namespace，比如：

1
2

# 容器启动后，直接监听的就是宿主机的 80 端口。
docker run –d –net=host --name nginx-host nginx

关于本地持久化存储

用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器Volume。

这样做的好处就是：由于这个Volume直接使用的是本地磁盘，尤其是SSD盘，它的读
写性能相比于大多数远程存储来说，要好得多。

Local PV的设计难点

如何把本地磁盘抽象成PV

PV和PVC

PV是持久化存储数据卷。

这个API对象主要定义的是一个持久化存储在宿主机上的目录，比如一个NFS的挂载目录。

下面来定义一个NFS类型的PV：

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/"

Job

API对象定义：

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

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: resouer/ubuntu-bc
        # scale=10000 意思是 计算出的结果取小数点后 10000位
        command: ["sh","-c","echo 'scale=10000; 4*a(1)' | bc -l "]
      restartPolicy: Never # 离线计算的Pod永远不应该被重启
  backoffLimit: 4

在这个模板中，我们定义了一个Ubuntu镜像的容器，他运行计算π的程序，所以，这是一个计算π的容器。

创建成功后，查看一下这个Job对象：
//TODO:
可以看到，在这个Job对象创建后，它的Pod模板被自动加上了一个controller-uid=<一个随机字符串>这样的Label。从而保证了Job与它所管理的Pod之间的匹配关系。