运维进行时

        在运营系统中经常用到异步方式来处理我们的任务，比如将业务上线流程串成任务再写入队列，通过后台作业节点去调度执行。比较典型的案例为腾讯的蓝鲸、织云、云智慧等平台。本译文结合Django+Celery+Redis实现一个定期从Flickr 获取图片并展示的简单案例，方便大家理解实现异步对列任务的过程。
        刚接触django的时候，我经历过的最让人沮丧的事情是需要定期运行一段代码。我写了一个需要每天上午12点执行一个动作的不错的函数。很简单是不是？错了。事实证明，这对我来说是一个巨大的困难点，因为，那时我使用Cpane类型的虚拟主机管理系统，它能专门提供一个很友好，很方便的图形用户界面来设置cron作业。
       经过反复研究，我发现了一个很好的解决方案 - Celery，一个用于在后台运行任务的强大的异步作业队列。但是，这也导致了其它的问题，因为我无法找到一系列简单的指令将celery集成到Django项目中。
       当然，我最终还是设法成功搞定了它 - 这正是本文将介绍的内容：如何将celery集成到一个Django项目，创建周期性任务。
       该项目利用Python3.4，Django的1.8.2，celery3.1.18和Redis3.0.2.

一、概述
       由于大篇幅的文字，为了您的方便，请参阅下表中的每一步的简要信息，并获取相关的代码。
步骤      概要           Git标签
样板      样板下载          V1
建立      集成Celery和Django      V2
Celery任务    添加基本的Celery任务    V3
周期性任务    添加周期性任务        V4
本地运行    本地运行我们的应用程序    V5
远程运行    远程运行我们的应用程序    V5

二、什么是Celery
       “Celery是一个异步任务队列/基于分布式消息传递的作业队列。它侧重于实时操作，但对调度的支持也很好。”本文，我们将重点讲解周期性执行任务的调度特点。
       为什么这一点有用呢？
      •回想一下你不得不在将来运行某一特定任务的经历。也许你需要每隔一小时访问一个API。或者，也许你需要在这一天结束时发送一批电子邮件。不论任务大小，Celery都可以使得调度周期性任务变的很容易。
      •你永远不希望终端用户等待那些不必要的页面加载或动作执行完成。如果你的应用程序工作流的一部分是一个需要很长时间的程序，当资源可用时，你就可以使用Celery在后台执行这段程序，从而使你的应用程序可以继续响应客户端的请求。这样可以使任务在应用程序的环境之外运行。

三、构建项目
       在深入了解Celery之前，先从Github库中获取开始项目。确保激活一个虚拟的环境，安装必要的软件，并运行迁移。然后启动服务器，通过你的浏览器导航到http://localhost:8000/。你应当能看到‘恭喜你的第一个Django页面’。完成后，关闭服务器。
       接下来，我们开始安装celery。
$ pip install celery==3.1.18 $ pip freeze > requirements.txt
       现在，我们通过简单的三步将celery集成到django项目中。
步骤一：创建celery.py
在“picha“目录下，创建celery.py，代码如下：
from __future__ import absolute_import import os from celery import Celery from django.conf import settings # set the default Django settings module for the 'celery' program. os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'picha.settings') app = Celery('picha') # Using a string here means the worker will not have to # pickle the object when using Windows. app.config_from_object('django.conf:settings') app.autodiscover_tasks(lambda: settings.INSTALLED_APPS) @app.task(bind=True) def debug_task(self):     print('Request: {0!r}'.format(self.request))
       请注意代码中的注释。
步骤二：引入celery应用
为了确保在django启动时加载了celery应用，在settings.py旁边新建__init__.py，并添加以下代码到__init__.py中。
from __future__ import absolute_import # This will make sure the app is always imported when # Django starts so that shared_task will use this app. from .celery import app as celery_app
完成以上步骤后，你的项目目录应该是这样的：
├── manage.py ├── picha │   ├── __init__.py │   ├── celery.py │   ├── settings.py │   ├── urls.py │   └── wsgi.py └── requirements.txt
步骤三：安装 Redis作为Celery的“中间件”
    Celery使用中间件在django项目与celery监控者之间传递消息。在本教程中，我们使用redis作为消息中间代理。
首先，从官方下载页面或通过brew（BREW安装Redis）安装Redis，然后打开你的终端上，在一个新的终端窗口，启动服务器：
$ redis-server
你可以通过在终端中输入如下命令测试Redis是否正常工作。
$ redis-cli ping
       Redis应该回复PONG - 试试吧！
       一旦Redis正常启动了，把下面的代码添加到你的settings.py文件中：
# CELERY STUFF BROKER_URL = 'redis://localhost:6379' CELERY_RESULT_BACKEND = 'redis://localhost:6379' CELERY_ACCEPT_CONTENT = ['application/json'] CELERY_TASK_SERIALIZER = 'json' CELERY_RESULT_SERIALIZER = 'json' CELERY_TIMEZONE = 'Africa/Nairobi'
       你还需要添加Redis的作为Django项目的依赖：
$ pip install redis==2.10.3 $ pip freeze > requirements.txt
       就是这样了！你现在应该能够在Django中使用Celery。有关设置Celery与Django的更多信息，请查看官方Celery文档。
在继续下面步骤之前，让我们进行一些完整性检查，以确保一切都是正常的。
测试Celery worker已准备好接收任务：
$ celery -A picha worker -l info ... [2015-07-07 14:07:07,398: INFO/MainProcess] Connected to redis://localhost:6379// [2015-07-07 14:07:07,410: INFO/MainProcess] mingle: searching for neighbors [2015-07-07 14:07:08,419: INFO/MainProcess] mingle: all alone
       使用CTRL-C杀死该段程序。现在，测试Celery任务调度程序是否已经准备好：
$ celery -A picha beat -l info ... [2015-07-07 14:08:23,054: INFO/MainProcess] beat: Starting...
       在上述完成时再次终止该进程。

1、Celery任务
       Celery利用celery调用的常规Python函数作为任务。
       例如，让我们把这个基本函数变为celery的任务：
def add(x, y):     return x + y
       首先，添加一个装饰器。
from celery.decorators import task @task(name="sum_two_numbers") def add(x, y):     return x + y
       然后你可以通过以下方式利用celery异步运行该任务：
add.delay(7, 8)
       很简单，对不对？
所以，这对于解决类似你要加载一个网页，而不需要用户等待一些后台程序的完成这些类型的任务来说是非常完美的。
      让我们来看一个例子...
让我们再回到Django项目的版本3，它包括一个接受来自用户的反馈的应用程序，人们形象地称之为反馈：
├── feedback │   ├── __init__.py │   ├── admin.py │   ├── emails.py │   ├── forms.py │   ├── models.py │   ├── tests.py │   └── views.py ├── manage.py ├── picha │   ├── __init__.py │   ├── celery.py │   ├── settings.py │   ├── urls.py │   └── wsgi.py ├── requirements.txt └── templates     ├── base.html     └── feedback         ├── contact.html         └── email             ├── feedback_email_body.txt             └── feedback_email_subject.txt
       安装新的必要软件，启动应用程序，并导航到http://localhost:8000/feedback/。你应该看到如下结果：

让我们连接celery任务。

2、添加任务
       基本上，用户提交反馈表后，我们希望让他继续以他舒服的方式往下进行，而我们在后台进行处理反馈，发送电子邮件等等。
要做到这一点，首先添加一个叫tasks.py的文件到“feedback”目录：
from celery.decorators import task from celery.utils.log import get_task_logger from feedback.emails import send_feedback_email logger = get_task_logger(__name__) @task(name="send_feedback_email_task") def send_feedback_email_task(email, message):     """sends an email when feedback form is filled successfully"""     logger.info("Sent feedback email")     return send_feedback_email(email, message)
       然后按照如下内容更新forms.py：
from django import forms from feedback.tasks import send_feedback_email_task class FeedbackForm(forms.Form):     email = forms.EmailField(label="Email Address")     message = forms.CharField(         label="Message", widget=forms.Textarea(attrs={'rows': 5}))     honeypot = forms.CharField(widget=forms.HiddenInput(), required=False)     def send_email(self):         # try to trick spammers by checking whether the honeypot field is         # filled in; not super complicated/effective but it works         if self.cleaned_data['honeypot']:             return False         send_feedback_email_task.delay(             self.cleaned_data['email'], self.cleaned_data['message'])
       大体上，send_feedback_email_task.delay(email, message)的函数过程，并发送反馈电子邮件等都是在用户继续使用该网站的同时作为后台进程运行。
注：在views.py中的success_url被设置为将用户重定向到/ 目录，这个目录还不存在。我们会在下一节设置这个终点启动。

3、周期任务
       通常情况下，你经常需要安排一个任务在特定的时间运行 - 例如，一个web scraper 可能需要每天都运行。这样的任务，被称为周期性任务，很容易建立利用celery启动。
       celery使用“celery beat”来安排定期任务。celery beat定期运行任务，然后由celery worker执行任务。
例如，下面的任务计划每15分钟运行一次：
from celery.task.schedules import crontab from celery.decorators import periodic_task @periodic_task(run_every=(crontab(minute='*/15')), name="some_task", ignore_result=True) def some_task():     # do something
       让我们通过往Django项目中添加功能来看一个更强大的例子。
回到Django项目版本4，它包括另一个新的应用程序，叫做photos，这个应用程序使用 Flickr API获取新照片用来显示在网站：
├── feedback │   ├── __init__.py │   ├── admin.py │   ├── emails.py │   ├── forms.py │   ├── models.py │   ├── tasks.py │   ├── tests.py │   └── views.py ├── manage.py ├── photos │   ├── __init__.py │   ├── admin.py │   ├── models.py │   ├── settings.py │   ├── tests.py │   ├── utils.py │   └── views.py ├── picha │   ├── __init__.py │   ├── celery.py │   ├── settings.py │   ├── urls.py │   └── wsgi.py ├── requirements.txt └── templates     ├── base.html     ├── feedback     │   ├── contact.html     │   └── email     │       ├── feedback_email_body.txt     │       └── feedback_email_subject.txt     └── photos         └── photo_list.html
       安装新的必要软件，运行迁移，然后启动服务器，以确保一切都是好的。重新测试反馈表。这次，它应该重定向好了。
       下一步是什么？
       既然我们需要周期性的调用Flickr API，以获取更多的照片添加到我们的网站，我们可以添加一个celery任务。

4、添加任务
往photos应用中添加一个tasks.py。
from celery.task.schedules import crontab from celery.decorators import periodic_task from celery.utils.log import get_task_logger from photos.utils import save_latest_flickr_image logger = get_task_logger(__name__) @periodic_task(     run_every=(crontab(minute='*/15')),     name="task_save_latest_flickr_image",     ignore_result=True ) def task_save_latest_flickr_image():     """     Saves latest image from Flickr     """     save_latest_flickr_image()     logger.info("Saved image from Flickr")
       在这里，我们通过在一个task中包装这个函数，来实现每15分钟运行一次save_latest_flickr_image()函数。该@periodic_task装饰器抽象出代码来运行celery任务，使得tasks.py干净，易于阅读！

5、本地运行
       准备开始运行了？
       在Django应用程序和Redis运行的前提下，打开两个新的终端窗口/标签。在每一个新的窗口中，导航到你的项目目录，激活你的虚拟环境，然后运行下面的命令（每个窗口一个）：
$ celery -A picha worker -l info $ celery -A picha beat -l info
       当你访问http://127.0.0.1:8000/ 网址的时候，你现在应该能看到一个图片。我们的应用程序每15分钟从Flickr 获取一张图片。


通过photos/tasks.py查看代码。点击“Feedback”按钮发送一些反馈意见：


       以上是通过celery任务运行的。更多的请查看feedback/tasks.py。
       就这样，你成功的启动并运行了 Picha项目！
       当你本地开发Django项目时，这是一个很好的测试，但是当你需要部署到生产环境- 就像 DigitalOcean时，就不那么合适了。为此，建议你通过使用Supervisor在后台作为一个守护进程运行celery worker和调度器。

6、远程运行
       安装很简单。从版本库中获取版本5（如果你还没有的话）。然后，SSH到远程服务器，并运行：
$ sudo apt-get install supervisor
       然后，通过在远程服务器上“/etc/supervisor/conf.d/” 目录下添加配置文件来告知Supervisor celery的workers。在我们的例子中，我们需要两个这样的配置文件 - 一个用于Celery worker，一个是Celery scheduler。
在本地，在项目的根目录下创建一个“supervisor”的文件夹，然后添加下面的文件。
Celery Worker: picha_celery.conf
; ================================== ;  celery worker supervisor example ; ================================== ; the name of your supervisord program [program:pichacelery] ; Set full path to celery program if using virtualenv command=/home/mosh/.virtualenvs/picha/bin/celery worker -A picha --loglevel=INFO ; The directory to your Django project directory=/home/mosh/sites/picha ; If supervisord is run as the root user, switch users to this UNIX user account ; before doing any processing. user=mosh ; Supervisor will start as many instances of this program as named by numprocs numprocs=1 ; Put process stdout output in this file stdout_logfile=/var/log/celery/picha_worker.log ; Put process stderr output in this file stderr_logfile=/var/log/celery/picha_worker.log ; If true, this program will start automatically when supervisord is started autostart=true ; May be one of false, unexpected, or true. If false, the process will never ; be autorestarted. If unexpected, the process will be restart when the program ; exits with an exit code that is not one of the exit codes associated with this ; process’ configuration (see exitcodes). If true, the process will be ; unconditionally restarted when it exits, without regard to its exit code. autorestart=true ; The total number of seconds which the program needs to stay running after ; a startup to consider the start successful. startsecs=10 ; Need to wait for currently executing tasks to finish at shutdown. ; Increase this if you have very long running tasks. stopwaitsecs = 600 ; When resorting to send SIGKILL to the program to terminate it ; send SIGKILL to its whole process group instead, ; taking care of its children as well. killasgroup=true ; if your broker is supervised, set its priority higher ; so it starts first priority=998
Celery Scheduler: picha_celerybeat.conf
; ================================ ;  celery beat supervisor example ; ================================ ; the name of your supervisord program [program:pichacelerybeat] ; Set full path to celery program if using virtualenv command=/home/mosh/.virtualenvs/picha/bin/celerybeat -A picha --loglevel=INFO ; The directory to your Django project directory=/home/mosh/sites/picha ; If supervisord is run as the root user, switch users to this UNIX user account ; before doing any processing. user=mosh ; Supervisor will start as many instances of this program as named by numprocs numprocs=1 ; Put process stdout output in this file stdout_logfile=/var/log/celery/picha_beat.log ; Put process stderr output in this file stderr_logfile=/var/log/celery/picha_beat.log ; If true, this program will start automatically when supervisord is started autostart=true ; May be one of false, unexpected, or true. If false, the process will never ; be autorestarted. If unexpected, the process will be restart when the program ; exits with an exit code that is not one of the exit codes associated with this ; process’ configuration (see exitcodes). If true, the process will be ; unconditionally restarted when it exits, without regard to its exit code. autorestart=true ; The total number of seconds which the program needs to stay running after ; a startup to consider the start successful. startsecs=10 ; if your broker is supervised, set its priority higher ; so it starts first priority=999
       注：确保更新这些文件的路径，以匹配你的远程服务器的文件系统。
基本上，这些supervisor 配置文件告诉supervisord如何运行并管理我们的'programs'（因为它们是由supervisord调用）。
       在上面的例子中，我们已经创建了两个名为“pichacelery”和“pichacelerybeat”的supervisord程序。
现在，只需将这些文件拷贝到远程服务器的/etc/supervisor/conf.d/目录下。
       我们还需要在远程服务器上创建上面脚本中提到的日志文件：
$ touch /var/log/celery/picha_worker.log $ touch /var/log/celery/picha_beat.log
       最后，运行以下命令，使 Supervisor 知道它所管理的程序的存在 - 例如，pichacelery和pichacelerybeat：
$ sudo supervisorctl reread $ sudo supervisorctl update
       运行以下命令停止，启动，和/或检查pichacelery程序的状态：
$ sudo supervisorctl stop pichacelery $ sudo supervisorctl start pichacelery $ sudo supervisorctl status pichacelery
       你可以通过阅读官方文档获取Supervisor的更多信息。

7、最后提示
       1. 千万不要传递Django模型对象到celery任务。为了避免模型对象在传递给celery任务之前已经改变了，传递celery的主键给celery。然后，在运行之前使用主键从数据库中获取对象。
       2. 默认celery调度会在本地创建一些文件存储它的调度表。这些文件是“celerybeat-schedule.db”和“celerybeat.pid”。如果你在使用版本控制系统，比如Git（你应该使用！），请忽略这个文件，不要将它们添加到你的代码库中，因为它们是为本地运行的进程服务的。

8、下一步
       以上就是将celery集成到一个django项目的基本介绍。
想要更多？
1. 深入研究官方celery用户指南，以了解更多信息。
2. 创建一个Fabfile来设置Supervisor和配置文件。确保添加命令到reread和 update Supervisor。
3. 从repo中获取这个项目，并打开一个Pull 请求来添加一个新的celery任务。
编码快乐！

原文：https://realpython.com/blog/python/asynchronous-tasks-with-django-and-celery/

一、前言
        Kubernetes 是Google开源的容器集群管理系统，基于Docker构建一个容器的调度服务，提供资源调度、均衡容灾、服务注册、动态扩缩容等功能套件，目前最新版本为0.6.2。本文介绍如何基于Centos7.0构建Kubernetes平台，在正式介绍之前，大家有必要先理解Kubernetes几个核心概念及其承担的功能。以下为Kubernetes的架构设计图：

1. Pods
        在Kubernetes系统中，调度的最小颗粒不是单纯的容器，而是抽象成一个Pod，Pod是一个可以被创建、销毁、调度、管理的最小的部署单元。比如一个或一组容器。
2. Replication Controllers
        Replication Controller是Kubernetes系统中最有用的功能，实现复制多个Pod副本，往往一个应用需要多个Pod来支撑，并且可以保证其复制的副本数，即使副本所调度分配的主宿机出现异常，通过Replication Controller可以保证在其它主宿机启用同等数量的Pod。Replication Controller可以通过repcon模板来创建多个Pod副本，同样也可以直接复制已存在Pod，需要通过Label selector来关联。
3、Services
        Services是Kubernetes最外围的单元，通过虚拟一个访问IP及服务端口，可以访问我们定义好的Pod资源，目前的版本是通过iptables的nat转发来实现，转发的目标端口为Kube_proxy生成的随机端口，目前只提供GOOGLE云上的访问调度，如GCE。如果与我们自建的平台进行整合？请关注下篇《kubernetes与HECD架构的整合》文章。
4、Labels
        Labels是用于区分Pod、Service、Replication Controller的key/value键值对，仅使用在Pod、Service、 Replication Controller之间的关系识别，但对这些单元本身进行操作时得使用name标签。
5、Proxy
        Proxy不但解决了同一主宿机相同服务端口冲突的问题，还提供了Service转发服务端口对外提供服务的能力，Proxy后端使用了随机、轮循负载均衡算法。

        说说个人一点看法，目前Kubernetes 保持一周一小版本、一个月一大版本的节奏，迭代速度极快，同时也带来了不同版本操作方法的差异，另外官网文档更新速度相对滞后及欠缺，给初学者带来一定挑战。在上游接入层官方侧重点还放在GCE（Google Compute Engine）的对接优化，针对个人私有云还未推出一套可行的接入解决方案。在v0.5版本中才引用service代理转发的机制，且是通过iptables来实现，在高并发下性能令人担忧。但作者依然看好Kubernetes未来的发展，至少目前还未看到另外一个成体系、具备良好生态圈的平台，相信在V1.0时就会具备生产环境的服务支撑能力。

一、环境部署
1、平台版本说明
    1）Centos7.0 OS
    2）Kubernetes V0.6.2
    3）etcd version 0.4.6
    4）Docker version 1.3.2

2、平台环境说明


3、环境安装
    1）系统初始化工作（所有主机）
    系统安装-选择[最小化安装]
    
    CentOS 7.0默认使用的是firewall作为防火墙，这里改为iptables防火墙（熟悉度更高，非必须）。
    1.1、关闭firewall：
    
    1.2、安装iptables防火墙
    
    2）安装Etcd（192.168.1.10主机）
    
    启动服务etcd服务，如有提供第三方管理需求，另需在启动参数中添加“-cors='*'”参数。
    
    配置etcd服务防火墙，其中4001为服务端口，7001为集群数据交互端口。
  

    3）安装Kubernetes（涉及所有Master、Minion主机）
    通过yum源方式安装，默认将安装etcd, docker, and cadvisor相关包。
    
    升级至v0.6.2，覆盖bin文件即可，方法如下：
    
    校验安装结果，出版以下信息说明安装正常。
    
    4）Kubernetes配置（仅Master主机）
    master运行三个组件,包括apiserver、scheduler、controller-manager，相关配置项也只涉及这三块。
4.1、【/etc/kubernetes/config】
# Comma seperated list of nodes in the etcd cluster KUBE_ETCD_SERVERS="--etcd_servers=http://192.168.1.10:4001" # logging to stderr means we get it in the systemd journal KUBE_LOGTOSTDERR="--logtostderr=true" # journal message level, 0 is debug KUBE_LOG_LEVEL="--v=0" # Should this cluster be allowed to run privleged docker containers KUBE_ALLOW_PRIV="--allow_privileged=false"
4.2、【/etc/kubernetes/apiserver】
# The address on the local server to listen to. KUBE_API_ADDRESS="--address=0.0.0.0" # The port on the local server to listen on. KUBE_API_PORT="--port=8080" # How the replication controller and scheduler find the kube-apiserver KUBE_MASTER="--master=192.168.1.200:8080" # Port minions listen on KUBELET_PORT="--kubelet_port=10250" # Address range to use for services KUBE_SERVICE_ADDRESSES="--portal_net=10.254.0.0/16" # Add you own! KUBE_API_ARGS=""
4.3、【/etc/kubernetes/controller-manager】
# Comma seperated list of minions KUBELET_ADDRESSES="--machines= 192.168.1.201,192.168.1.202" # Add you own! KUBE_CONTROLLER_MANAGER_ARGS=""
4.4、【/etc/kubernetes/scheduler】
# Add your own! KUBE_SCHEDULER_ARGS=""
    启动master侧相关服务
    
    5）Kubernetes配置（仅minion主机）
        minion运行两个组件,包括kubelet、proxy，相关配置项也只涉及这两块。
    Docker启动脚本更新
    # vi /etc/sysconfig/docker
    添加：-H tcp://0.0.0.0:2375，最终配置如下，以便以后提供远程API维护。
    OPTIONS=--selinux-enabled -H tcp://0.0.0.0:2375 -H fd://

    修改minion防火墙配置，通常master找不到minion主机多半是由于端口没有连通。
    iptables -I INPUT -s 192.168.1.200 -p tcp --dport 10250 -j ACCEPT

    修改kubernetes minion端配置，以192.168.1.201主机为例，其它minion主机同理。
5.1、【/etc/kubernetes/config】
# Comma seperated list of nodes in the etcd cluster KUBE_ETCD_SERVERS="--etcd_servers=http://192.168.1.10:4001" # logging to stderr means we get it in the systemd journal KUBE_LOGTOSTDERR="--logtostderr=true" # journal message level, 0 is debug KUBE_LOG_LEVEL="--v=0" # Should this cluster be allowed to run privleged docker containers KUBE_ALLOW_PRIV="--allow_privileged=false"
5.2、【/etc/kubernetes/kubelet】
### # kubernetes kubelet (minion) config # The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces) KUBELET_ADDRESS="--address=0.0.0.0" # The port for the info server to serve on KUBELET_PORT="--port=10250" # You may leave this blank to use the actual hostname KUBELET_HOSTNAME="--hostname_override=192.168.1.201" # Add your own! KUBELET_ARGS=""
5.3、【/etc/kubernetes/proxy】
KUBE_PROXY_ARGS=""
启动kubernetes服务
    
3、校验安装(在master主机操作，或可访问master主机8080端口的client api主机)
  1) kubernetes常用命令
    
    或者通过Server api for REST方式（推荐，及时性更高）：
    
注：在新版kubernetes中，所有的操作命令都整合至kubectl，包括kubecfg、kubectl.sh、kubecfg.sh等

  2）创建测试pod单元
   # /home/kubermange/pods && cd /home/kubermange/pods
   # vi apache-pod.json
{   "id": "fedoraapache",   "kind": "Pod",   "apiVersion": "v1beta1",   "desiredState": {     "manifest": {       "version": "v1beta1",       "id": "fedoraapache",       "containers": [{         "name": "fedoraapache",         "image": "fedora/apache",         "ports": [{           "containerPort": 80,           "hostPort": 8080         }]       }]     }   },   "labels": {     "name": "fedoraapache"   } }
    # kubectl create -f apache-pod.json
    # kubectl get pod

    启动浏览器访问http://192.168.1.202:8080/，对应的服务端口切记在iptables中已添加。效果图如下：

    观察kubernetes在etcd中的数据存储结构


    观察单个pods的数据存储结构，以json的格式存储。


二、实战操作
    任务：通过Kubernetes创建一个LNMP架构的服务集群，以及观察其负载均衡，涉及镜像“yorko/webserver”已经push至registry.hub.docker.com，大家可以通过“docker pull yorko/webserver”下载。
    
1、 创建一个replication ，本例直接在replication模板中创建pod并复制，也可独立创建pod再通过replication来复制。
【replication/lnmp-replication.json】
{   "id": "webserverController",   "kind": "ReplicationController",   "apiVersion": "v1beta1",   "labels": {"name": "webserver"},   "desiredState": {     "replicas": 2,     "replicaSelector": {"name": "webserver_pod"},     "podTemplate": {       "desiredState": {          "manifest": {            "version": "v1beta1",            "id": "webserver",            "volumes": [              {"name":"httpconf", "source":{"hostDir":{"path":"/etc/httpd/conf"}}},              {"name":"httpconfd", "source":{"hostDir":{"path":"/etc/httpd/conf.d"}}},              {"name":"httproot", "source":{"hostDir":{"path":"/data"}}}             ],            "containers": [{              "name": "webserver",              "image": "yorko/webserver",              "command": ["/bin/sh", "-c", "/usr/bin/supervisord -c /etc/supervisord.conf"],              "volumeMounts": [                {"name":"httpconf", "mountPath":"/etc/httpd/conf"},                {"name":"httpconfd", "mountPath":"/etc/httpd/conf.d"},                {"name":"httproot", "mountPath":"/data"}               ],              "cpu": 100,              "memory": 50000000,              "ports": [{                "containerPort": 80,              },{                "containerPort": 22,             }]            }]          }        },        "labels": {"name": "webserver_pod"},       },   } }
    执行创建命令
    #kubectl create -f lnmp-replication.json
    观察生成的pod副本清单：
[root@SN2014-12-200 replication]# kubectl get pod

2、创建一个service，通过selector指定 "name": "webserver_pod"与pods关联。
【service/lnmp-service.json】
{   "id": "webserver",   "kind": "Service",   "apiVersion": "v1beta1",   "selector": {     "name": "webserver_pod",   },   "protocol": "TCP",   "containerPort": 80,   "port": 8080 }
    执行创建命令：
    # kubectl create -f lnmp-service.json

    登录minion主机（192.168.1.201），查询主宿机生成的iptables转发规则（最后一行）
    # iptables -nvL -t nat

    访问测试，http://192.168.1.201:40689/info.php，刷新浏览器发现proxy后端的变化，默认为随机轮循算法。



三、测试过程
    1、pods自动复制、销毁测试，观察kubernetes自动保持副本数（6份）
删除replicationcontrollers中一个副本fedoraapache
[root@SN2014-12-200 pods]# kubectl delete pods fedoraapache
I1219 23:59:39.305730    9516 restclient.go:133] Waiting for completion of operation 142530
fedoraapache

#自动生成出一个副本，保持6份的效果

2、测试不同角色模块中的hostPort
    1）pod中hostPort为空，而replicationcontrollers为指定端口，则异常；两侧都指定端口，相同或不同时都异常；pod的hostport为指定，另replicationcon为空，则正常；pod的hostport为空，另replicationcon为空，则正常；结论是在replicationcontrollers场景不能指定hostport，否则异常，待持续测试。
    2）结论：在replicationcontronllers.json中，"replicaSelector": {"name": "webserver_pod"}要与"labels": {"name": "webserver_pod"}以及service中的"selector": {"name": "webserver_pod"｝保持一致；

请关注下篇《kubernetes与HECD架构的整合》，近期推出。

参考文献：
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/fedora/fedora_manual_config.md
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/DESIGN.md
http://www.infoq.com/cn/articles/Kubernetes-system-architecture-introduction

转载请注明来源 http://blog.liuts.com/post/247/