Kubernetes初步

时间：2015-07-08 22:14:04 阅读：435 评论：0 收藏：0 [点我收藏+]

Kubernetes是Google开源的容器集群管理系统。它构建于docker技术之上。为容器化的应用提供资源调度、部署执行、服务发现、扩容缩容等整一套功能。本质上可看作是基于容器技术的mini-PaaS平台。本文旨在梳理Kubernetes的架构、概念及基本工作流，而且通过执行一个简单的演示样例应用来介绍怎样使用Kubernetes。

整体概览

例如以下图所看到的是我初步阅读文档和源码之后整理的整体概览，基本上能够从例如以下三个维度来认识Kubernetes。

操作对象

Kubernetes以RESTFul形式开放接口，用户可操作的REST对象有三个：

pod：是Kubernetes最主要的部署调度单元。能够包括container，逻辑上表示某种应用的一个实例。比方一个web网站应用由前端、后端及数据库构建而成。这三个组件将执行在各自的容器中，那么我们能够创建包括三个container的pod。

service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。
由于pod的执行状态可动态变化(比方切换机器了、缩容过程中被终止了等)。所以訪问端不能以写死IP的方式去訪问该pod提供的服务。
service的引入旨在保证pod的动态变化对訪问端透明，訪问端仅仅须要知道service的地址。由service来提供代理。

replicationController：是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，须要复制多份资源，而且依据负载情况动态伸缩。
通过replicationController。我们能够指定一个应用须要几份复制，Kubernetes将为每份复制创建一个pod，而且保证实际执行pod数量总是与该复制数量相等(比如。当前某个pod宕机时。自己主动创建新的pod来替换)。

能够看到。service和replicationController仅仅是建立在pod之上的抽象，终于是要作用于pod的，那么它们怎样跟pod联系起来呢？这就要引入label的概念：label事实上非常好理解，就是为pod加上可用于搜索或关联的一组key/value标签，而service和replicationController正是通过label来与pod关联的。例如以下图所看到的。有三个pod都有label为"app=backend"。创建service和replicationController时能够指定相同的label:"app=backend"，再通过label selector机制，就将它们与这三个pod关联起来了。比如。当有其它frontend pod訪问该service时，自己主动会转发到当中的一个backend pod。

功能组件

例如以下图所看到的是官方文档里的集群架构图，一个典型的master/slave模型。

master执行三个组件：

apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。

scheduler：负责集群的资源调度。为新建的pod分配机器。这部分工作分出来变成一个组件，意味着能够非常方便地替换成其它的调度器。

controller-manager：负责运行各种控制器，眼下有两类：
- endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
- replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际执行pod的数量总是一致的。

slave(称作minion)执行两个组件：

kubelet：负责管控docker容器，如启动/停止、监控执行状态等。它会定期从etcd获取分配到本机的pod，并依据pod信息启动或停止对应的容器。同一时候，它也会接收apiserver的HTTP请求，汇报pod的执行状态。

proxy：负责为pod提供代理。它会定期从etcd获取全部的service，并依据service信息创建代理。当某个客户pod要訪问其它pod时。訪问请求会经过本机proxy做转发。

工作流

上文已经提到了Kubernetes中最主要的三个操作对象：pod, replicationController及service。以下分别从它们的对象创建出发，通过时序图来描写叙述Kubernetes各个组件之间的交互及其工作流。

使用演示样例

最后，让我们进入实战模式。这里跑一个最简单的单机演示样例(全部组件执行在一台机器上)。旨在打通基本流程。

搭建好开发环境

第一步，我们须要Kuberntes各组件的二进制可运行文件。有下面两种方式获取：

下载源码自己编译：

git clone https://github.com/GoogleCloudPlatform/kubernetes.git
cd kubernetes/build
./release.sh

直接下载人家已经编译打包好的tar文件：

wget https://storage.googleapis.com/kubernetes/binaries.tar.gz

自己编译源代码须要先安装好golang。编译完之后在kubernetes/_output/release-tars目录下能够得到打包文件。

直接下载的方式不须要安装其它软件，但可能得不到最新的版本号。

第二步，我们还须要etcd的二进制可运行文件，通过例如以下方式获取：

wget https://github.com/coreos/etcd/releases/download/v0.4.6/etcd-v0.4.6-linux-amd64.tar.gz
tar xvf etcd-v0.4.6-linux-amd64.tar.gz

第三步，就能够启动各个组件了：

etcd

cd etcd-v0.4.6-linux-amd64
./etcd

apiserver

./apiserver -address=127.0.0.1 -port=8080 -portal_net="172.0.0.0/16" -etcd_servers=http://127.0.0.1:4001 -machines=127.0.0.1 -v=3 -logtostderr=false -log_dir=./log

scheduler

./scheduler -master 127.0.0.1:8080 -v=3 -logtostderr=false -log_dir=./log

controller-manager

./controller-manager -master 127.0.0.1:8080 -v=3 -logtostderr=false -log_dir=./log

kubelet

./kubelet -address=127.0.0.1 -port=10250 -hostname_override=127.0.0.1 -etcd_servers=http://127.0.0.1:4001 -v=3 -logtostderr=false -log_dir=./log

创建pod
搭好了执行环境后，就能够提交pod了。首先编写pod描写叙述文件，保存为redis.json：

{
  "id": "redis",
  "desiredState": {
    "manifest": {
      "version": "v1beta1",
      "id": "redis",
      "containers": [{
        "name": "redis",
        "image": "dockerfile/redis",
        "imagePullPolicy": "PullIfNotPresent",
        "ports": [{
          "containerPort": 6379,
          "hostPort": 6379
        }]
      }]
    }
  },
  "labels": {
    "name": "redis"
  }
}

然后，通过命令行工具kubecfg提交：

./kubecfg -c redis.json create /pods

提交完后，通过kubecfg查看pod状态：

# ./kubecfg list /pods
ID                  Image(s)            Host                Labels              Status
----------          ----------          ----------          ----------          ----------
redis               dockerfile/redis    127.0.0.1/          name=redis          Running

Status是Running表示pod已经在容器里执行起来了，能够用"docker ps"命令来查看容器信息:

# docker ps
CONTAINER ID        IMAGE                     COMMAND                CREATED             STATUS              PORTS                    NAMES
ae83d1e4b1ec        dockerfile/redis:latest   "redis-server /etc/r   19 seconds ago      Up 19 seconds                                k8s_redis.caa18858_redis.default.etcd_1414684622_1b43fe35

创建replicationController

{
    "id": "redisController",
    "apiVersion": "v1beta1",
    "kind": "ReplicationController",
    "desiredState": {
      "replicas": 1,
      "replicaSelector": {"name": "redis"},
      "podTemplate": {
        "desiredState": {
           "manifest": {
             "version": "v1beta1",
             "id": "redisController",
             "containers": [{
               "name": "redis",
               "image": "dockerfile/redis",
               "imagePullPolicy": "PullIfNotPresent",
               "ports": [{
                   "containerPort": 6379,
                   "hostPort": 6379
               }]
             }]
           }
         },
         "labels": {"name": "redis"}
        }},
    "labels": {"name": "redis"}
  }

然后，通过命令行工具kubecfg提交：

./kubecfg -c redisController.json create /replicationControllers

提交完后。通过kubecfg查看replicationController状态：

# ./kubecfg list /replicationControllers
ID                  Image(s)            Selector            Replicas
----------          ----------          ----------          ----------
redisController     dockerfile/redis    name=redis          1

同一时候。1个pod也将被自己主动创建出来，即使我们有益删除该pod。replicationController也将保证创建1个新pod。

Kubernetes初步

原文：http://www.cnblogs.com/lcchuguo/p/4631240.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年09月23日 (328)
2021年09月24日 (313)
2021年09月17日 (191)
2021年09月15日 (369)
2021年09月16日 (411)
2021年09月13日 (439)
2021年09月11日 (398)
2021年09月12日 (393)
2021年09月10日 (160)
2021年09月08日 (222)