Enterprise Just Builder

Solution for Enterprise Software Architecture

docker

初窥 Windows Container 和 Docker

抽象地说所有的计算都是在一系列物理资源上(包括处理器、 内存、 磁盘、 网络等)运行某些”功能”以达成特定任务,这些计算可以是简单的数学运算,比如“1+1”,也可以是跨越多台机器的复杂应用比如 Exchange。随着时代的进步,物理资源越来越强大,结果应用程序常常只利用了物理机所提供的资源的一小部分。因而,工程师们通过创建“虚拟”资源来模拟底层物理硬件,从而使得多个应用可以并发运行 — — 每个应用使用同一物理机器的部分物理资源。

通常这些模拟技术被称为虚拟化。“虚拟化”一词会让很多人联想到虚拟机。不过“虚拟机”只是虚拟化的一种实现,而容器是另一种类型的虚拟化,也称为操作系统虚拟化。以 Linux 容器为例:在一个 Linux 操作系统中可以创建多个容器,对于运行在容器中的应用程序来说,该 Linux 容器就是一个完全隔离且独立的“操作系统”,它的磁盘就像保存原始 OS 文件的副本,内存驻留的文件和数据也和正常启动的操作系统没什么区别。要实现要做到这一点,创建容器的”宿主”机要实现一系列技术。1

首先是名称空间隔离。名称空间包含了应用程序可交互的一切资源,包括文件、 网络端口和活跃进程的列表。通过名称空间隔离,宿主可以为每个容器分配一个虚拟名称空间,其中包含只对该容器可见的资源。在此受限视图中,无论容器运行在什么权限上,它都无法访问其名称空间之外的文件,就是因为这些文件对容器不可见。容器也无法查看该容器外的应用,当然也无法与之交互,所以容器中的应用就会错认为自己独占了整个系统(其实同一时刻还可能还有成十上百个应用在运行)。

出于效率考虑,宿主操作系统的许多文件、目录以及运行服务都被不同容器所共享,并被投影到每个容器的名称空间中。只有当应用程序改动到其容器,容器才会从底层主机操作系统获得一个独立副本 — 但只是包含被改动的那部分文件。这就是 “Docker” 的“copy-on-write”优化。通过共享单个主机可以高效地部署多个容器。

其次需要宿主管控可供容器使用的主机资源。管控诸如 CPU、 RAM和网络带宽等等资源,可以确保容器获得其预期的资源且不影响主机上其他容器的性能。例可以约束某个容器使得它的 CPU 占用率不得超过 10%。这意味着即使应用程序努力尝试,它也不能获得其他 90% CPU 占用,这部分 CPU 主机可以将分配给其他容器或供自己使用。Linux 使用称为 “cgroups” 的技术来实现这种管控。当然如果同一主机上的不同容器之间是相互协作的,并允许主机根据应用的实际需求变化不断动态调整资源分配,此时就无需资源管控。

>>> 阅读全文

 

, ,

Kubernetes 设计概览

Kubernetes 是用于管理跨主机的容器化(containerized)应用程序的系统,它为应用的部署、维护和扩展提供了基本机制。

Kubernetes 建立了强壮的声明式元语用于维护用户请求的预期状态。这些原语是 Kubernetes 的一大特色。此外还有自愈机制,如自动重启,重新调度,以及根据主动控制器而不单是业务流程的需要高对容器进行复制。

Kubernetes 主要适用于包含多个容器的应用,如弹性分布式微服务。它还设计用来将非容器化应用程序栈迁移到 Kubernetes。为此,它包括抽象为分组的松散耦合和紧密耦合的编队,容器,并提供容器查找,并以相对熟悉的方式互相交流的方式。

Kubernetes is primarily targeted at applications composed of multiple containers, such as elastic, distributed micro-services. It is also designed to facilitate migration of non-containerized application stacks to Kubernetes. It therefore includes abstractions for grouping containers in both loosely coupled and tightly coupled formations, and provides ways for containers to find and communicate with each other in relatively familiar ways.

Kubernetes enables users to ask a cluster to run a set of containers. The system automatically chooses hosts to run those containers on. While Kubernetes’s scheduler is currently very simple, we expect it to grow in sophistication over time. Scheduling is a policy-rich, topology-aware, workload-specific function that significantly impacts availability, performance, and capacity. The scheduler needs to take into account individual and collective resource requirements, quality of service requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, deadlines, and so on. Workload-specific requirements will be exposed through the API as necessary.

>>> 阅读全文

 

, ,