Pod 的副本集合可以共同组成一整个应用，一个微服务，或者在一个多层应用的一层。一旦 Pod 创建好，系统会持续的监控他们的健康状态，和它们运行时所在的机器的健康状况。如果一个 Pod 因为软件问题或者所在机器故障出现问题，Replication 控制器会自动在健康的机器上创建一个新的 Pod。
Kubernetes 支持一种独特的网络模型。Kubernetes 鼓励用扁平的地址空间，并且不会动态的分配端口，而是采用让用户可以选择任意合适自己的端口。为了实现这点，它给每一个 Pod 分配了一个 IP 地址。
Kubernetes 提供了 Service 的抽象，其提供了一稳定的 IP 地址和 DNS 名字，来对应一组动态的 Pod，例如一组构成一个微服务的 Pod。这个 Pod 组是通过 Label 选择器来定义的，因为可以指定任何的 Pod 组。当一个运行在 Kubernetes Pod 里的容器连接到这个地址时，这个连接会被本地的代理转发（称作 kube proxy）。该代理运行在来源机器上，转发的目的地是一个相应的后端容器，确切的后端是通过 round-robin 的策略进行选择，以均衡负载。kube proxy 也会追踪后端的 Pod 组的动态变化，如当 Pod 被位于新机器上的新的 Pod 取代的时候，因而服务的 IP 和 DNS 名字不用改变。
每一个 Kubernetes 中的资源，如 Pod，都通过一个URI来被识别，并且有一个 UID。URI 中一个总要的组件是，对象的类型（如：Pod），对象的名字，和对象的 namespace（命名空间）。对于一个特定的对象类型，每一个名字在其命名空间都是独一无二的，在一个对象的名字没有带着命名空间的形式给出，那就是默认的命名空间，UID 在时间和空间的范围都是唯一的。
关于 Service 的更多说明：
Service 是应用服务的抽象，通过 labels 为应用提供负载均衡和服务发现。匹配 labels 的 Pod IP 和端口列表组成 endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
每个 Service 都会自动分配一个 cluster IP（仅在集群内部可访问的虚拟地址）和 DNS 名，其他容器可以通过该地址或 DNS 来访问服务，而不需要了解后端容器的运行。
Kubernetes 组件：
kubectl：客户端命令行工具，将接受的命令格式化后发送给 kube-apiserver，作为整个系统的操作入口。
kube-apiserver：作为整个系统的控制入口，以 REST API 服务提供接口。
kube-controller-manager：用来执行整个系统中的后台任务，包括节点状态状况、Pod 个数、Pods 和 Service 的关联等。
kube-scheduler（将 Pod 调度到 Node 上）：负责节点资源管理，接受来自 kube-apiserver 创建 Pods 任务，并分配到某个节点。
etcd：负责节点间的服务发现和配置共享。
kube-proxy：运行在每个计算节点上，负责 Pod 网络代理。定时从 etcd 获取到 Service 信息来做相应的策略。
kubelet：运行在每个计算节点上，作为 agent，接受分配该节点的 Pods 任务及管理容器，周期性获取容器状态，反馈给 kube-apiserver。
DNS：一个可选的DNS服务，用于为每个 Service 对象创建 DNS 记录，这样所有的 Pod 就可以通过 DNS 访问服务了。
flannel：Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，需要另外下载部署。我们知道当我们启动 Docker 后会有一个用于和容器进行交互的 IP 地址，如果不去管理的话可能这个 IP 地址在各个机器上是一样的，并且仅限于在本机上进行通信，无法访问到其他机器上的 Docker 容器。Flannel 的目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。
master 节点包含组件：
docker
etcd
kube-apiserver
kube-controller-manager
kubelet
kube-scheduler
minion 节点包含组件：
docker
kubelet
kube-proxy