GitLab CI 工作流程

GitLab CI 基本概念

在介绍 GitLab CI 之前，首先简单介绍一下 GitLab CI 里的一些基本概念，具体如下：

• Pipeline：Gitlab CI 里的流水线，每一次代码的提交触发 GitLab CI 都会产生一个 Pipeline。

• Stage：每个 Pipeline 由多个 Stage 组成，并且每个 Stage 是有先后顺序的。

• Job：GitLab CI 里的最小任务单元，负责完成具有一件事情，例如编译、测试、构建镜像等。每个 Job 都需要指定 Stage ，所以 Job 的执行顺序可以通过制定不同的 Stage 来实现。

• GitLab Runner：是具体执行 Job 的环境，每个 Runner 在同一时间只能执行一个 Job。

• Executor：每个 Runner 在向 GitLab 注册的时候需要指定 Executor，来决定通过何种类型的执行器来完成 Job。

GitLab CI 的工作流程

当有代码 push 到 GitLab 时，就会触发一个 Pipeline。然后进行编译，测试和镜像构建等操作等操作，其中每一步操作都为一个 Job。在 CD 阶段，会将 CI 阶段构建出来的结果根据情况部署到测试环境或生产环境。

GitLab Runner 介绍

Gitlab Runner 分类

GitLab 中有三种类型的 Runner ，分别为：

• shared：所有项目使用

• group：group下项目使用

• specific：指定项目使用

我们可以根据需要向 GitLab 注册不同类型的 Runner，注册的方式是相同的。

Gitlab Runner 工作过程

Runner 首先会向 GitLab 发起注册请求，请求内容中包含 token、tag 等信息，注册成功后 GitLab 会向 Runner 返回一个 token，后续的请求，Runner 都会携带这个请求。

注册成功后，Runner 就会不停的向 GitLab 请求 Job，时间间隔是 3s。若没有请求到 Job，GitLab 返回 204 No Content。如果请求到 Job，GitLab 会把 Job 信息返回回来，Runner 在接收到 Job 之后，会向 GitLab 发送一个确认请求，同时更新任务的状态。之后，Runner 开始 Job 的执行， 并且会定时地将中间数据，以 Patch 请求的方式发送给 GitLab。

GitLab Runner 的 Executor

Runner 在实际执行 Job 时，是通过调用 Executor 来完成的。Runner 在注册时提供了 SSH、Shell、Docker、docker-ssh、VirtualBox、Kubernetes 等不同类型的 Executor 来满足不同的场景和需求。

其中我们常用的有 Shell 和 Docker 等 Executor，Shell 类型主要是利用 Runner 所在主机的环境进行 Job的执行。而 Docker 类型的 Executor 在每个 Job 开始时，拉取镜像生产一个容器，在容器里完成 Job，在 Job 完成后，对应的容器就会被销毁。由于 Docker 隔离性强、轻量且回收，我们在使用时选用 Docker 类型的 Executor 去执行 Job，我们只要提前做好 Job 所需环境的 Docker 镜像，在每个 Job 定义好 image 即可使用对应的环境，操作便捷。

GitLab Runner 安装与配置

Docker 安装

由于我们需要使用 Docker 类型的 Executor，所以需要在运行 Runnner 的服务器上先安装 Docker，具体步骤如下（CentOS 环境）：

安装需要的软件包，yum-util 提供 yum-config-manager 功能，另外两个是 DeviceMapper 驱动依赖：

yum install -y yum-utils device-mapper-persistent-data lvm2

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

yum install docker-ce -y

systemctl start docker	
systemctl enable docker

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash	
sudo yum install gitlab-runner -y	
gitlab-runner start

GitLab Runner 注册与配置更新

启动 GitLab Runner 后还需要向 GitLab 进行注册，在注册前需要从 GitLab 里查询 token。不同类型的 Runner 对应的 token 获取的路径不同。shared Runner 需要 admin 权限的账号，按如下方式可以获取对应的 token。

其他两种类型在对应的页面下（ group 或 project 主页）的 setting—>CI/CD—>Runner 可以获取到 token。

Runner 的注册方式分为交互式和非交互式两种。其中交互式注册方式，在输入 gitlab-runner register 命令后，按照提示输入注册所需要的信息，包括 gitlab url、token 和 Runner 名字等。这边个人比较推荐非交互式命令，可以事先准备好命令，完成一键注册，并且非交互式注册方式提供了更多的注册选项，可以满足更多样化的需求。

按如下示例即可完成一个 Runner 的注册：

gitlab-runner register  --non-interactive  \	
--url "http://git.xxxx.cn"  \	
--registration-token  "xxxxxxxxxxx"  \	
--executor "docker"  \	
--docker-image alpine:latest  \	
--description "base-runner-docker"  \	
--tag-list "base-runner"  \	
--run-untagged="true"   \	
--docker-privileged="true"  \	
--docker-pull-policy "if-not-present" \	
--docker-volumes /etc/docker/daemon.json:/etc/docker/daemon.json \	
--docker-volumes /etc/gitlab-runner/key/docker-config.json:/root/.docker/config.json \	
--docker-volumes /etc/gitlab-runner/find_diff_files:/usr/bin/find_diff_files  \	
--docker-volumes /etc/gitlab-runner/key/id_rsa:/root/.ssh/id_rsa \	
--docker-volumes /etc/gitlab-runner/key/test-kube-config:/root/.kube/config

{ "insecure-registries" : ["http://docker.vpgame.cn"] }

gitlab-runner restart

部署完成后，可以在 GitLab 的 Web 管理界面查看到不同 Runner 的信息。

此外，如果一台服务需要注册多个 Runner ，可以修改 /etc/gitlab-runner/config.toml 中的 concurrent 值增加 Runner 的并发数，修改完之后同样需要重启 Runner。

为了满足不同服务对运行环境的多样化需求，我们需要为不同语言的服务提前准备不同的基础镜像用于构建镜像阶段使用。此外，CI/CD 所需要的工具镜像也需要制作，作为 Runner 执行 Job 时生成容器所需要的 Docker 镜像。

所有的镜像都以编写 Dockerfile 的形式通过 GitLab 进行管理，并且我们编写了 .gitlab-ci.yml 文件，使得每次有 Dockerfile 新增或者修改就会触发 Pipeline 进行镜像的构建并上传到 Harbor 上。这种管理方式有以下优点：

• 按照一定规则自动构建镜像，可以快速便捷地新建和更新镜像

• 根据规则可以找到镜像对应的 Dockerfile，明确镜像的具体组成

• 团队成员可以通过提交 Merge Request 自由地构建自己需要的镜像

镜像分类

• 运行时基础镜像：提供各个语言运行时必须的工具和相应的 package。

• CI 镜像：基于运行时基础镜像，添加单元测试、lint、静态分析等功能，用在 CI/CD 流程中的 test 环节。

• 打包上线镜像：用在 CI/CD 流程中的 build 和 deploy 环节。

Dockerfile目录结构

每个文件夹都有 Dockerfile 来描述镜像的基本情况，其中包含了 Java、PHP、Node 和 Go 等不同语言的运行时基础镜像和 CI 镜像，还有 docker-kubectl 这类工具镜像的 Dockerfile。

以 PHP 镜像为例：

php/	
├── 1.0	
│   ├── Dockerfile	
│   ├── ci-1.0	
│   │   └── Dockerfile	
│   ├── php.ini	
│   ├── read-zk-config	
│   ├── start_service.sh	
│   └── www.conf	
└── nginx	
    ├── Dockerfile	
    ├── api.vpgame.com.conf	
    └── nginx.conf

FROM php:7.1.16-fpm-alpine3.4	
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories\	
    && apk upgrade --update && apk add --no-cache --virtual build-dependencies $PHPIZE_DEPS \	
    tzdata postgresql-dev libxml2-dev libmcrypt libmcrypt-dev libmemcached-dev cyrus-sasl-dev autoconf  \	
    && apk add --no-cache freetype libpng libjpeg-turbo freetype-dev libpng-dev libjpeg-turbo-dev libmemcached-dev \	
    && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \	
    && echo "Asia/Shanghai" > /etc/timezone \	
    && docker-php-ext-configure gd \	
        --with-gd \	
        --with-freetype-dir=/usr/include/ \	
        --with-png-dir=/usr/include/ \	
        --with-jpeg-dir=/usr/include/ \	
    && docker-php-ext-install gd pdo pdo_mysql bcmath opcache \	
    && pecl install memcached apcu redis \	
    && docker-php-ext-enable memcached apcu redis \	
    && apk del build-dependencies \	
    && apk del tzdata \	
    && rm -rf /var/cache/apk/* \	
    && rm -rf /tmp/*  \	
    && rm -rf /working/* \	
    && rm -rf /usr/local/etc/php-fpm.d/*	
COPY start_service.sh /usr/local/bin/start_service.sh	
COPY read-zk-config /usr/local/bin/read-zk-config	
COPY php.ini /usr/local/etc/php/php.ini	
COPY www.conf /usr/local/etc/php-fpm.d/www.conf	
WORKDIR /work	
CMD ["start_service.sh"]

FROM docker.vpgame.cn/infra/php-1.0	
ENV PATH="/root/.composer/vendor/bin:${PATH}"	
ENV COMPOSER_ALLOW_SUPERUSER=1	
RUN mkdir -p /etc/ssh && echo "StrictHostKeyChecking no" >> /etc/ssh/ssh_config	
RUN apk --update add --no-cache make libc-dev autoconf gcc openssh-client git bash  &&\	
    echo "apc.enable_cli=1" >> /usr/local/etc/php/conf.d/docker-php-ext-apcu.ini	
RUN pecl install xdebug && docker-php-ext-enable xdebug &&\	
    echo -e "\nzend_extension=xdebug.so" >> /usr/local/etc/php/php.ini	
RUN wget https://vp-infra.oss-cn-beijing.aliyuncs.com/gitlab-ci/software/download/1.6.5/composer.phar -O /bin/composer && \	
    chmod +x /bin/composer && \	
    composer config -g -q repo.packagist composer https://packagist.laravel-china.org	
RUN composer global require -q phpunit/phpunit:~5.0 squizlabs/php_codesniffer:~3.0	
WORKDIR /	
CMD ["/bin/bash"]

另外 Nginx 目录下同样有 Dockerfile，来定制化我们 PHP 项目所需要的 Nginx 镜像。

在 GitLab 里第一次增加新的 Dockerfile 或者更改 Dockerfile 时，会触动 Pipeline 自动进行镜像的构建并上传的我们私有的 Docker Harbor 上。

镜像自动构建基本原理

由于各个镜像通过 Dockerfile 进行管理， Master 分支有新的合并，可以通过 git diff 命令找出合并前后新增或更新的 Dockerfile，然后根据这些 Dockerfile 依据一定的命名规则构建镜像，并上传到 Docker Harbor 上。

for FILE in `bash ./find_diff_files|grep Dockerfile|sort`;	
   do	
     DIR=`dirname "$FILE"`;	
     IMAGE_NAME=`echo $DIR | sed -e 's/\//-/g'`;	
     echo $CI_REGISTRY/$HARBOR_DIR/$IMAGE_NAME;	
     docker build -t $CI_REGISTRY/$HARBOR_DIR/$IMAGE_NAME -f $FILE $DIR;	
     docker push $CI_REGISTRY/$HARBOR_DIR/$IMAGE_NAME;	
   done

stages:	
  - build	
  - test	
  - deploy

unittest:	
  stage: test	
  image: docker.vpgame.cn/infra/php-1.0-ci-1.1	
  services:	
  - name: docker.vpgame.cn/infra/mysql-5.6-multi	
    alias: mysql	
  - name: redis:4.0	
    alias: redis_default	
  script:	
  - mv .env.tp .env	
  - composer install --no-dev	
  - phpunit -v --coverage-text --colors=never --coverage-html=coverage --stderr	
  artifacts:	
    when: on_success	
    paths:	
    - vendor/	
    - coverage/	
    expire_in: 1 hour	
  coverage: '/^\s*Lines:\s*\d+.\d+\%/'	
  only:	
  - branches	
  - tags	
  tags:	
  - base-runner

dependencies:	
  - unittest

job:	
  only:	
    - /^issue-.*$/	
  except:	
    - branches

这个例子中，只有以 issue- 开头 tag 标记才会触发 Job。如果不加 except 参数，以 issue- 开头的分支 或者 tag 标记会会触发 Job。

tags，tags关键字主要是用来指定运行的 Runner 类型。在我们实际运用中，部署测试环境和生产环境所采用的 Runner 是不一样的，它们是通过不同的 tag 去标识区分。

所以，我们在 Job 定义中，通过 tags 指定 Runner 的值，来指定所需要的 Runner。

我们可以看到 Job 的定义非常的清晰和灵活，关于 Job 的使用远不止这些功能，更详细的用法可以参考 GitLab CI/CD 官方文档。

CI/CD 流程编排

在清楚了如何描述一个 Job 之后，我们通过定义一个个 Job，并进行编排形成 Pipelines。因为我们可以描述设定 Job 的触发条件，所以通过不同的条件可以触发形成不一样的 Pipelines。

在 PHP 项目 Kubernetes 上线过程中，我们规定了合并 Master 分支会进行 lint、unitest、build-test 以及 deploy-test 四个 Job。

在测试环境验证通过之后，我们再通过打 tag 进行正式环境的上线。此处的 Pipelines 包含了 unittest、build-pro 和 deploy-pro 三个 Job。

在 .gitlab-ci.yml 文件中，test 阶段主要完成 lint 和 unitest 两个 Job，不同的语言在进行 Job 定义时会各有不同。我们重点来看一下 build 和 deploy 两个 stage 的 Job 描述。

build stage：

# Build stage	
.build-op:	
  stage: build	
  dependencies:	
  - unittest	
  image: docker.vpgame.cn/infra/docker-kubectl-1.0	
  services:	
  - name: docker:dind	
    entrypoint: ["dockerd-entrypoint.sh"]	
  script:	
  - echo "Image name:" ${DOCKER_IMAGE_NAME}	
  - docker build -t ${DOCKER_IMAGE_NAME} .	
  - docker push ${DOCKER_IMAGE_NAME}	
  tags:	
  - base-runner	
build-test:	
 extends: .build-op	
 variables:	
   DOCKER_IMAGE_NAME:  ${DOCKER_REGISTRY_PREFIX}/${CI_PROJECT_PATH}:${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}	
 only:	
 - /^testing/	
 - master	
build-prod:	
 extends: .build-op	
 variables:	
   DOCKER_IMAGE_NAME:  ${DOCKER_REGISTRY_PREFIX}/${CI_PROJECT_PATH}:${CI_COMMIT_TAG}	
 only:	
 - tags

# Deploy stage	
.deploy-op:	
  stage: deploy	
  image: docker.vpgame.cn/infra/docker-kubectl-1.0	
  script:	
  - echo "Image name:" ${DOCKER_IMAGE_NAME}	
  - echo ${APP_NAME}	
  - sed -i "s~__NAMESPACE__~${NAMESPACE}~g" deployment.yml service.yml	
  - sed -i "s~__APP_NAME__~${APP_NAME}~g" deployment.yml service.yml	
  - sed -i "s~__PROJECT_NAME__~${CI_PROJECT_NAME}~g" deployment.yml	
  - sed -i "s~__PROJECT_NAMESPACE__~${CI_PROJECT_NAMESPACE}~g" deployment.yml	
  - sed -i "s~__GROUP_NAME__~${GROUP_NAME}~g" deployment.yml	
  - sed -i "s~__VERSION__~${VERSION}~g" deployment.yml	
  - sed -i "s~__REPLICAS__~${REPLICAS}~g" deployment.yml	
  - kubectl apply -f deployment.yml	
  - kubectl apply -f service.yml	
  - kubectl rollout status -f deployment.yml	
  - kubectl get all,ing -l app=${APP_NAME} -n $NAMESPACE	
# Deploy test environment	
deploy-test:	
  variables:	
    REPLICAS: 2	
    VERSION: ${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}	
  extends: .deploy-op	
  environment:	
    name: test	
    url: http://example.com	
  only:	
  - /^testing/	
  - master	
  tags:	
  - base-runner	
# Deploy prod environment	
deploy-prod:	
  variables:	
    REPLICAS: 3	
    VERSION: ${CI_COMMIT_TAG}	
  extends: .deploy-op	
  environment:	
    name: prod	
    url: http://example.com	
  only:	
  - tags	
  tags:	
  - pro-deploy

与 build 阶段类似，先先定义一个 .deploy-op 的 Job，然后 deploy-test 和 deploy-prod 都通过 extend 进行继承。

.deploy-op 主要完成了对 Kubernetes Deployment 和 Service 模板文件的一些变量的替换，以及根据生成的 Deployment 和 Service 文件进行 Kubernetes 服务的部署。

deploy-test 和 deploy-prod 两个 Job 定义了不同变量（variables）以及触发条件（only）。除此之外， deploy-prod 通过 tags 关键字来使用不同的 Runner，将部署的目标集群指向给生产环境的 Kubernetes。

这里还有一个关键字 environment 需要特别说明，在定义了 environment 之后，我们可以在 GitLab 中查看每次部署的一些信息。除了查看每次部署的一些信息之外，我们还可以很方便地进行重新部署和回滚。

可以看到，通过对 Job 的关键字进行配置，我们可以灵活地编排出我们所需要的 CI/CD 流程，非常好地满足多样化的场景。

在 CI/CD 流程中完成 Docker 镜像的打包任务之后需要将服务所对应的镜像部署到 Kubernetes 集群中。Kubernetes 提供了多种可以编排调度的资源对象。首先，我们简单了解一下 Kubernetes 中的一些基本资源。

Kubernetes 基本资源对象概览

Pod

Pod 作为无状态应用的运行实体是其中最常用的一种资源对象， Kubernetes 中资源调度最小的基本单元，它包含一个或多个紧密联系的容器。这些容器共享存储、网络和命名空间，以及如何运行的规范。

在 Kubernetes 中， Pod 是非持久的，会因为节点故障或者网络不通等情况而被销毁和重建。所以我们在 Kubernetes 中一般不会直接创建一个独立的 Pod，而是通过多个 Pod 对外提供服务。

ReplicaSet

ReplicaSet 是 Kubernetes 中的一种副本控制器，控制由其管理的 Pod，使 Pod 副本的数量维持在预设的个数。ReplicaSets 可以独立使用，但是在大多数场景下被 Deployments 作为协调 Pod 创建，删除和更新的机制。

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义方法。通过在 Deployment 中进行目标状态的描述，Deployment controller 会将 Pod 和 ReplicaSet 的实际状态改变为所设定的目标状态。Deployment 典型的应用场景包括：

• 定义 Deployment 来创建 Pod 和 ReplicaSet

• 滚动升级和回滚应用

• 扩容和缩容

• 暂停和继续 Deployment

Service

在 Kubernetes 中，Pod 会被随时创建或销毁，每个 Pod 都有自己的 IP，这些 IP 也无法持久存在，所以需要 Service 来提供服务发现和负载均衡能力。Service 是一个定义了一组 Pod 的策略的抽象，通过 Label Selector 来确定后端访问的 Pod，从而为客户端访问服务提供了一个入口。每个 Service 会对应一个集群内部的 ClusterIP，集群内部可以通过 ClusterIP 访问一个服务。如果需要对集群外部提供服务，可以通过 NodePort 或 LoadBalancer 方式。

deployment.yml 配置

deployment.yml 文件用来定义 Deployment。首先通过一个简单的 deployment.yml 配置文件熟悉 Deployment 的配置格式。

上图中 deployment.yml 分为8个部分，分别如下：

1. apiVersion 为当前配置格式的版本

2. kind 指定了资源类型，这边当然是 Deployment

3. metadata 是该资源的元数据，其中 name 是必需的数据项，还可以指定 label 给资源加上标签

4. spec 部分是该 Deployment 的规格说明

5. spec.replicas 指定了 Pod 的副本数量

6. spec.template 定义 Pod 的基本信息，通过 spec.template.metadata 和 spec.template.spec 指定

7. spec.template.metadata 定义 Pod 的元数据。至少需要定义一个 label 用于 Service 识别转发的 Pod， label 是通过 key-value 形式指定的

8. spec.template.spec 描述 Pod 的规格，此部分定义 Pod 中每一个容器的属性，name 和 image 是必需项

在实际应用中，还有更多灵活个性化的配置。我们在 Kubernetes 的部署实践中制定了相关的规范，在以上基础结构上进行配置，得到满足我们实际需求的 deployment.yml 配置文件。

在 Kubernetes 的迁移实践中，我们主要在以下方面对 Deployment 的配置进行了规范的约定：

文件模板化

首先我们的 deployment.yml 配置文件是带有变量的模版文件，如下所示：

apiVersion: apps/v1beta2	
kind: Deployment	
metadata:	
  labels:	
    app: __APP_NAME__	
    group: __GROUP_NAME__	
  name: __APP_NAME__	
  namespace: __NAMESPACE__

...	
  spec:	
    ...	
    template:	
      ...	
      spec:	
        ...	
        affinity:	
          nodeAffinity:	
            requiredDuringSchedulingIgnoredDuringExecution:	
              nodeSelectorTerms:	
              - matchExpressions:	
                - key: group	
                  operator: In	
                  values:	
                  - __GROUP_NAME__	
     ...

...	
spec:	
  ...	
  template:	
    ...	
    spec:	
      ...	
      containers:	
      - name: fpm	
        livenessProbe:	
          httpGet:	
            path: /__PROJECT_NAME__	
            port: 80	
          initialDelaySeconds: 3	
          periodSeconds: 5	
        readinessProbe:	
          httpGet:	
            path: /__PROJECT_NAME__	
            port: 80	
          initialDelaySeconds: 3	
          periodSeconds: 5	
        ...	
   ...

升级策略配置

升级策略我们选择 RollingUpdate 的方式，即在升级过程中滚动式地逐步新建新版本的 Pod，待新建 Pod 正常启动后逐步 kill 掉老版本的 Pod，最终全部新版本的 Pod 替换为旧版本的 Pod。

我们还可以设置 maxSurge 和 maxUnavailable 的值分别控制升级过程中最多可以比原先设置多出的 Pod 比例以及升级过程中最多有多少比例 Pod 处于无法提供服务的状态。

...	
spec:	
  ...	
  strategy:	
    rollingUpdate:	
      maxSurge: 25%	
      maxUnavailable: 25%	
    type: RollingUpdate	
...

...	
spec:	
  ...	
  template:	
    ...	
    spec:	
      ...	
      containers:	
      - name: fpm	
        env:	
        - name: aliyun_logs_vpgame	
          value: stdout	
        - name: aliyun_logs_vpgame_tags	
          value: topic=__APP_NAME__	
        ...	
   ...

...	
spec:	
 ...	
 template:	
    metadata:	
      annotations:	
        prometheus.io/scrape: "true"	
        prometheus.io/port: "80"        	
        prometheus.io/path: /{{ project_name }}/metrics	
  ...

apiVersion: v1	
kind: Service	
metadata:	
  annotations:	
    service.beta.kubernetes.io/alicloud-loadbalancer-address-type: intranet	
  labels:	
    app: __APP_NAME__	
  name: __APP_NAME__	
  namespace: __NAMESPACE__	
spec:	
  ports:	
  - port: 80	
    protocol: TCP	
    targetPort: 80	
  selector:	
    app: __APP_NAME__	
  type: LoadBalancer

对 Service 的定义相比于 Deoloyment 要简单的多，通过定义 spec.ports 的相关参数可以指定 Service 的对外暴露的端口已经转发到后端 Pod 的端口。spec.selector 则是指定了需要转发的 Pod 的 label。

另外，我们这边是通过负载均衡器类型对外提供服务，这是通过定义 spec.type 为 LoadBalancer 实现的。通过增加 metadata.annotations 为 service.beta.kubernetes.io/alicloud-loadbalancer-address-type: intranet 可以在对该 Service 进行创建的同时创建一个阿里云内网 SLB 作为对该 Service 请求流量的入口。

如上图所示，EXTERNAL-IP 即为 SLB 的 IP。

在以上工作的基础上，我们对各个服务划分为几类（目前基本上按照语言进行划分），然后为每一类中的服务通过 .gitlab-ci.yml 制定一套统一的 CI/CD 流程，与此相同的，同一类中的服务共用一个 Deployment 和 Service 模板。这样我们在进行服务迁移到 Kubernetes 环境时可以实现快速高效地迁移。

当然，这只是迁移实践路上迈出的第一步，在 Kubernetes 中的服务的稳定性、性能、自动伸缩等方面还需要更深入地探索和研究。

Kubernetes实战培训

Kubernetes实战培训将于2019年10月18日在深圳开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：云原生介绍、微服务；Docker基础、Docker工作原理、镜像、网络、存储、数据卷、安全；Kubernetes架构、核心组件、常用对象、网络、存储、认证、服务发现、调度和服务质量保证、日志、监控、告警、Helm、实践案例等，点击下方图片或者阅读原文链接查看详情。