在Kubernetes上运行高可用的WordPress和MySQL

WordPress是用于编辑和发布Web内容的主流平台。在本教程中,我将逐步介绍如何使用Kubernetes来构建高可用性(HA)WordPress部署。

WordPress由两个主要组件组成:WordPress PHP服务器和用于存储用户信息、帖子和网站数据的数据库。我们需要让整个应用程序中这两个组件在高可用的同时都具备容错能力。

在硬件和地址发生变化的时候,运行高可用服务可能会很困难:非常难维护。借助Kubernetes以及其强大的网络组件,我们可以部署高可用的WordPress站点和MySQL数据库,而无需(几乎无需)输入单个IP地址。

在本教程中,我将向你展示如何在Kubernetes中创建存储类、服务、配置映射和集合,如何运行高可用MySQL,以及如何将高可用WordPress集群挂载到数据库服务上。如果你还没有Kubernetes集群,你可以在Amazon、Google或者Azure上轻松找到并且启动它们,或者在任意的服务器上使用Rancher Kubernetes Engine (RKE)

架构概述

现在我来简要介绍一下我们将要使用的技术及其功能:
WordPress应用程序文件的存储:具有GCE持久性磁盘备份的NFS存储
数据库集群:带有用于奇偶校验的xtrabackup的MySQL
应用程序级别:挂载到NFS存储的WordPress DockerHub映像
负载均衡和网络:基于Kubernetes的负载均衡器和服务网络

该体系架构如下所示:

未分类

在K8s中创建存储类、服务和配置映射

在Kubernetes中,状态集提供了一种定义pod初始化顺序的方法。我们将使用一个有状态的MySQL集合,因为它能确保我们的数据节点有足够的时间在启动时复制先前pods中的记录。我们配置这个状态集的方式可以让MySQL主机在其他附属机器之前先启动,因此当我们扩展时,可以直接从主机将克隆发送到附属机器上。

首先,我们需要创建一个持久卷存储类和配置映射,以根据需要应用主从配置。我们使用持久卷,避免数据库中的数据受限于集群中任何特定的pods。这种方式可以避免数据库在MySQL主机pod丢失的情况下丢失数据,当主机pod丢失时,它可以重新连接到带xtrabackup的附属机器,并将数据从附属机器拷贝到主机中。MySQL的复制负责主机-附属的复制,而xtrabackup负责附属-主机的复制。

要动态分配持久卷,我们使用GCE持久磁盘创建存储类。不过,Kubernetes提供了各种持久性卷的存储方案:

# storage-class.yamlkind: StorageClassapiVersion: storage.k8s.io/v1metadata:
 name: slowprovisioner: kubernetes.io/gce-pdparameters:
 type: pd-standard  zone: us-central1-a

创建类,并且使用指令:$ kubectl create -f storage-class.yaml部署它。

接下来,我们将创建configmap,它指定了一些在MySQL配置文件中设置的变量。这些不同的配置由pod本身选择有关,但它们也为我们提供了一种便捷的方式来管理潜在的配置变量。

创建名为mysql-configmap.yaml的YAML文件来处理配置,如下:

# mysql-configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
 name: mysql  labels:
   app: mysqldata:
 master.cnf: |    # Apply this config only on the master.
   [mysqld]
   log-bin
   skip-host-cache
   skip-name-resolve  slave.cnf: |    # Apply this config only on slaves.
   [mysqld]
   skip-host-cache
   skip-name-resolve

创建configmap并使用指令:$ kubectl create -f mysql-configmap.yaml
来部署它。

接下来我们要设置服务以便MySQL pods可以互相通信,并且我们的WordPress pod可以使用mysql-services.yaml与MySQL通信。这也为MySQL服务启动了服务负载均衡器。

# mysql-services.yaml# Headless service for stable DNS entries of StatefulSet members.apiVersion: v1kind: Servicemetadata:
 name: mysql  labels:
   app: mysqlspec:
 ports:
 - name: mysql    port: 3306  clusterIP: None  selector:
   app: mysql

通过此服务声明,我们就为实现一个多写入、多读取的MySQL实例集群奠定了基础。这种配置是必要的,每个WordPress实例都可能写入数据库,所以每个节点都必须准备好读写。

执行命令 $ kubectl create -f mysql-services.yaml来创建上述的服务。

到这为止,我们创建了卷声明存储类,它将持久磁盘交给所有请求它们的容器,我们配置了configmap,在MySQL配置文件中设置了一些变量,并且我们配置了一个网络层服务,负责对MySQL服务器请求的负载均衡。上面说的这些只是准备有状态集的框架, MySQL服务器实际在哪里运行,我们接下来将继续探讨。

配置有状态集的MySQL

本节中,我们将编写一个YAML配置文件应用于使用了状态集的MySQL实例。

我们先定义我们的状态集:

1、创建三个pods并将它们注册到MySQL服务上。
2、按照下列模版定义每个pod:

  • 为主机MySQL服务器创建初始化容器,命名为init-mysql.
  • 给这个容器使用mysql:5.7镜像
  • 运行一个bash脚本来启动xtrabackup
  • 为配置文件和configmap挂载两个新卷

3、为主机MySQL服务器创建初始化容器,命名为clone-mysql.

  • 为该容器使用Google Cloud Registry的xtrabackup:1.0镜像
  • 运行bash脚本来克隆上一个同级的现有xtrabackups
  • 为数据和配置文件挂在两个新卷
  • 该容器有效地托管克隆的数据,便于新的附属容器可以获取它

4、为附属MySQL服务器创建基本容器

  • 创建一个MySQL附属容器,配置它连接到MySQL主机
  • 创建附属xtrabackup容器,配置它连接到xtrabackup主机

5、创建一个卷声明模板来描述每个卷,每个卷是一个10GB的持久磁盘
下面的配置文件定义了MySQL集群的主节点和附属节点的行为,提供了运行附属客户端的bash配置,并确保在克隆之前主节点能够正常运行。附属节点和主节点分别获得他们自己的10GB卷,这是他们在我们之前定义的持久卷存储类中请求的。

apiVersion: apps/v1beta1kind: StatefulSetmetadata:
 name: mysqlspec:
 selector:
   matchLabels:
     app: mysql  serviceName: mysql  replicas: 3  template:
   metadata:
     labels:
       app: mysql    spec:
     initContainers:
     - name: init-mysql        image: mysql:5.7        command:
       - bash        - "-c"
       - |
         set -ex          # Generate mysql server-id from pod ordinal index.
         [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
         ordinal=${BASH_REMATCH[1]}
         echo [mysqld] > /mnt/conf.d/server-id.cnf          # Add an offset to avoid reserved server-id=0 value.
         echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf          # Copy appropriate conf.d files from config-map to emptyDir.
         if [[ $ordinal -eq 0 ]]; then
           cp /mnt/config-map/master.cnf /mnt/conf.d/
         else
           cp /mnt/config-map/slave.cnf /mnt/conf.d/
         fi        volumeMounts:
       - name: conf          mountPath: /mnt/conf.d        - name: config-map          mountPath: /mnt/config-map      - name: clone-mysql        image: gcr.io/google-samples/xtrabackup:1.0        command:
       - bash        - "-c"
       - |
         set -ex          # Skip the clone if data already exists.
         [[ -d /var/lib/mysql/mysql ]] && exit 0          # Skip the clone on master (ordinal index 0).
         [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
         ordinal=${BASH_REMATCH[1]}
         [[ $ordinal -eq 0 ]] && exit 0          # Clone data from previous peer.
         ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql          # Prepare the backup.
         xtrabackup --prepare --target-dir=/var/lib/mysql        volumeMounts:
       - name: data          mountPath: /var/lib/mysql          subPath: mysql        - name: conf          mountPath: /etc/mysql/conf.d      containers:
     - name: mysql        image: mysql:5.7        env:
       - name: MYSQL_ALLOW_EMPTY_PASSWORD          value: "1"
       ports:
       - name: mysql          containerPort: 3306        volumeMounts:
       - name: data          mountPath: /var/lib/mysql          subPath: mysql        - name: conf          mountPath: /etc/mysql/conf.d        resources:
         requests:
           cpu: 500m            memory: 1Gi        livenessProbe:
         exec:
           command: ["mysqladmin", "ping"]
         initialDelaySeconds: 30          periodSeconds: 10          timeoutSeconds: 5        readinessProbe:
         exec:
           # Check we can execute queries over TCP (skip-networking is off).
           command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
         initialDelaySeconds: 5          periodSeconds: 2          timeoutSeconds: 1      - name: xtrabackup        image: gcr.io/google-samples/xtrabackup:1.0        ports:
       - name: xtrabackup          containerPort: 3307        command:
       - bash        - "-c"
       - |
         set -ex
         cd /var/lib/mysql          # Determine binlog position of cloned data, if any.
         if [[ -f xtrabackup_slave_info ]]; then            # XtraBackup already generated a partial "CHANGE MASTER TO" query
           # because we're cloning from an existing slave.
           mv xtrabackup_slave_info change_master_to.sql.in            # Ignore xtrabackup_binlog_info in this case (it's useless).
           rm -f xtrabackup_binlog_info
         elif [[ -f xtrabackup_binlog_info ]]; then            # We're cloning directly from master. Parse binlog position.
           [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
           rm xtrabackup_binlog_info
           echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
         fi          # Check if we need to complete a clone by starting replication.
         if [[ -f change_master_to.sql.in ]]; then
           echo "Waiting for mysqld to be ready (accepting connections)"
           until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done

           echo "Initializing replication from clone position"
           # In case of container restart, attempt this at-most-once.
           mv change_master_to.sql.in change_master_to.sql.orig
           mysql -h 127.0.0.1 <<EOF
         $(<change_master_to.sql.orig),
           MASTER_HOST='mysql-0.mysql',
           MASTER_USER='root',
           MASTER_PASSWORD='',
           MASTER_CONNECT_RETRY=10;
         START SLAVE;
         EOF
         fi          # Start a server to send backups when requested by peers.
         exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c             "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
       volumeMounts:
       - name: data          mountPath: /var/lib/mysql          subPath: mysql
       - name: conf          mountPath: /etc/mysql/conf.d        resources:
         requests:
           cpu: 100m            memory: 100Mi      volumes:
     - name: conf        emptyDir: {}
     - name: config-map        configMap:
         name: mysql  volumeClaimTemplates:
 - metadata:
     name: data    spec:
     accessModes: ["ReadWriteOnce"]
     resources:
       requests:
         storage: 10Gi

将该文件存为mysql-statefulset.yaml,输入kubectl=”” create=”” -f=”” mysql-statefulset.yaml并让kubernetes部署你的数据库。
现在当你调用$=”” kubectl=”” get=”” pods,你应该看到3个pods启动或者准备好,其中每个pod上都有两个容器。主节点pod表示为mysql-0,而附属的pods为mysql-1和mysql-2.让pods执行几分钟来确保xtrabackup服务在pod之间正确同步,然后进行wordpress的部署。
您可以检查单个容器的日志来确认没有错误消息抛出。 查看日志的命令为$=”” logs=”” <container_name=””>

主节点xtrabackup容器应显示来自附属的两个连接,并且日志中不应该出现任何错误。

部署高可用的WordPress

整个过程的最后一步是将我们的WordPress pods部署到集群上。为此我们希望为WordPress的服务和部署进行定义。

为了让WordPress实现高可用,我们希望每个容器运行时都是完全可替换的,这意味着我们可以终止一个,启动另一个而不需要对数据或服务可用性进行修改。我们也希望能够容忍至少一个容器的失误,有一个冗余的容器负责处理slack。

WordPress将重要的站点相关数据存储在应用程序目录/var/www/html中。对于要为同一站点提供服务的两个WordPress实例,该文件夹必须包含相同的数据。

当运行高可用WordPress时,我们需要在实例之间共享/var/www/html文件夹,因此我们定义一个NGS服务作为这些卷的挂载点。
下面是设置NFS服务的配置,我提供了纯英文的版本:

# nfs.yaml# Define the persistent volume claimapiVersion: v1kind: PersistentVolumeClaimmetadata:
name: nfs  labels:
  demo: nfs  annotations:
  volume.alpha.kubernetes.io/storage-class: anyspec:
accessModes: [ "ReadWriteOnce" ]
resources:
  requests:
    storage: 200Gi---# Define the Replication ControllerapiVersion: v1kind: ReplicationControllermetadata:
name: nfs-serverspec:
replicas: 1  selector:
  role: nfs-server  template:
  metadata:
    labels:
      role: nfs-server    spec:
    containers:
    - name: nfs-server        image: gcr.io/google_containers/volume-nfs:0.8        ports:
        - name: nfs            containerPort: 2049          - name: mountd            containerPort: 20048          - name: rpcbind            containerPort: 111        securityContext:
        privileged: true        volumeMounts:
        - mountPath: /exports            name: nfs-pvc      volumes:
      - name: nfs-pvc          persistentVolumeClaim:
          claimName: nfs---# Define the Servicekind: ServiceapiVersion: v1metadata:
name: nfs-serverspec:
ports:
  - name: nfs      port: 2049    - name: mountd      port: 20048    - name: rpcbind      port: 111  selector:
  role: nfs-server

使用指令$ kubectl create -f nfs.yaml部署NFS服务。现在,我们需要运行$ kubectl describe services nfs-server获得IP地址,这在后面会用到。

注意:将来,我们可以使用服务名称讲这些绑定在一起,但现在你需要对IP地址进行硬编码。

# wordpress.yamlapiVersion: v1kind: Servicemetadata:
 name: wordpress  labels:
   app: wordpressspec:
 ports:
   - port: 80  selector:
   app: wordpress    tier: frontend  type: LoadBalancer---apiVersion: v1kind: PersistentVolumemetadata:
 name: nfsspec:
 capacity:
   storage: 20G  accessModes:
   - ReadWriteMany  nfs:
   # FIXME: use the right IP
   server: <ip of="" the="" nfs="" service="">    path: "/"---apiVersion: v1kind: PersistentVolumeClaimmetadata:
 name: nfsspec:
 accessModes:
   - ReadWriteMany  storageClassName: ""
 resources:
   requests:
     storage: 20G---apiVersion: apps/v1beta1 # for versions before 1.8.0 use apps/v1beta1kind: Deploymentmetadata:
 name: wordpress  labels:
   app: wordpressspec:
 selector:
   matchLabels:
     app: wordpress      tier: frontend  strategy:
   type: Recreate  template:
   metadata:
     labels:
       app: wordpress        tier: frontend    spec:
     containers:
     - image: wordpress:4.9-apache        name: wordpress        env:
       - name: WORDPRESS_DB_HOST          value: mysql        - name: WORDPRESS_DB_PASSWORD          value: ""
       ports:
       - containerPort: 80          name: wordpress        volumeMounts:
       - name: wordpress-persistent-storage          mountPath: /var/www/html      volumes:
     - name: wordpress-persistent-storage        persistentVolumeClaim:
           claimName: nfs

我们现在创建了一个持久卷声明,和我们之前创建的NFS服务建立映射,然后将卷附加到WordPress pod上,即/var/www/html根目录,这也是WordPress安装的地方。这里保留了集群中WordPress pods的所有安装和环境。有了这些配置,我们就可以对任何WordPress节点进行启动和拆除,而数据能够留下来。因为NFS服务需要不断使用物理卷,该卷将保留下来,并且不会被回收或错误分配。

使用指令$ kubectl create -f wordpress.yaml部署WordPress实例。默认部署只会运行一个WordPress实例,可以使用指令$ kubectl scale –replicas= deployment/wordpress扩展WordPress实例数量。

要获得WordPress服务负载均衡器的地址,你需要输入$ kubectl get services wordpress
并从结果中获取EXTERNAL-IP字段来导航到WordPress。

弹性测试

OK,现在我们已经部署好了服务,那我们来拆除一下它们,看看我们的高可用架构如何处理这些混乱。在这种部署方式中,唯一剩下的单点故障就是NFS服务(原因总结在文末结论中)。你应该能够测试其他任何的服务来了解应用程序是如何响应的。现在我已经启动了WordPress服务的三个副本,以及MySQL服务中的一个主两个附属节点。

首先,我们先kill掉其他而只留下一个WordPress节点,来看看应用如何响应:$ kubectl scale –replicas=1 deployment/wordpress现在我们应该看到WordPress部署的pod数量有所下降。$ kubectl get pods应该能看到WordPress pods的运行变成了1/1。

点击WordPress服务IP,我们将看到与之前一样的站点和数据库。如果要扩展复原,可以使用$ kubectl scale –replicas=3 deployment/wordpress再一次,我们可以看到数据包留在了三个实例中。

下面测试MySQL的状态集,我们使用指令缩小备份的数量:$ kubectl scale statefulsets mysql –replicas=1我们会看到两个附属从该实例中丢失,如果主节点在此时丢失,它所保存的数据将保存在GCE持久磁盘上。不过就必须手动从磁盘恢复数据。

如果所有三个MySQL节点都关闭了,当新节点出现时就无法复制。但是,如果一个主节点发生故障,一个新的主节点就会自动启动,并且通过xtrabackup重新配置来自附属节点的数据。因此,在运行生产数据库时,我不建议以小于3的复制系数来运行。在结论段中,我们会谈谈针对有状态数据有什么更好的解决方案,因为Kubernetes并非真正是为状态设计的。

结论和建议

到现在为止,你已经完成了在Kubernetes构建并部署高可用WordPress和MySQL的安装!

不过尽管取得了这样的效果,你的研究之旅可能还远没有结束。可能你还没注意到,我们的安装仍然存在着单点故障:NFS服务器在WordPress pods之间共享/var/www/html目录。这项服务代表了单点故障,因为如果它没有运行,在使用它的pods上html目录就会丢失。教程中我们为服务器选择了非常稳定的镜像,可以在生产环境中使用,但对于真正的生产部署,你可以考虑使用GlusterFS对WordPress实例共享的目录开启多读多写。

这个过程涉及在Kubernetes上运行分布式存储集群,实际上这不是Kubernetes构建的,因此尽管它运行良好,但不是长期部署的理想选择。

对于数据库,我个人建议使用托管的关系数据库服务来托管MySQL实例,因为无论是Google的CloudSQL还是AWS的RDS,它们都以更合理的价格提供高可用和冗余处理,并且不需担心数据的完整性。Kuberntes并不是围绕有状态的应用程序设计的,任何建立在其中的状态更多都是事后考虑。目前有大量的解决方案可以在选择数据库服务时提供所需的保证。

也就是说,上面介绍的是一种理想的流程,由Kubernetes教程、web中找到的例子创建一个有关联的现实的Kubernetes例子,并且包含了Kubernetes 1.8.x中所有的新特性。

我希望通过这份指南,你能在部署WordPress和MySQL时获得一些惊喜的体验,当然,更希望你的运行一切正常。

Kubernetes之路 2 – 利用LXCFS提升容器资源可见性

未分类

这是本系列的第2篇内容,将介绍在Docker和Kubernetes环境中解决遗留应用无法识别容器资源限制的问题。

Linuxs利用Cgroup实现了对容器的资源限制,但在容器内部依然缺省挂载了宿主机上的procfs的/proc目录,其包含如:meminfo, cpuinfo,stat, uptime等资源信息。一些监控工具如free/top或遗留应用还依赖上述文件内容获取资源配置和使用情况。当它们在容器中运行时,就会把宿主机的资源状态读取出来,引起错误和不便。

LXCFS简介

社区中常见的做法是利用 lxcfs来提供容器中的资源可见性。lxcfs 是一个开源的FUSE(用户态文件系统)实现来支持LXC容器,它也可以支持Docker容器。

LXCFS通过用户态文件系统,在容器中提供下列 procfs 的文件。

/proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime

LXCFS的示意图如下

未分类

比如,把宿主机的 /var/lib/lxcfs/proc/memoinfo 文件挂载到Docker容器的/proc/meminfo位置后。容器中进程读取相应文件内容时,LXCFS的FUSE实现会从容器对应的Cgroup中读取正确的内存限制。从而使得应用获得正确的资源约束设定。

Docker环境下LXCFS使用

注:

  • 本文采用CentOS 7.4作为测试环境,并已经开启FUSE模块支持。
  • Docker for Mac/Minikube等开发环境由于采用高度剪裁过的操作系统,无法支持FUSE,并运行LXCFS进行测试。

安装 lxcfs 的RPM包

wget https://copr-be.cloud.fedoraproject.org/results/ganto/lxd/epel-7-x86_64/00486278-lxcfs/lxcfs-2.0.5-3.el7.centos.x86_64.rpm
yum install lxcfs-2.0.5-3.el7.centos.x86_64.rpm  

启动 lxcfs

lxcfs /var/lib/lxcfs &  

测试

$docker run -it -m 256m 
      -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:rw 
      -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:rw 
      -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw 
      -v /var/lib/lxcfs/proc/stat:/proc/stat:rw 
      -v /var/lib/lxcfs/proc/swaps:/proc/swaps:rw 
      -v /var/lib/lxcfs/proc/uptime:/proc/uptime:rw 
      ubuntu:16.04 /bin/bash

root@f4a2a01e61cd:/# free
              total        used        free      shared  buff/cache   available
Mem:         262144         708      261436        2364           0      261436
Swap:             0           0           0

我们可以看到total的内存为256MB,配置已经生效。

lxcfs 的 Kubernetes实践

一些同学问过如何在Kubernetes集群环境中使用lxcfs,我们将给大家一个示例方法供参考。

首先我们要在集群节点上安装并启动lxcfs,我们将用Kubernetes的方式,用利用容器和DaemonSet方式来运行 lxcfs FUSE文件系统。

本文所有示例代码可以通过以下地址从Github上获得

git clone https://github.com/denverdino/lxcfs-initializer
cd lxcfs-initializer

其manifest文件如下

apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
  name: lxcfs
  labels:
    app: lxcfs
spec:
  selector:
    matchLabels:
      app: lxcfs
  template:
    metadata:
      labels:
        app: lxcfs
    spec:
      hostPID: true
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: lxcfs
        image: registry.cn-hangzhou.aliyuncs.com/denverdino/lxcfs:2.0.8
        imagePullPolicy: Always
        securityContext:
          privileged: true
        volumeMounts:
        - name: rootfs
          mountPath: /host
      volumes:
      - name: rootfs
        hostPath:
          path: /

注: 由于 lxcfs FUSE需要共享系统的PID名空间以及需要特权模式,所有我们配置了相应的容器启动参数。

可以通过如下命令在所有集群节点上自动安装、部署完成 lxcfs,是不是很简单?:-)

kubectl create -f lxcfs-daemonset.yaml

那么如何在Kubernetes中使用 lxcfs 呢?和上文一样,我们可以在Pod的定义中添加对 /proc 下面文件的 volume(文件卷)和对 volumeMounts(文件卷挂载)定义。然而这就让K8S的应用部署文件变得比较复杂,有没有办法让系统自动完成相应文件的挂载呢?

Kubernetes提供了 Initializer 扩展机制,可以用于对资源创建进行拦截和注入处理,我们可以借助它优雅地完成对lxcfs文件的自动化挂载。

注: 阿里云Kubernetes集群,已经默认开启了对 Initializer 的支持,如果是在自建集群上进行测试请参见文档开启相应功能

其 manifest 文件如下

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: lxcfs-initializer-default
  namespace: default
rules:
- apiGroups: ["*"]
  resources: ["deployments"]
  verbs: ["initialize", "patch", "watch", "list"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: lxcfs-initializer-service-account
  namespace: default
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: lxcfs-initializer-role-binding
subjects:
- kind: ServiceAccount
  name: lxcfs-initializer-service-account
  namespace: default
roleRef:
  kind: ClusterRole
  name: lxcfs-initializer-default
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  initializers:
    pending: []
  labels:
    app: lxcfs-initializer
  name: lxcfs-initializer
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: lxcfs-initializer
      name: lxcfs-initializer
    spec:
      serviceAccountName: lxcfs-initializer-service-account
      containers:
        - name: lxcfs-initializer
          image: registry.cn-hangzhou.aliyuncs.com/denverdino/lxcfs-initializer:0.0.2
          imagePullPolicy: Always
          args:
            - "-annotation=initializer.kubernetes.io/lxcfs"
            - "-require-annotation=true"
---
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: InitializerConfiguration
metadata:
  name: lxcfs.initializer
initializers:
  - name: lxcfs.initializer.kubernetes.io
    rules:
      - apiGroups:
          - "*"
        apiVersions:
          - "*"
        resources:
          - deployments

注: 这是一个典型的 Initializer 部署描述,首先我们创建了service account lxcfs-initializer-service-account,并对其授权了 “deployments” 资源的查找、更改等权限。然后我们部署了一个名为 “lxcfs-initializer” 的Initializer,利用上述SA启动一个容器来处理对 “deployments” 资源的创建,如果deployment中包含 initializer.kubernetes.io/lxcfs为true的注释,就会对该应用中容器进行文件挂载

我们可以执行如下命令,部署完成之后就可以愉快地玩耍了

kubectl apply -f lxcfs-initializer.yaml

下面我们部署一个简单的Apache应用,为其分配256MB内存,并且声明了如下注释 “initializer.kubernetes.io/lxcfs”: “true”

其manifest文件如下

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  annotations:
    "initializer.kubernetes.io/lxcfs": "true"
  labels:
    app: web
  name: web
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: web
      name: web
    spec:
      containers:
        - name: web
          image: httpd:2
          imagePullPolicy: Always
          resources:
            requests:
              memory: "256Mi"
              cpu: "500m"
            limits:
              memory: "256Mi"
              cpu: "500m"

我们可以用如下方式进行部署和测试

$ kubectl create -f web.yaml 
deployment "web" created

$ kubectl get pod
NAME                                 READY     STATUS    RESTARTS   AGE
web-7f6bc6797c-rb9sk                 1/1       Running   0          32s
$ kubectl exec web-7f6bc6797c-rb9sk free
             total       used       free     shared    buffers     cached
Mem:        262144       2876     259268       2292          0        304
-/+ buffers/cache:       2572     259572
Swap:            0          0          0

我们可以看到 free 命令返回的 total memory 就是我们设置的容器资源容量。

我们可以检查上述Pod的配置,果然相关的 procfs 文件都已经挂载正确

$ kubectl describe pod web-7f6bc6797c-rb9sk
...
    Mounts:
      /proc/cpuinfo from lxcfs-proc-cpuinfo (rw)
      /proc/diskstats from lxcfs-proc-diskstats (rw)
      /proc/meminfo from lxcfs-proc-meminfo (rw)
      /proc/stat from lxcfs-proc-stat (rw)
...

在Kubernetes中,还可以通过 Preset 实现类似的功能,篇幅有限。本文不再赘述了。

总结

本文介绍了通过 lxcfs 提供容器资源可见性的方法,可以帮助一些遗留系统更好的识别容器运行时的资源限制。

同时,在本文中我们介绍了利用容器和DaemonSet的方式部署lxcfs FUSE,这不但极大简化了部署。也可以方便地利用Kubernetes自身的容器管理能力,支持lxcfs进程失效时自动恢复,在集群伸缩时也可以保证节点部署的一致性。这个技巧对于其他类似的监控或者系统扩展都是适用的。

另外我们介绍了利用Kubernetes的扩展机制 Initializer,实现对 lxcfs 文件的自动化挂载。整个过程对于应用部署人员是透明的,可以极大简化运维复杂度。同时利用类似的方法,我们可以灵活地定制应用部署的行为,满足业务的特殊要求。

阿里云Kubernetes服务 全球首批通过Kubernetes一致性认证,简化了Kubernetes集群生命周期管理,内置了与阿里云产品集成,也将进一步简化Kubernetes的开发者体验,帮助用户关注云端应用价值创新。

Kubernetes之路 1 – Java应用资源限制的迷思

未分类

随着容器技术的成熟,越来越多的企业客户在企业中选择Docker和Kubernetes作为应用平台的基础。然而在实践过程中,还会遇到很多具体问题。本系列文章会记录阿里云容器服务团队在支持客户中的一些心得体会和最佳实践。我们也欢迎您通过邮件和钉钉群和我们联系,分享您的思路和遇到的问题。

在对Java应用容器化部署的过程中,有些同学反映:自己设置了容器的资源限制,但是Java应用容器在运行中还是会莫名奇妙地被OOM Killer干掉。

这背后一个非常常见的原因是:没有正确设置容器的资源限制以及对应的JVM的堆空间大小。

我们拿一个tomcat应用为例,其实例代码和Kubernetes部署文件可以从Github中获得。

git clone https://github.com/denverdino/system-info
cd system-info`

下面是一个Kubernetes的Pod的定义描述:

  • Pod中的app是一个初始化容器,负责把一个JSP应用拷贝到 tomcat 容器的 “webapps”目录下。注: 镜像中JSP应用index.jsp用于显示JVM和系统资源信息。
  • tomcat 容器会保持运行,而且我们限制了容器最大的内存用量为256MB内存。
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  initContainers:
  - image: registry.cn-hangzhou.aliyuncs.com/denverdino/system-info
    name: app
    imagePullPolicy: IfNotPresent
    command:
      - "cp"
      - "-r"
      - "/system-info"
      - "/app"
    volumeMounts:
    - mountPath: /app
      name: app-volume
  containers:
  - image: tomcat:9-jre8
    name: tomcat
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - mountPath: /usr/local/tomcat/webapps
      name: app-volume
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: "500m"
  volumes:
  - name: app-volume
    emptyDir: {}

我们执行如下命令来部署、测试应用

$ kubectl create -f test.yaml
pod "test" created
$ kubectl get pods test
NAME      READY     STATUS    RESTARTS   AGE
test      1/1       Running   0          28s
$ kubectl exec test curl http://localhost:8080/system-info/
...

我们可以看到HTML格式的系统CPU/Memory等信息,我们也可以用 html2text 命令将其转化成为文本格式。

注意:本文是在一个 2C 4G的节点上进行的测试,在不同环境中测试输出的结果会有所不同

$ kubectl exec test curl http://localhost:8080/system-info/ | html2text

Java version     Oracle Corporation 1.8.0_162
Operating system Linux 4.9.64
Server           Apache Tomcat/9.0.6
Memory           Used 29 of 57 MB, Max 878 MB
Physica Memory   3951 MB
CPU Cores        2
                                          **** Memory MXBean ****
Heap Memory Usage     init = 65011712(63488K) used = 19873704(19407K) committed
                      = 65536000(64000K) max = 921174016(899584K)
Non-Heap Memory Usage init = 2555904(2496K) used = 32944912(32172K) committed =
                      33882112(33088K) max = -1(-1K)

我们可以发现,容器中看到的系统内存是 3951MB,而JVM Heap Size最大是 878MB。纳尼?!我们不是设置容器资源的容量为256MB了吗?如果这样,当应用内存的用量超出了256MB,JVM还没对其进行GC,而JVM进程就会被系统直接OOM干掉了。

问题的根源在于:

  • 对于JVM而言,如果没有设置Heap Size,就会按照宿主机环境的内存大小缺省设置自己的最大堆大小。
  • Docker容器利用CGroup对进程使用的资源进行限制,而在容器中的JVM依然会利用宿主机环境的内存大小和CPU核数进行缺省设置,这导致了JVM Heap的错误计算。

类似,JVM缺省的GC、JIT编译线程数量取决于宿主机CPU核数。如果我们在一个节点上运行多个Java应用,即使我们设置了CPU的限制,应用之间依然有可能因为GC线程抢占切换,导致应用性能收到影响。

了解了问题的根源,我们就可以非常简单地解决问题了

解决思路

开启CGroup资源感知

Java社区也关注到这个问题,并在JavaSE8u131+和JDK9 支持了对容器资源限制的自动感知能力 https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits

其用法就是添加如下参数

java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap …

我们在上文示例的tomcat容器添加环境变量 “JAVA_OPTS”参数

apiVersion: v1
kind: Pod
metadata:
  name: cgrouptest
spec:
  initContainers:
  - image: registry.cn-hangzhou.aliyuncs.com/denverdino/system-info
    name: app
    imagePullPolicy: IfNotPresent
    command:
      - "cp"
      - "-r"
      - "/system-info"
      - "/app"
    volumeMounts:
    - mountPath: /app
      name: app-volume
  containers:
  - image: tomcat:9-jre8
    name: tomcat
    imagePullPolicy: IfNotPresent
    env:
    - name: JAVA_OPTS
      value: "-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap"
    volumeMounts:
    - mountPath: /usr/local/tomcat/webapps
      name: app-volume
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: "500m"
  volumes:
  - name: app-volume
    emptyDir: {}

我们部署一个新的Pod,并重复相应的测试

$ kubectl create -f cgroup_test.yaml
pod "cgrouptest" created

$ kubectl exec cgrouptest curl http://localhost:8080/system-info/ | html2txt
Java version     Oracle Corporation 1.8.0_162
Operating system Linux 4.9.64
Server           Apache Tomcat/9.0.6
Memory           Used 23 of 44 MB, Max 112 MB
Physica Memory   3951 MB
CPU Cores        2
                                          **** Memory MXBean ****
Heap Memory Usage     init = 8388608(8192K) used = 25280928(24688K) committed =
                      46661632(45568K) max = 117440512(114688K)
Non-Heap Memory Usage init = 2555904(2496K) used = 31970840(31221K) committed =
                      32768000(32000K) max = -1(-1K)

我们看到JVM最大的Heap大小变成了112MB,这很不错,这样就能保证我们的应用不会轻易被OOM了。随后问题又来了,为什么我们设置了容器最大内存限制是256MB,而JVM只给Heap设置了112MB的最大值呢?

这就涉及到JVM的内存管理的细节了,JVM中的内存消耗包含Heap和Non-Heap两类;类似Class的元信息,JIT编译过的代码,线程堆栈(thread stack),GC需要的内存空间等都属于Non-Heap内存,所以JVM还会根据CGroup的资源限制预留出部分内存给Non Heap,来保障系统的稳定。(在上面的示例中我们可以看到,tomcat启动后Non Heap占用了近32MB的内存)

在最新的JDK 10中,又对JVM在容器中运行做了进一步的优化和增强。

容器内部感知CGroup资源限制

如果无法利用JDK 8/9的新特性,比如还在使用JDK6的老应用,我们还可以在容器内部利用脚本来获取容器的CGroup资源限制,并通过设置JVM的Heap大小。

Docker1.7开始将容器cgroup信息挂载到容器中,所以应用可以从 /sys/fs/cgroup/memory/memory.limit_in_bytes 等文件获取内存、 CPU等设置,在容器的应用启动命令中根据Cgroup配置正确的资源设置 -Xmx, -XX:ParallelGCThreads等参数

在 https://yq.aliyun.com/articles/18037 一文中已经有相应的示例和代码,本文不再赘述

总结

本文分析了Java应用在容器使用中一个常见Heap设置的问题。容器与虚拟机不同,其资源限制通过CGroup来实现。而容器内部进程如果不感知CGroup的限制,就进行内存、CPU分配可能导致资源冲突和问题。

我们可以非常简单地利用JVM的新特性和自定义脚本来正确设置资源限制。这个可以解决绝大多数资源限制的问题。

关于容器应用中资源限制还有一类问题是,一些比较老的监控工具或者free/top等系统命令,在容器中运行时依然会获取到宿主机的CPU和内存,这导致了一些监控工具在容器中运行时无法正常计算资源消耗。社区中常见的做法是利用 lxcfs 来让容器在资源可见性的行为和虚机保持一致,后续文章会介绍其在Kubernetes上的使用方案。

阿里云Kubernetes服务 全球首批通过Kubernetes一致性认证,简化了Kubernetes集群生命周期管理,内置了与阿里云产品集成,也将进一步简化Kubernetes的开发者体验,帮助用户关注云端应用价值创新。

实战Kubernetes动态卷存储(NFS)

之前的《 Kubernetes持久卷实战两部曲》系列中,我们实战了先声明一个存储卷,再使用这个存储卷,这种方式要求每次都要提前申明存储,不是很方便,而动态卷存储不需要提前申明,而是使用时自动申明,今天我们就来一起实战;

原文地址:https://blog.csdn.net/boling_cavalry/article/details/79598905

本章概要

今天的实战,我们要做下列操作:

  1. 准备好NFS服务;
  2. 创建namespace;
  3. 创建NFS服务的provisioner;
  4. 创建存储类StorageClass,与刚刚创建的provisioner绑定;
  5. 创建应用Pod,此应用是个web服务,外部通过HTTP请求将二进制文件上传到服务端,存储在Pod的本地路径,而这个路径已经被挂载到NFS;
  6. 通过客户端上传文件,检查文件是否保存在NFS上;
  7. 将web应用的Pod数扩展到两个,检查动态卷存储是否自动扩展;

网络服务图

本次实战涉及到客户端、K8S、NFS等网络节点,如下图:

未分类

源码下载

您可以在GitHub下载web服务的源码,地址和链接信息如下表所示:

未分类

这个git项目中有多个目录,本次需要其中的三个,如下:

  1. 在K8S上创建Pod,service,StorageClass等资源的时候用到的各种yaml文件,存放在storageclass目录;
  2. 接收客户端上传文件的web应用,源码在k8spvdemo目录;
  3. 上传文件client工程,源码在uploadfileclient目录;

准备好NFS服务

参照 https://blog.csdn.net/boling_cavalry/article/details/79498346 搭建好NFS服务,服务器的IP地址是192.168.238.132,开放的目录/usr/local/work/nfs;

创建namespace

在能够执行kubectl的机器上执行命令kubectl create namespace bolingcavalry,即可创建本次实战要用到的namespace;

创建NFS服务的provisioner

创建provisioner对应的deployment-nfs.yaml脚本:

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-client-provisioner
  namespace: bolingcavalry
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      containers:
        - name: nfs-client-provisioner
          image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 192.168.238.132
            - name: NFS_PATH
              value: /usr/local/work/nfs
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.238.132
            path: /usr/local/work/nfs

在此文件所在目录下执行kubectl create -f deployment-nfs.yaml,即可创建NFS的provisioner的pod,创建成功后,在dashboard页面看到,如下图:

未分类

这里三处需要注意:

1、设置了NFS的共享目录后,记得执行以下命令使设置生效:

systemctl restart rpcbind.service && systemctl restart nfs.service

2、此处用到的镜像是”registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner”,这是我在阿里云的搜索到的,原本打算使用”quay.io/kubernetes_incubator/nfs-client-provisioner:v1”,但是在pull的时候报错:{“error”: “Permission Denied”},在实战过程中用了阿里云的镜像可以正常工作,没有影响;
3、环境变量中有个PROVISIONER_NAME,值为fuseim.pri/ifs,后面的StorageClass就以“fuseim.pri/ifs”作为参数来定位到此Pod作为NFS服务的提供者;

创建存储类StorageClass

1、创建provisioner对应的nfs-class.yaml脚本:

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: fuseim.pri/ifs

2、在此文件所在目录下执行kubectl create -f nfs-class.yaml,即可创建存储类的资源,创建成功后,在dashboard页面看到,如下图:

未分类

创建web应用的Pod

存储已经准备好了,接下来制作一个web服务的应用来使用这个存储,该应用我已经做成镜像,可以直接使用;

1、创建web服务的部署脚本k8spvdemo.yaml:

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: k8spvdemo
  namespace:  bolingcavalry
spec:
  serviceName: "k8spvdemo"
  replicas: 1
  volumeClaimTemplates:
  - metadata:
      name: test 
      annotations:
        volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 2Gi 
  template:
    metadata:
     labels:
       name: k8spvdemo
    spec:
     containers:
     - name: k8spvdemo
       image: bolingcavalry/k8spvdemo:0.0.1-SNAPSHOT
       volumeMounts:
       - mountPath: "/usr/local/uploadfiles"
         name: test
       tty: true
       ports:
       - containerPort: 8080

2、在k8spvdemo.yaml文件所在目录执行命令kubectl create -f k8spvdemo.yaml,即可创建应用的Pod,如下图:

未分类

3、将应用Pod包裹成Service以便外部访问,创建服务配置文件k8spvdemo-svc.yaml:

apiVersion: v1
kind: Service
metadata:
  name: k8spvdemo
  namespace:  bolingcavalry
spec:
  type: NodePort
  ports:
       - port: 8080
         nodePort: 30010
  selector:
    name: k8spvdemo

4、在k8spvdemo.yaml文件所在目录执行命令kubectl create -f k8spvdemo-svc.yaml,即可创建服务,在dashboard页面看到服务如下图:

未分类

经历了以上四步,就把服务启动起来了,并且使用了NFS,小结出以下几个关键点需要注意:

  • 参数kind: StatefulSet表示使用了有状态资源,因为普通deployment是无法使用StorageClass资源的;
  • web工程中,收到客户端POST上来的文件后,保存在本地的/usr/local/uploadfiles目录,该目录在k8spvdemo.yaml的配置中通过volumeMounts参数挂在到StorageClass上;
  • 在k8spvdemo-svc.yaml的配置中做了端口映射,我的k8s节点机器的IP是192.168.238.130,那么通过192.168.238.130:30010就能访问到Pod服务;
  • 将springboot工程制作成镜像的方法请参考《maven构建docker镜像三部曲》系列文章;
  • 在NFS机器的/usr/local/work/nfs目录下,可以看到新创建的文件夹,如下图:

未分类

  • 在容器的事件中可以看到挂载信息,挂载的PV名称与NFS上创建的文件夹是可以对应起来的,如下图红框3所示:

未分类

服务已经准备好了,接下来试试上传文件,看应用能否正常使用动态卷存储;

运行客户端,上传本地文件到Tomcat

1、创建一个maven工程,pom.xml如下:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.bolingcavalry</groupId>
    <artifactId>uploadfileclient</artifactId>
    <version>1.0-SNAPSHOT</version>

    <!-- 指明编译源代码时使用的字符编码,maven编译的时候默认使用的GBK编码, 通过project.build.sourceEncoding属性设置字符编码,告诉maven这个项目使用UTF-8来编译 -->
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpclient</artifactId>
            <version>4.3.5</version>
        </dependency>

        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpmime</artifactId>
            <version>4.3.5</version>
        </dependency>
    </dependencies>

</project>
  1. 工程中创建一个java类,源码如下:
package com.bolingcavalry;

import org.apache.http.HttpEntity;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.config.RequestConfig;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.ContentType;
import org.apache.http.entity.mime.MultipartEntityBuilder;
import org.apache.http.entity.mime.content.FileBody;
import org.apache.http.entity.mime.content.StringBody;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.util.EntityUtils;

import java.io.File;
import java.io.IOException;

/**
 * @Description : 上传文件的类,将本地文件POST到server
 * @Author : [email protected]
 * @Date : 2018-02-24 18:12
 */
public class UploadFileClient {

    /**
     * 文件服务的ULR
     */
    private static final String POST_URL = "http://192.168.238.130:30010//upload";

    /**
     * 要上传的本地文件的完整路径加文件名
     */
    private static final String UPLOAD_FILE_FULLPATH = "D:\temp\201802\21\abc.zip";

    public static void main(String[] args) throws Exception{
        System.out.println("start upload");
        CloseableHttpClient httpclient = HttpClients.createDefault();
        try {
            HttpPost httppost = new HttpPost(POST_URL);

            //基本的配置信息
            RequestConfig requestConfig = RequestConfig.custom().setConnectTimeout(200000).setSocketTimeout(200000).build();

            httppost.setConfig(requestConfig);

            //要上传的文件
            FileBody bin = new FileBody(new File(UPLOAD_FILE_FULLPATH));

            //在POST中添加一个字符串请求参数
            StringBody comment = new StringBody("This is comment", ContentType.TEXT_PLAIN);

            HttpEntity reqEntity = MultipartEntityBuilder.create().addPart("file", bin).addPart("comment", comment).build();

            httppost.setEntity(reqEntity);

            System.out.println("executing request " + httppost.getRequestLine());

            //发起POST
            CloseableHttpResponse response = httpclient.execute(httppost);

            try {

                HttpEntity resEntity = response.getEntity();
                if (resEntity != null) {
                    String responseEntityStr = EntityUtils.toString(response.getEntity());
                    System.out.println("response status : " + response.getStatusLine());
                    System.out.println("response content length: " + resEntity.getContentLength());
                    System.out.println("response entity str : " + responseEntityStr);
                }
                EntityUtils.consume(resEntity);
            } finally {
                response.close();
            }
        } catch (ClientProtocolException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            try {
                httpclient.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

        System.out.println("end upload");
    }
}

以上源码中,有两处要注意:
第一,POST_URL = “http://192.168.238.130:30010//upload”中的192.168.238.130是Pod所在的节点机器的IP地址,请替换为您的k8s环境中的节点IP地址;
第二,UPLOAD_FILE_FULLPATH = “D:temp20180221abc.zip”,这里配置的是要上传的本地文件的路径,请替换为您要上传的文件路径;

3、直接运行UploadFileClient.java,看到控制台输出如下信息表示上传成功:

start upload
executing request POST http://192.168.238.130:30010/upload HTTP/1.1
response status : HTTP/1.1 200 
response content length: 40
response entity str : SpringBoot环境下,上传文件成功
end upload

Process finished with exit code 0

上传成功了,在dashboard上查看容器的日志,能看到上传有关的日志如下图红框所示:

未分类

现在理论上现在文件已经保存在NFS Server的/usr/local/work/nfs目录下了,去检查一下;

去NFS Server检查上传的文件

登录NFS Server,进入/usr/local/work/nfs,查看文件信息如下图:

未分类

可见k8s上的tomcat应用可以通过动态卷存储的方式将客户端上传的文件保存在NFS服务器上;

扩展web应用的Pod数量

目前web应用的Pod数量是1,执行以下命令扩展到两个:

kubectl scale StatefulSet k8spvdemo --replicas=2 --namespace=bolingcavalry

执行完毕后,在dashboard可以看见创建的动态卷,如下图:

未分类

您可以再次上传文件,然后去NFS服务器检查是否已经创建了新的文件夹,并且存放了新的上传文件;

至此,Kubernetes动态卷存储的实战就全部完成了,希望PV&&PVC和动态存储两种方案可以帮助您在应用中解决独立存储的问题;

kubernetes 的资源配额控制器

有很多团队在使用kubernetes的时候是将一个namespace当成一个租户的,所以对namespace的权限控制,资源控制就很重要了,你总是会担心你的某个租户使用的资源就超出了应有的配额。幸运的是kubernetes本身就为我们提供了解决这一问题的工具:资源配额控制器(ResourceQuotaController)

资源配额控制器确保了指定的资源对象始终不会超过配置的资源,能够有效的降低整个系统宕机的机率,增强系统的鲁棒性,对整个集群的稳定性有非常重要的作用。

介绍

kubernetes主要有3个层级的资源配额控制:

  • 容器:可以对 CPU 和 Memory 进行限制
  • POD:可以对一个 POD 内所有容器的的资源进行限制
  • Namespace:为一个命名空间下的资源进行限制

其中容器层次主要利用容器本身的支持,比如 Docker 对 CPU、内存等的支持;POD 方面可以限制系统内创建 POD 的资源范围,比如最大或者最小的 CPU、memory 需求;Namespace 层次就是对用户级别的资源限额了,包括 CPU、内存,还可以限定 POD、RC、Service 的数量。

要使用资源配额的话需要确保apiserver的–admission-control参数中包含ResourceQuota,当 namespace 中存在一个 ResourceQuota对象时,该 namespace 即开始实施资源配额的管理工作了,另外需要注意的是一个 namespace 中最多只应存在一个 ResourceQuota 对象。

ResourceQuotaController支持的配额控制资源主要包括:计算资源配额、存储资源配额、对象数量资源配额以及配额作用域,下面我们来分别看看这些资源的具体信息:

计算资源配额

用户可以对给定 namespace 下的计算资源总量进行限制,ResourceQuotaController所支持的资源类型如下:

未分类

示例如下:

$ cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: myspace
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
EOF
$ kubectl create -f compute-resources.yaml

然后我们查看下上面我们创建的 ResourceQuota对象:

$ kubectl describe quota compute-resources -n myspace
Name:            compute-resources
Namespace:       myspace
Resource         Used  Hard
--------         ----  ----
limits.cpu       0     2
limits.memory    0     2Gi
requests.cpu     0     1
requests.memory  0     1Gi

另外需要注意的是:如果 namespace 下的计算资源 (如 cpu 和 memory)的配额被启用,则用户必须为这些资源设定请求值(request) 和约束值(limit),否则配额系统将拒绝Pod的创建;或者也可以为资源设置默认的资源限制,如下 yaml 文件:(同样需要在–admission-control参数中设置值LimitRanger)

apiVersion: v1
kind: LimitRange
metadata:
  name: limits
spec:
  limits:
  - default:
    cpu: 200m
    memory: 200Mi
  type: Container

存储资源配额

用户可以对给定 namespace 下的存储资源总量进行限制,此外,还可以根据相关的存储类(Storage Class)来限制存储资源的消耗。

未分类

对象数量配额

给定类型的对象数量可以被限制。 支持以下类型:

未分类

如下示例:

$ cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: myspace
spec:
  hard:
    pods: "40"
    configmaps: "10"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.nodeports: "2"
EOF
$ kubectl create -f object-counts.yaml

同样可以查看上面创建的资源限额对象:

$ kubectl describe quota object-counts -n myspace
Name:                   object-counts
Namespace:              myspace
Resource                Used  Hard
--------                ----  ----
configmaps              0     10
pods                    0     40
replicationcontrollers  0     20
secrets                 1     10
services                0     10
services.nodeports      0     2

配额作用域

每个配额都有一组相关的作用域(scope),配额只会对作用域内的资源生效。当一个作用域被添加到配额中后,它会对作用域相关的资源数量作限制。 如配额中指定了允许(作用域)集合之外的资源,会导致验证错误。

未分类

其中BestEffort 作用域限制配额跟踪以下资源: PODS

Terminating、 NotTerminating 和 NotBestEffort限制配额跟踪以下资源:cpu、limits.cpu、limits.memory、memory、pods、requests.cpu、requests.memory。

总结

物理资源 CPU 和内存受到 namespace 资源配额管理器的控制,几乎所有使用到的资源都能够被简单的调整,我们可以结合我们自身的业务和物理资源实际情况来进行分配配额,所以这里没有一个完全通用的配额方案,需要根据实际情况来定,因为只有你自己最清楚你的集群的整体情况了。

Kubernetes性能测试实践

概述

随着容器技术的发展,容器服务已经成为行业主流,然而想要在生产环境中成功部署和操作容器,关键还是容器编排技术。市场上有各种各样的容器编排工具,如Docker原生的Swarm、Mesos、Kubernetes等,其中Google开发的Kubernetes因为业界各大巨头的加入和开源社区的全力支撑,成为了容器编排的首选。

简单来讲,Kubernetes是容器集群管理系统,为容器化的应用提供资源调度、部署运行、滚动升级、扩容缩容等功能。容器集群管理给业务带来了便利,但是随着业务的不断增长,应用数量可能会发生爆发式的增长。那在这种情况下,Kubernetes能否快速地完成扩容、扩容到大规模时Kubernetes管理能力是否稳定成了挑战。

因此,结合近期对社区Kubernetes性能测试的调研和我们平时进行的kubernetes性能测试实践,和大家探讨下Kubernetes性能测试的一些要点,不足之处还望大家多多指正!

测试目的

未分类

如上Kubernetes架构图所示,无论外部客户端,还是Kubernetes集群内部组件,其通信都需要经过Kubernetes的apiserver,API的响应性决定着集群性能的好坏。

其次,对于外部客户而言,他只关注创建容器服务所用的时间,因此,pod的启动时间也是影响集群性能的另外一个因素。

目前,业内普遍采用的性能标准是:

  • API响应性:99%的API调用响应时间小于1s。
  • Pod启动时间:99%的pods(已经拉取好镜像)启动时间在5s以内。

“pod启动时间”包括了ReplicationController的创建,RC依次创建pod,调度器调度pod,Kubernetes为pod设置网络,启动容器,等待容器成功响应健康检查,并最终等待容器将其状态上报回API服务器,最后API服务器将pod的状态报告给正在监听中的客户端。

除此之外,网络吞吐量、镜像大小(需要拉取)都会影响Kubernetes的整体性能。

测试要点

1、社区测试Kubernetes性能的关键点

  • 当集群资源使用率是X%(50%、90% 、99%等不同规模下)的时候,创建新的pod所需的时间(这种场景需要提前铺底,然后在铺底基础上用不同的并发梯度创建pod,测试pod创建耗时,评估集群性能)。在测试kubernetes新版本时,一般是以老版本稳定水位(node、pod等)铺底,然后梯度增加进行测试。
  • 当集群使用率高于90%时,容器启动时延的增大(系统会经历一个异常的减速)还有etcd测试的线性性质和“模型建立”的因素。调优方法是:调研etcd新版本是否有解决该问题。
  • 测试的过程中要找出集群的一个最高点,低于和高于这个阈值点,集群性能都不是最优的。
  • 组件负载会消耗master节点的资源,资源消耗所产生的不稳定性和性能问题,会导致集群不可用。所以,在测试过程中要时刻关注资源情况。
  • 客户端创建资源对象的格式 —— API服务对编码和解码JSON对象也需要花费大量的时间 —— 这也可以作为一个优化点。

2、网易云容器服务Kubernetes集群性能测试关键点总结

集群整体

  • 不同的集群使用水位线(0%,50%, 90%)上,pod/deployment(rs 等资源)创建、扩缩容等核心操作的性能。可以通过预先创建出一批dp(副本数默认设置为3)来填充集群,达到预期的水位,即铺底。
  • 不同水位对系统性能的影响——安全水位,极限水位
  • 容器有无挂载数据盘对容器创建性能的影响。例如,挂载数据盘增加了kubelet挂载磁盘的耗时,会增加pod的启动时长。

测试kubernetes集群的性能时,重点关注在不同水位、不同并发数下,长时间执行压力测试时,系统的稳定性,包括:

  • 系统性能表现,在较长时间范围内的变化趋势
  • 系统资源使用情况,在较长时间范围内的变化趋势
  • 各个服务组件的TPS、响应时间、错误率
  • 内部模块间访问次数、耗时、错误率等内部性能数据
  • 各个模块资源使用情况
  • 各个服务端组件长时间运行时,是否出现进程意外退出、重启等情况
  • 服务端日志是否有未知错误
  • 系统日志是否报错

apiserver

  1. 关注api的响应时间。数据写到etcd即可,然后根据情况关注异步操作是否真正执行完成。
  2. 关注apiserver缓存的存储设备对性能的影响。例如,master端节点的磁盘io。
  3. 流控对系统、系统性能的影响。
  4. apiserver 日志中的错误响应码。
  5. apiserver 重启恢复的时间。需要考虑该时间用户是否可接受,重启后请求或者资源使用是否有异常。
  6. 关注apiserver在压力测试情况下,响应时间和资源使用情况。

scheduler

1、压测scheduler处理能力

  • 并发创建大量pod,测试各个pod被调度器调度的耗时(从Pod创建到其被bind到host)
  • 不断加大新建的pod数量来增加调度器的负载
  • 关注不同pod数量级下,调度器的平均耗时、最大时间、最大QPS(吞吐量)

2、scheduler 重启恢复的时间(从重启开始到重启后系统恢复稳定)。需要考虑该时间用户是否可接受,重启后请求或者资源使用是否有异常。

3、关注scheduler日志中的错误信息。

controller

1、压测 deployment controller处理能力

  • 并发创建大量rc(1.3 以后是deployment,单副本),测试各个deployment被空感知并创建对应rs的耗时
  • 观察rs controller创建对应pod的耗时
  • 扩容、缩容(缩容到0副本)的耗时
  • 不断加大新建deployment的数,测试在不同deployment数量级下,控制器处理deployment的平均耗时、最大时间、最大QPS(吞吐量)和控制器负载等情况

2、controller 重启恢复的时间(从重启开始到重启后系统恢复稳定)。需要考虑该时间用户是否可接受,重启后请求或者资源使用是否有异常。

3、关注controller日志中的错误信息。

kubelet

  • node心跳对系统性能的影响。
  • kubelet重启恢复的时间(从重启开始到重启后系统恢复稳定)。需要考虑该时间用户是否可接受,重启后请求或者资源使用是否有异常。
  • 关注kubelet日志中的错误信息。

etcd

1、关注etcd 的写入性能

  • 写最大并发数
  • 写入性能瓶颈,这个主要是定期持久化snapshot操作的性能

2、etcd 的存储设备对性能的影响。例如,写etcd的io。

3、watcher hub 数对kubernetes系统性能的影响。

aspnetcore.webapi实践k8s健康探测机制 – kubernetes

1、浅析k8s两种健康检查机制

  • Liveness
    k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可能是资源死锁,此时 httpd 进程并没有异常退出,在这种情况下重启容器可能是最直接最有效的解决方案。

  • Readiness
    k8s通过readiness来探测微服务的什么时候准备就绪(例如初始化时,连接数据库,加载缓存数据等等,可能需要一段时间),然后将容器加入到server的负载均衡池中,对外提供服务。

1.1、k8s默认的健康检查机制

  每个容器启动时都会执行一个进程,此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出时返回码非零,则认为容器发生故障,Kubernetes 就会根据 restartPolicy 重启容器。如果不特意配置,Kubernetes 将对两种探测采取相同的默认行为。

2、通过微服务自定义两种机制

存活10分钟:如果当前时间超过服务启动时间10分钟,则探测失败,否则探测成功。Kubernetes 如果连续执行 3 次 Liveness 探测均失败,就会杀掉并重启容器。

未分类

准备就绪30秒,30秒后,如果连续 3 次 Readiness 探测均失败后,容器将被重置为不可用,不接收 Service 转发的请求。

未分类

从上面可以看到,我们可以根据自身的需求来实现这两种机制,然后,提供给k8s进行探测。

3、编写k8s资源配置文件(yml)

k8s默认是根据命令进行探测的,由于我们需要与微服务结合,所以需要在yml文件中指定为http方式,k8s对于http方式探测成功的判断条件是请求的返回代码在 200-400 之间。

health-checks-deployment.yml 如下:

未分类

从上面可以看到,一共部署了3个pod副本,而每个pod副本里面部署一个容器,即为同一个微服务部署了3个实例进行集群。

4、在k8s集群的master机器上,创建部署对象

未分类

从上面可以看到,刚开始创建时,READY 状态为不可用,等待一段时间

未分类

现在全部可用了

5、通过dashboard查看集群概况

未分类

6、剖析k8s集群自愈(self-healing)过程

未分类

未分类

未分类

从上面可以看到,大约1分钟(dashboard统计信息有一定的延迟)左右,第一次进行 Readiness 探测并成功返回,此时准备就绪,可以对外提供服务了。在10分钟内,探测Liveness也成功返回。

继续等待一段时间,查询其中一个pod详细信息:

未分类

未分类

从上面可以看到,超过10分钟存活期后,liveness探测失败,容器被 killed and recreated。探测Readiness未成功返回时,整个容器处于不健康的状态,并不会被负载均衡请求。

此时通过dashboard查看集群概况:

未分类

继续等待一段时间:

未分类

现在,整个集群已经自愈完成了!!!

7、总结

Liveness 探测和 Readiness 探测是独立执行的,二者之间没有依赖,可以单独使用,也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈;用 Readiness 探测判断容器是否已经准备好对外提供服务。

源码参考:https://github.com/justmine66/k8s.ecoysystem.apps

在kubernetes集群中创建redis主从多实例

继续使用上次实验环境 https://www.58jb.com/html/180.html ,因为环境中已经配置好flannel网络了,接下要就是慢慢在此环境中创建一些实例。因为只是搭建简单的环境是比较容易上手,随便网上一搜可能就出来了。但是要自己去从头一步一步跑起项目,还是基于真实的项目来跑的话还是需要自己多研究,当然目前还是止于使用阶段,要深入还得多看资料。

未分类

本次要记录的是自己从创建镜像到实现redis主从示例,为什么要自己制作镜像呢?其实就是为了自己可以学多点,毕竟网上的都人别人做好的,你自己没做过根本不知道制作过程中会遇到什么。为什么有些镜像大,有些镜像比较小。这都是在哪里做的优化?
本次直接使用alpine基础镜像,因为它小,加上个redis也就11M左右的镜像,如果使用centos可能就大点了,这里先不做存储的方便,只是简单的实现redis-master和redis-slave之间的自动发现。
为了自己好区分我直接制作两个镜像,一个为redis-master专门用来跑master服务的,一个为redis-slave专门跑slave实例的。其实可以只用一个,只需分两个配置文件或者是两个不同的启动方法,这里不做这个介绍。

redis-slave镜像制作

需要二个文件:Dockerfile、run.sh

Dockerfile内容如下:

FROM alpine:3.4  
RUN apk add --no-cache redis sed bash  
COPY run.sh /run.sh  
CMD [ "/run.sh" ]  
ENTRYPOINT [ "bash" ]  

其实默认可以不使用redis.conf文件的,如果需要就在上面的Dockerfile文件也加入,这里目前也处于测试,先不加配置。

run.sh启动脚本,也就是一行文件。

[root@k8s-node1 slave]# cat run.sh 
#/bin/sh 
redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} ${REDIS_MASTER_SERVICE_PORT} 

打包成镜像传到内网仓库:

docker build -t redis-slave . 
docker tag redis-slave reg.docker.tb/harbor/redis-slave 
docker push reg.docker.tb/harbor/redis-slave 

redis-master镜像制作

跟上面的配置差不多一样,只是启动时的命令有点不而已。
Dockerfile内容如下:

FROM alpine:3.4  
RUN apk add --no-cache redis sed bash  
COPY run.sh /run.sh  
CMD [ "/run.sh" ]  
ENTRYPOINT [ "bash" ]  

其实默认可以不使用redis.conf文件的,如果需要就在上面的Dockerfile文件也加入,这里目前也处于测试,先不加配置。

run.sh启动脚本,也就是一行文件。

[root@k8s-node1 master]# cat run.sh 
#/bin/sh 
redis-server

打包成镜像传到内网仓库:

docker build -t redis-master . 
docker tag redis-master reg.docker.tb/harbor/redis-master 
docker push reg.docker.tb/harbor/redis-master 

创建kube的配置文件yaml

创建一个master-service.yaml 来统一Master的入口,同时会自动关联到labels为redis-master的所有Pod,这里要注意Service要优于pod启动,不然无法通过环境变量把配置信息写入到pod中。

apiVersion: v1 
kind: Service 
metadata: 
  name: redis-master 
  labels: 
    name: redis-master 
spec: 
  ports: 
  - port: 6379 
    targetPort: 6379 
  selector: 
    name: redis-master 

redis-master.yaml 以rc的方式来创建一个master容器,它会保证容器的副本数量。

apiVersion: v1 
kind: ReplicationController 
metadata: 
  name: redis-master 
  labels: 
    name: redis-master 
spec: 
  replicas: 1 
  selector: 
    name: redis-master 
  template: 
    metadata: 
      labels: 
        name: redis-master 
    spec: 
      containers: 
      - name: master 
        image: reg.docker.tb/harbor/redis-master 
        ports: 
        - containerPort: 6379 

redis-slave-service.yaml跟上面的Service一样,都是管理redis-slave所有容器的,此服务创建后会把所有的slave实例的容器分配一个集群IP.

apiVersion: v1 
kind: Service 
metadata: 
  name: redis-slave 
  labels: 
    name: redis-slave 
spec: 
  ports: 
  - port: 6379 
  selector: 
    name: redis-slave 

redis-slave.yaml 同样是以RC的方式来创建redis-slave实例,这里的数量为两个。需要注意的是Image这里指定是刚才打包的镜像名。

apiVersion: v1 
kind: ReplicationController 
metadata: 
  name: redis-slave 
  labels: 
    name: redis-slave 
spec: 
  replicas: 2 
  selector: 
    name: redis-slave 
  template: 
    metadata: 
      labels: 
        name: redis-slave 
    spec: 
      containers: 
      - name: worker 
        image: reg.docker.tb/harbor/redis-slave 
        env: 
        - name: GET_HOSTS_FROM 
          value: env 
#value: dns
        ports: 
        - containerPort: 6379 

注意:要实现master和slave服务自动发现,需要配置它们之间的对应关系。Kubernetes有两种方法就是环境变量ENV和DNS记录解析,因为我的实验环境没有使用这个DNS来解析,所以只能使用ENV环境变量。

上面的redis-slave.yaml 就是使用了env环境变量。

接下来创建实例吧:

master: 
kubectl create -f redis-service.yaml 
kubectl create -f redis-master.yaml 

slave: 
kubectl create -f redis-slave-service.yaml 
kubectl create -f redis-slave.yaml 

查看启动的效果:

[root@k8s-master redis-pod]# kubectl get all -o wide 
NAME                    READY     STATUS    RESTARTS   AGE       IP           NODE 
po/redis-master-qpzlh   1/1       Running   0          1h        172.21.2.2   k8s-node1 
po/redis-slave-2rwk5    1/1       Running   0          1h        172.21.2.3   k8s-node1 
po/redis-slave-6tf2f    1/1       Running   0          1h        172.21.8.3   k8s-node2 

NAME              DESIRED   CURRENT   READY     AGE       CONTAINERS   IMAGES                              SELECTOR 
rc/redis-master   1         1         1         1h        master       reg.docker.tb/harbor/redis-master   name=redis-master 
rc/redis-slave    2         2         2         1h        worker       reg.docker.tb/harbor/redis-slave    name=redis-slave 

NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE       SELECTOR 
svc/kubernetes     ClusterIP   10.254.0.1       <none>        443/TCP    3d        <none> 
svc/redis-master   ClusterIP   10.254.152.116   <none>        6379/TCP   1h        name=redis-master 
svc/redis-slave    ClusterIP   10.254.188.60    <none>        6379/TCP   1h        name=redis-slave 

简单的测试master和slave是否可以同步数据:
连接master容器,可以看到有两个Replication中有两个connected_slaves就是从实例,后面跟着的就是IP地址。

[root@k8s-master redis-pod]# kubectl exec -it redis-master-qpzlh -- /bin/bash 
bash-4.3# redis-cli                                                                                                                                          
127.0.0.1:6379> info 
# Server 
redis_version:3.2.11 
redis_git_sha1:535782f7 
redis_git_dirty:0 
redis_build_id:80ce8a1f388ac530 
redis_mode:standalone 
os:Linux 4.4.113-1.el7.elrepo.x86_64 x86_64 
arch_bits:64 
multiplexing_api:epoll 
gcc_version:5.3.0 
process_id:5 
run_id:6629f021c2e5bd972fff05c84566cc92c7e59be0 
tcp_port:6379 
uptime_in_seconds:7105 
uptime_in_days:0 

...... 
# Clients 
connected_clients:2 
client_longest_output_list:0 
client_biggest_input_buf:0 
blocked_clients:0 
...... 

# Replication 
role:master 
connected_slaves:2 
slave0:ip=172.21.2.3,port=6379,state=online,offset=5276,lag=1 
slave1:ip=172.21.8.0,port=6379,state=online,offset=5276,lag=1 
master_repl_offset:5276 
repl_backlog_active:1 
repl_backlog_size:1048576 
repl_backlog_first_byte_offset:2 
repl_backlog_histlen:5275 

连接一个slave容器查看信息,可以看到Replication中role:slave为从实例,master的IP和端口等信息。

[root@k8s-master ~]# kubectl exec -it redis-slave-2rwk5 -- /bin/bash 
bash-4.3# redis-cli                                                                                                                                          
127.0.0.1:6379> info 
# Server 
redis_version:3.2.11 
redis_git_sha1:535782f7 
redis_git_dirty:0 
redis_build_id:80ce8a1f388ac530 
redis_mode:standalone 
os:Linux 4.4.113-1.el7.elrepo.x86_64 x86_64 
arch_bits:64 
multiplexing_api:epoll 
gcc_version:5.3.0 
process_id:5 
run_id:d48c42ea0a83babda663837ed5a6f9ef5a3ff9bf 
tcp_port:6379 
uptime_in_seconds:3957 
uptime_in_days:0 

...... 
# Replication 
role:slave 
master_host:10.254.152.116 
master_port:6379 
master_link_status:up 
master_last_io_seconds_ago:7 
master_sync_in_progress:0 
slave_repl_offset:5542 
slave_priority:100 
slave_read_only:1 
connected_slaves:0 
master_repl_offset:0 
repl_backlog_active:0 
repl_backlog_size:1048576 
repl_backlog_first_byte_offset:0 
repl_backlog_histlen:0 

此时在Master上创建一个key, 在slave上立马就可以获取到了。

master: 
127.0.0.1:6379> set name swper 
OK 

slave: 
127.0.0.1:6379> get name 
"swper" 

slave上只读: 
127.0.0.1:6379> set test 1 
(error) READONLY You can't write against a read only slave. 

这样就实现了一主多从的效果了,集群的IP现在是外部无法访问的,kubernetes节点中可以相互连通。
其实原本是很简单的实验,我居然在传递参数的时候少了个$号导致一直获取不到。

kubernetes下的Nginx加Tomcat三部曲之三:实战扩容和升级

本章是《kubernetes下的Nginx加Tomcat三部曲系列》的终篇,今天咱们一起在kubernetes环境对下图中tomcat的数量进行调整,再修改tomcat中web工程的源码,并将现有的tomcat的pod全部替换成新代码构建的结果:

未分类

往期章节

  1. kubernetes下的Nginx加Tomcat三部曲之一: http://devops.webres.wang/2018/02/kubernetes%E4%B8%8B%E7%9A%84nginx%E5%8A%A0tomcat%E4%B8%89%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%B8%80%EF%BC%9A%E6%9E%81%E9%80%9F%E4%BD%93%E9%AA%8C/
  2. kubernetes下的Nginx加Tomcat三部曲之二: http://devops.webres.wang/2018/02/kubernetes%E4%B8%8B%E7%9A%84nginx%E5%8A%A0tomcat%E4%B8%89%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BA%8C%EF%BC%9A%E7%BB%86%E8%AF%B4%E5%BC%80%E5%8F%91/

列举步骤

  1. 在线扩容Tomcat;
  2. 验证扩容结果;
  3. 修改web工程源码;
  4. 构建web工程的新镜像;
  5. 让kubernetes的机器用上web工程的Docker镜像
  6. 在线更新Tomcat的pod的镜像;
  7. 验证更新结果;
  8. Nginx&Tomcat方式和SpringCloud方式扩容对比;

kubernetes环境基本情况

  1. 一个master,一个node;
  2. master的IP地址:192.168.119.148;
  3. node1的IP地址:192.168.119.153;

在线扩容Tomcat

  • 在装好kubectl工具的机器上执行kubectl get pods,查看当前pod情况:
root@master:~# kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
ng-59b887b8bc-jzcv5           1/1       Running   3          2d
tomcathost-7f68566795-8pl29   1/1       Running   3          2d
tomcathost-7f68566795-mvg5f   1/1       Running   3          2d
tomcathost-7f68566795-trscg   1/1       Running   3          2d

如上所示,目前是三个tomcat的pod;

  • 执行扩容命令kubectl scale deployment tomcathost –replicas=5,将tomcat的pod从3个增加到5个,如下:
root@master:~# kubectl scale deployment tomcathost --replicas=5
deployment "tomcathost" scaled
root@master:~# kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
ng-59b887b8bc-jzcv5           1/1       Running   3          2d
tomcathost-7f68566795-8kf76   1/1       Running   0          18s
tomcathost-7f68566795-8pl29   1/1       Running   3          2d
tomcathost-7f68566795-mvg5f   1/1       Running   3          2d
tomcathost-7f68566795-tp5xp   1/1       Running   0          18s
tomcathost-7f68566795-trscg   1/1       Running   3          2d

tomcat的pod已经增加到5个了,创建时间都只有18秒;

  • 去dashboard页面看以下tomcathost这个deployment的详情,可以看到tomcat数量已经上升到5个了,扩容成功:

未分类

点击上图红框1,再点击tomcathost这个服务,可以看到上图中的详情;
上图红框2中是5个tomcat的pod的容器IP地址;
点击上图红框3中的每个容器名,可以查看容器详情;
上图红框4显示了刚才的扩容事件;

验证扩容结果

nginx服务所在的node机器的IP地址是192.168.119.153,所以在浏览器上访问:http://192.168.119.153:30006/getserverinfo,反复刷新此页面,看到返回的IP地址在不断的更新,都是tomcat所在pod的IP地址,5个都会出现,如下图:

未分类

扩容实战就到这里,接下来我们修改web工程的源码,验证在线升级的能力;

修改web工程源码

tomcat上运行的web工程源码,可以GitHub下载,地址和链接信息如下表所示:

未分类

这个git项目中有多个目录,本次的web工程源码放在k8stomcatdemo,如下图红框所示:

未分类

  • 打开工程中的ServerInfo.java,web接口的源码如下:
@RequestMapping(value = "/getserverinfo", method = RequestMethod.GET)
    public String getUserInfoWithRequestParam(){
        return String.format("server : %s, time : %s", getIPAddr(), new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()));
    }
  • 修改返回的字符串内容,在前面加上”From new version,”:
@RequestMapping(value = "/getserverinfo", method = RequestMethod.GET)
    public String getUserInfoWithRequestParam(){
        return String.format("From new version, server : %s, time : %s", getIPAddr(), new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()));
    }

构建web工程的新镜像

修改pom.xml中的工程版本,从0.0.1-SNAPSHOT改为0.0.3,如下所示:

<groupId>com.bolingcavalry</groupId>
    <artifactId>k8stomcatdemo</artifactId>
    <version>0.0.3</version>
    <packaging>jar</packaging>
    <name>k8stomcatdemo</name>
  • 在pom.xml所在目录执行mvn clean package -DskipTests docker:build,会编译构建工程,并且在本地制作好镜像文件,如下:
root@maven:/usr/local/work/k8s/k8stomcatdemo# docker images
REPOSITORY                                              TAG                 IMAGE ID            CREATED             SIZE
bolingcavalry/k8stomcatdemo                             0.0.3               5f2d27eafd1b        17 seconds ago      658 MB
bolingcavalry/k8stomcatdemo                             latest              5f2d27eafd1b        17 seconds ago      658 MB

让kubernetes的机器用上web工程的Docker镜像

现在的镜像只存在于开发和构建web工程的电脑上,为了让kubernetes的node机器能用上这个镜像,可以用以下几种方式实现:

1、用docker push命令将本机镜像推送到hub.docker.com网站,这样其他机器都可以通过docker pull命令取得了,我就是用的这种方法,需要在hub.docker.com上注册,下图是正在push中:

未分类

2、用docker save命令导出镜像文件,再用docker load命令导入;
3、kubernetes所在机器安装java和maven环境,将工程在这里编译构建;
4、使用docker私有仓库,例如搭建局域网私有仓库或者阿里云私有仓库,参考 http://blog.csdn.net/boling_cavalry/article/details/78934391

在线更新Tomcat的pod的镜像

  • 在kubernetes上执行以下命令,即可升级镜像,当前的5个tomcat的pod会被销毁,然后用新的镜像创建pod:
kubectl set image deployment/tomcathost tomcathost=bolingcavalry/k8stomcatdemo:0.0.3
  • 控制台提示的信息如下:
root@maven:/usr/local/work/k8s/k8stomcatdemo# kubectl set image deployment/tomcathost tomcathost=bolingcavalry/k8stomcatdemo:0.0.3
deployment "tomcathost" image updated
  • 此刻反复执行kubectl get pod,会看到新容器创建,旧容器正在被销毁,如下:
root@maven:/usr/local/work/k8s/k8stomcatdemo# kubectl get pod
NAME                          READY     STATUS              RESTARTS   AGE
ng-59b887b8bc-jzcv5           1/1       Running             3          2d
tomcathost-6dfc87dc8b-9bkfv   1/1       Running             0          50s
tomcathost-6dfc87dc8b-h6gx4   0/1       ContainerCreating   0          50s
tomcathost-6dfc87dc8b-ht2d8   1/1       Running             0          18s
tomcathost-6dfc87dc8b-pfb56   1/1       Running             0          10s
tomcathost-6dfc87dc8b-x8pnn   1/1       Running             0          14s
tomcathost-7f68566795-8pl29   0/1       Terminating         3          2d
tomcathost-7f68566795-trscg   0/1       Terminating         3          2d

验证更新结果

  • nginx服务所在的node机器的IP地址是192.168.119.153,所以在浏览器上访问:http://192.168.119.153:30006/getserverinfo,可以看到”From new version”这个字符串,如下图:

未分类

去dashboard页面看服务详情,可以看见一系列的缩容和扩容事件,如下图:

未分类

Nginx&Tomcat方式和SpringCloud方式扩容对比

在之前的文章中,我们实战了SpringCloud环境下服务提供方的扩容,由于是“注册&发现”的方式,扩容只需要往SpringCloud环境添加provider机器,不需要做什么设置,请求就会被落到新的provider上,相关实战的地址如下:

  1. Docker下的Spring Cloud三部曲之一: http://blog.csdn.net/boling_cavalry/article/details/79177930

  2. Docker下的Spring Cloud三部曲之二: http://blog.csdn.net/boling_cavalry/article/details/79134497

  3. Docker下的Spring Cloud三部曲之三: http://blog.csdn.net/boling_cavalry/article/details/79192376

在Nginx加Tomcat环境中,如果不是在kubernetes环境,我们增加Tomcat之后需要修改Nginx配置,否则到达Nginx的请求不会被转发到新的机器上去,幸运的是kubernete帮我们解决了这个问题,扩容缩容都只需要控制副本数即可,不用修改Nginx配置了;

doceker-compose虽然可以修改副本数,但是Nginx的配置仍然需要修改,否则新创建的Tomcat容器都有自己的IP地址,Nginx还是感知不到;

至此,kubernetes下的Nginx加Tomcat三部曲就全部结束了,希望能在您的kubernetes实战中有所帮助;

kubernetes下的Nginx加Tomcat三部曲之二:细说开发

本文是《kubernetes下的Nginx加Tomcat三部曲》的第二章,在 http://devops.webres.wang/2018/02/kubernetes%E4%B8%8B%E7%9A%84nginx%E5%8A%A0tomcat%E4%B8%89%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%B8%80%EF%BC%9A%E6%9E%81%E9%80%9F%E4%BD%93%E9%AA%8C/ 一文我们快速部署了Nginx和Tomcat,达到以下效果:

未分类

本文我会详细说明在kubernetes部署上述网络服务时,需要做哪些具体的工作;

列举步骤

需要以下操做才能在kubernetes上部署Nginx加Tomcat的服务:

  1. 开发Tomcat上的web工程和Docker镜像;
  2. 让kubernetes的机器用上web工程的Docker镜像;
  3. 开发Tomcat对应的deployment脚本;
  4. 开发Tomcat对应的service脚本;
  5. 开发Nginx对应的Docker镜像;
  6. 让kubernetes的机器用上Nginx的Docker镜像
  7. 开发Nginx对应的deployment脚本;
  8. 开发Nginx对应的service脚本;
  9. 开发启动上述pod和service的脚本;
  10. 开发停止并清除上述pod和service的脚本

脚本文件下载

本次体验所需的deployment和service资源是通过脚本创建的,这个脚本可以通过以下两种方式中的任意一种下载:

  1. CSDN下载(无法设置免费下载,只能委屈您用掉两个积分了):http://download.csdn.net/download/boling_cavalry/10235034
  2. GitHub下载,地址和链接信息如下表所示:

未分类

这个git项目中有多个目录,本次所需的资源放在k8s_nginx_tomcat_resource,如下图红框所示:

未分类

下到的k8stomcatcluster20180201.tar是个压缩包,复制到可以执行kubectl命令的ubuntu电脑上,然后解压开,是个名为k8stomcatcluster的文件夹;

Spring boot的web工程源码下载

GitHub下载,地址和链接信息如下表所示:

未分类

这个git项目中有多个目录,本次的web工程源码放在k8stomcatdemo,如下图红框所示:

未分类

接下来我们开始实战开发吧;

开发环境

本次实战开发环境的具体信息如下:

  1. 操作系统:Ubuntu16;
  2. Docker版本:17.03.2-ce;
  3. JDK:1.8.0_151;
  4. maven:3.3.3;

Tomcat上的web工程和Docker镜像

web工程用来提供http服务,返回当前机器的IP地址给浏览器,完整源码请参照前面下载的k8stomcatdemo工程,这里我们还是重新创建一次;

1、创建一个springboot工程,pom.xml内容如下:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.bolingcavalry</groupId>
    <artifactId>k8stomcatdemo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>k8stomcatdemo</name>
    <description>Demo project for Spring Boot</description>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.9.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>

            <!--新增的docker maven插件-->
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
                <version>0.4.12</version>
                <!--docker镜像相关的配置信息-->
                <configuration>
                    <!--镜像名,这里用工程名-->
                    <imageName>bolingcavalry/${project.artifactId}</imageName>
                    <!--TAG,这里用工程版本号-->
                    <imageTags>
                        <imageTag>${project.version}</imageTag>
                    </imageTags>
                    <!--镜像的FROM,使用java官方镜像-->
                    <baseImage>java:8u111-jdk</baseImage>
                    <!--该镜像的容器启动后,直接运行spring boot工程-->
                    <entryPoint>["java", "-jar", "/${project.build.finalName}.jar"]</entryPoint>
                    <!--构建镜像的配置信息-->
                    <resources>
                        <resource>
                            <targetPath>/</targetPath>
                            <directory>${project.build.directory}</directory>
                            <include>${project.build.finalName}.jar</include>
                        </resource>
                    </resources>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

可以看到这是个普通的springboot的web工程,唯一不同的是多了一个maven插件:docker-maven-plugin,使用该插件我们可以将maven工程制作成docker镜像;

2、整个工程只有一个Controller,开通一个http接口,将当前服务器IP地址返回,源码如下:

@RestController
public class ServerInfo {

    @RequestMapping(value = "/getserverinfo", method = RequestMethod.GET)
    public String getUserInfoWithRequestParam(){
        return String.format("server : %s, time : %s", getIPAddr(), new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()));
    }

    /**
     * 获取本机IP地址
     * @return
     */
    private static String getIPAddr(){
        String hostAddress = null;
        try{
            InetAddress address = InetAddress.getLocalHost();
            hostAddress = address.getHostAddress();
        }catch (UnknownHostException e){
            e.printStackTrace();
        }

        return hostAddress;
    }
}

以上就是工程的关键源码;

3、在pom.xml所在目录执行mvn clean package -DskipTests docker:build,会编译构建工程,并且在本地制作好镜像文件,如下:

root@maven:/usr/local/work/github/blog_demos# docker images
REPOSITORY                                              TAG                 IMAGE ID            CREATED             SIZE
bolingcavalry/k8stomcatdemo                             latest              1d41d9980a0b        43 hours ago        658 MB
bolingcavalry/k8stomcatdemo                             0.0.1-SNAPSHOT      c91bc368a729        46 hours ago        658 MB

想了解更多maven制作docker镜像的细节,请看 http://blog.csdn.net/boling_cavalry/article/details/78872020

让kubernetes的机器用上web工程的Docker镜像

现在的镜像只存在于开发和构建web工程的电脑上,为了让kubernetes的node机器能用上这个镜像,可以用以下几种方式实现:

  1. 用docker push命令将本机镜像推送到hub.docker.com网站,这样其他机器都可以通过docker pull命令取得了,我就是用的这种方法,需要在hub.docker.com上注册;
  2. 用docker save命令导出镜像文件,再用docker load命令导入;
  3. kubernetes所在机器安装java和maven环境,将工程在这里编译构建;
  4. 使用docker私有仓库,例如搭建局域网私有仓库或者阿里云私有仓库,参考 http://blog.csdn.net/boling_cavalry/article/details/78934391

Tomcat对应的deployment脚本

用yaml文件将详情配置好,再用kubectl命令执行这个配置就能创建pod,这个web应用镜像的配置文件名为tomcat.yaml,内容如下:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tomcathost
spec:
  replicas: 3
  template:
    metadata:
     labels:
       name: tomcathost
    spec:
     containers:
     - name: tomcathost
       image: bolingcavalry/k8stomcatdemo:0.0.1-SNAPSHOT
       tty: true
       ports:
       - containerPort: 8080

将上述脚本的几个关键点列举一下:

  1. version用extensions/v1beta1;
  2. kind用Deployment,支持升级镜像和滚动升级;
  3. 使用的镜像bolingcavalry/k8stomcatdemo:0.0.1-SNAPSHOT,是我从本地push到hub.docker.com上去的;
  4. 创建的容器对外暴露了8080端口;

Tomcat对应的service脚本

创建了tomcat的pod之后,为了能在kubernetes环境中给其他service使用,需要将这些pod包装为service,这里是通过tomcat-svc.yaml文件来配置的,内容如下:

apiVersion: v1
kind: Service
metadata:
  name: tomcathost
spec:
  type: ClusterIP
  ports:
       - port: 8080
  selector:
    name: tomcathost

将上述脚本的几个关键点列举一下:

  1. 服务对应的pod是tomcathost;
  2. type用ClusterIP,为内部service调用提供统一IP地址;
  3. 服务对外暴露了pod的8080端口;

Nginx对应的Docker镜像

  • 定制的Nginx镜像和Nginx官方镜像相比,唯一的区别就是nginx.conf文件不同,我们用的nginx.conf内容如下:
user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    #include /etc/nginx/conf.d/*.conf;

    upstream tomcat_client {
         server tomcathost:8080;
    } 

    server {
        server_name "";
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        location / {
            proxy_pass http://tomcat_client;
            proxy_redirect default;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

以上配置中,新增的upstream对应的IP地址是tomcathost,这是tomcat的service名称,在Nginx运行的时候,通过tomcathost就能访问到tomcat的Pod;

  • 制作Docker镜像的Dockerfile文件内容如下,每行都有注释就不再多说了:
# First docker file from bolingcavalry
# VERSION 0.0.1
# Author: bolingcavalry

#基础镜像
FROM nginx:stable

#作者
MAINTAINER BolingCavalry <[email protected]>

#定义工作目录
ENV WORK_PATH /etc/nginx

#定义conf文件名
ENV CONF_FILE_NAME nginx.conf

#删除原有配置文件
RUN rm $WORK_PATH/$CONF_FILE_NAME

#复制新的配置文件
COPY ./$CONF_FILE_NAME $WORK_PATH/

#给shell文件赋读权限
RUN chmod a+r $WORK_PATH/$CONF_FILE_NAME

将nginx.conf和Dockerfile放在同一个目录,然后执行命令docker build -t bolingcavalry/nginx-with-tomcat-host:0.0.1 .,就能构建镜像文件了,如下:

root@maven:/usr/local/work/nginx# docker build -t bolingcavalry/nginx-with-tomcat-host:0.0.1 .
Sending build context to Docker daemon 14.51 MB
Step 1/7 : FROM nginx:stable
 ---> dfe062ee1dc8
Step 2/7 : MAINTAINER BolingCavalry <[email protected]>
 ---> Using cache
 ---> 93f4bf154c55
Step 3/7 : ENV WORK_PATH /etc/nginx
 ---> Using cache
 ---> d0158757fc9c
Step 4/7 : ENV CONF_FILE_NAME nginx.conf
 ---> Using cache
 ---> 7a18a8b417d6
Step 5/7 : RUN rm $WORK_PATH/$CONF_FILE_NAME
 ---> Using cache
 ---> f6f27d25539d
Step 6/7 : COPY ./$CONF_FILE_NAME $WORK_PATH/
 ---> Using cache
 ---> 33075a2b0379
Step 7/7 : RUN chmod a+r $WORK_PATH/$CONF_FILE_NAME
 ---> Using cache
 ---> 58ce530e160b
Successfully built 58ce530e160b

让kubernetes的机器用上Nginx的Docker镜像

这一步和之前的web工程的镜像放到kubernetes一样,有多种方式,我用的还是通过docker push推送到hub.docker.com网站,再在kubernetes上pull下来;

Nginx对应的deployment脚本

用yaml文件将详情配置好,再用kubectl命令执行这个配置就能创建pod,这个web应用镜像的配置文件名为nginx.yaml,内容如下:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ng
spec:
  replicas: 1
  template:
    metadata:
     labels:
      name: ng
    spec:
     containers:
     - name: ng
       image: bolingcavalry/nginx-with-tomcat-host:0.0.1
       ports:
       - containerPort: 80

以上配置中有几点要注意:

  1. 使用镜像是刚才创建的nginx镜像bolingcavalry/nginx-with-tomcat-host:0.0.1;
  2. pod容器创建后,对外暴露80端口;

Nginx对应的service脚本

通过service定义的yaml文件nginx-svc.yam,将前面创建的nginx的pod包装为service:

apiVersion: v1
kind: Service
metadata:
  name: ng
spec:
  type: NodePort
  ports:
       - port: 80
         nodePort: 30006
  selector:
    name: ng

以上配置中有几点要注意:

  1. type使用NodePort,这样可以通过节点机器的IP访问此service;
  2. 将节点机器的30006端口和pod的80端口绑定,因此,外部访问节点IP+30006端口就能访问到此Nginx服务了;

启动上述pod和service的脚本

接下来我们创建一个shell脚本start_all.sh,将上述的tomcat和nginx的pod以及service全部创建和启动:

kubectl create -f tomcat.yaml
kubectl create -f tomcat-svc.yaml
kubectl create -f nginx.yaml
kubectl create -f nginx-svc.yaml
echo ""
echo "nginx and tomcat running now"

如上所示,通过kubectl create -f加文件名,就能创建好yaml文件中定义的pod和service;

停止并清除上述pod和service的脚本

创建一个shell脚本stop_all.sh,能够将上述的tomcat和nginx的pod以及service全部清除掉:

kubectl delete service tomcathost
kubectl delete deployment tomcathost
kubectl delete service ng
kubectl delete deployment ng
echo "nginx and tomcat stop now"

如上所示,其实就是通过kubectl delete命令将指定的pod和service资源删除;

以上就是在kubernetes搭建整个Nginx加Tomcat环境的所有资源,您就可以用这些像 http://devops.webres.wang/2018/02/kubernetes%E4%B8%8B%E7%9A%84nginx%E5%8A%A0tomcat%E4%B8%89%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%B8%80%EF%BC%9A%E6%9E%81%E9%80%9F%E4%BD%93%E9%AA%8C/ 文中那样去搭建和体验kubernetes下的Nginx加Tomcat;

下一章,我们会在此环境的基础上实战Tomcat服务的扩容,并修改web工程的代码,再创建新的镜像,并且将kubernetes环境下在线升级新的web工程服务;