Group items tagged

通过增加一层代理的机制实现

操作系统和基础库的依赖允许应用自定义

对磁盘路径以及端口的依赖通过Docker运行参数动态注入

每个服务器节点上要有个agent来执行具体的操作，监控该节点上的应用

还要提供接口以及工具去操作。

应用进程和资源（包括 cpu，内存，磁盘，网络）的解耦

服务依赖关系的解耦

scheduler在Kubernetes中是一个plugin，可以用其他的实现替换（比如mesos）

大多数接口都是直接读写etcd中的数据。

etcd 作为配置中心和存储服务

kubelet 主要包含容器管理，镜像管理，Volume管理等。同时kubelet也是一个rest服务，和pod相关的命令操作都是通过调用接口实现的。

kube-proxy 主要用于实现Kubernetes的service机制。提供一部分SDN功能以及集群内部的智能LoadBalancer。

Pods Kubernetes将应用的具体实例抽象为pod。每个pod首先会启动一个google_containers/pause docker容器，然后再启动应用真正的docker容器。这样做的目的是为了可以将多个docker容器封装到一个pod中，共享网络地址。

Replication Controller 控制pod的副本数量

Services service是对一组pods的抽象，通过kube-proxy的智能LoadBalancer机制，pods的销毁迁移不会影响services的功能以及上层的调用方。

Namespace Kubernetes中的namespace主要用来避免pod，service的名称冲突。同一个namespace内的pod，service的名称必须是唯一的。

Kubernetes的理念里，pod之间是可以直接通讯的

需要用户自己选择解决方案: Flannel,OpenVSwitch,Weave 等。

Hypernetes就是一个实现了多租户的Kubernetes版本。

如果运维系统跟不上，服务拆太细，很容易出现某个服务器的角落里部署着一个很古老的不常更新的服务，后来大家竟然忘记了，最后服务器迁移的时候给丢了，用户投诉才发现。

在Kubernetes上的微服务治理框架可以一揽子解决微服务的rpc，监控，容灾问题

同一个pod的多个容器定义中没有优先级，启动顺序不能保证