Kubernetes + GitLab 微服务应用自动化部署

等级 487 0 0

Kubernetes + GitLab 微服务应用自动化部署

Docker 简化了单个服务的部署,Kubernetes 通过强大的容器编排能力使得运维人员可以轻松管理成千上万的容器,这些容器归属于多个服务,而这些服务又组合形成了多个应用。从代码到运行中的应用,需要经历构建、打包、测试和部署等阶段,如果每个步骤都手动执行,无疑会消耗研发人员的大量时间。本文讲解如何使用 GitLab CI/CD 来自动部署微服务应用到 Kubernetes 集群。

背景

笔者最近在负责公司研发中台的建设,以提升公司整体研发效率,其中很重要的一个环节就是解决从代码到运行中服务的部署效率问题。由于公司项目众多,以前都是各个项目各自为阵,每个项目都有自己的开发、测试环境,资源利用率低,浪费严重,并且基本采用传统手动部署方式,部署效率低且容易出错。经过调研,笔者最终选择了 Kubernetes + GitLab 的组合来实现了跨项目资源复用和应自动化部署。无论是开发、测试还是生产环境,每个环境各项目都共享同一个 Kubernetes 集群,复用同一套计算和存储资源。长期没有开发活动的项目可一键从开发和测试环境里下线,以让出资源给其它活跃项目,需要的时候可快速恢复开发和测试环境。对于开发、测试环境,每个项目每天都要部署多次,如果项目采用微服务架构,那么部署次数还会随着微服务数量翻倍,因此自动化部署就显得非常必要。通过使用 GitLab CI/CD,我们做到了在开发人员提交代码后就自动触发代码构建、镜像打包并部署到 Kubernetes 集群。

Kubernetes 微服务应用部署

微服务应用部署架构

先来看一下在 Kubernetes 集群里部署微服务应用的整体架构:

Kubernetes + GitLab 微服务应用自动化部署

为了简化 Kubernetes 集群的管理,我们使用了 Rancher,一个企业级的 Kubernetes 多集群管理系统。无论是云服务商提供的集群,还是自建集群,均可通过 Rancher 来统一管理。如果是自建集群,还可使用 Rancher 提供的工具来快速创建。

为了实现物理上隔离,不同的环境需要使用独立的 Kubernetes 集群。各个集群在内部结构上比较类似,但会有一些细微差别,比如开发和测试环境 MySQL 是独立部署,而生产环境为了高可用会采用主从部署。各个应用公用的 MySQL、Redis、Elasticsearch 等服务放在 default 命名空间里,每个应用都有其自己的命名空间,以防止命名冲突和限制权限。对外暴露的服务需要为其创建 Ingress 对象,然后 Ingress Controller 会按照 Ingress 的指示在 Kubernetes 集群的所有 Worker 节点上将服务暴露给外部。Worker 节点一般对外不可访问,并且存在多个,为了解决外部网络访问多个 Worker 节点上的暴露服务,还需要使用 HAProxy 这样的负载均衡器来作为外部流量入口并转发请求给某个 Worker 节点。

Kubernetes 集群管理

安装 Rancher

Rancher 支持多种安装方式,最简单的就是使用 Docker 在单个节点上运行 Rancher Server,适合集群节点数量不多的场景,比如开发、测试环境。如果集群节点数量较多,建议使用一个 Kubernetes 集群来安装 Rancher 自身。这个集群可以使用 Rancher 提供的 K3SRKE 工具来创建,推荐使用 K3S。K3S 是轻量级的 Kubernetes,易于安装,内存消耗只有原生 Kubernetes 的一半,所有组件打包在一个不到 50MB 的二进制文件中,适合资源较少、功能需求简单的场景。RKE 是经 CNCF 认证过的 Kubernetes 发行版,它简化了 Kubernetes 集群安装的复杂性。具体安装步骤可参考官方文档 Installing Rancher

创建 Kubernetes 集群

Rancher 除了支持使用其 RKE 工具来创建 Kubernetes 集群,还支持 Google、Amazon、Azure、Alibaba 等云服务商,甚至还可以把现有的集群导入到 Rancher 里来管理。这里我们选择 RKE 方式,在自定义节点上创建 Kubernetes 集群。

在创建 Kubernetes 集群之前需要先准备好节点。Rancher 支持 Ubuntu、CentOS 等常见 Linux 发行版(64-bit x86,ARM64 还处于试验阶段),并且安装好 Docker,Windows 系统只能用于 Worker 节点,并且需要运行 Docker 企业版。各节点之间网络必须是连通的,如果启用了防火墙,需要开放相关端口。由于开放端口较多,建议将各节点加入同一个安全组,然后在每个节点上允许组内其它节点访问任意端口。节点角色分为 etcdcontrolplaneworker,单个节点可具备一种或多种角色,最好只具备一种。其中 etcd 角色至少有三个节点,controlplane 和 worker 角色建议至少两个节点。

打开 Rancher UI,在 Global -> Cluster 页点击 Add Cluster 按钮来创建一个 Kubernetes 集群。首先需要填写集群名称、成员等信息,然后是添加节点。添加节点时需要先选择一到多种角色,然后拷贝页面显示的命令到节点服务器上执行,即可把该节点添加到集群里。创建完成后的集群显示如下:

Kubernetes + GitLab 微服务应用自动化部署
Kubernetes + GitLab 微服务应用自动化部署

安装 Rook Ceph 块存储服务

应用服务一般是无状态的,它们的状态保存在后端存储服务里,比如 MySQL、Elasticsearch 等。为了防止状态丢失,需要将服务状态持久化到存储上保存起来。传统部署方式下,计算和存储位于同一个节点,存储为本地磁盘。而在 Kubernetes 里,需要尽量避免使用节点本地存储,因为这样 Pod 会绑定到特定的节点,导致其无法在不同节点之间进行调度。Kubernetes 通过 PV(Persistent Volume)和 StorageClass 来抽象 Pod 对存储资源的需求。PV 可以使用手动方式预先创建好,也可以通过 StorageClass 来按需动态创建。PV 可以来源于节点本地路径、节点本地磁盘或者云服务商提供的块存储服务,如前所述应尽量避免使用本地存储。为了解决非云服务商环境里的 Kubernetes 集群的存储问题,我们可以选择一些开源方案来在 Kubernetes 集群内提供块存储服务。这里推荐两个,一个是 Rancher 发起的 Longhorn,另外一个是出现得更早的 Rook。相比而言,Rook 要比 Longhorn 更成熟一些,因为其底层使用了 Ceph(也支持其它块存储驱动,不过 Ceph 最为成熟),因此我们选择了 Rook。除了提供块存储服务,Rook Ceph 还能够提供对象存储服务(OSS)和共享文件系统服务(Shared Filesystem)。

在 Kubernetes 集群里安装 Rook Ceph 块存储服务的步骤如下,更多内容可参考官方文档 Ceph Storage Quickstart

# 克隆代码
git clone --single-branch --branch v1.4.6 https://github.com/rook/rook.git
cd rook/cluster/examples/kubernetes/ceph

# 创建 Rook CRD 和 Operator
kubectl create -f common.yaml
kubectl create -f operator.yaml

# 确认 rook-ceph-operator 处于 `Running` 状态后再继续后续操作
kubectl -n rook-ceph get pod

# 创建一个 Rook Ceph 存储集群
kubectl create -f cluster.yaml 

Rook 会使用所有 Worker 节点来创建一个 Ceph 集群,其存储资源包含所有节点上的所有 Raw 设备(没有分区或文件系统)和 Raw 分区(没有文件系统)。

为了方便日后查看和管理 Ceph 集群,建议安装 Rook 提供的 Toolbox,然后可进入 rook-ceph-tools 容器执行各种操作。

# 安装 Toolbox
$ kubectl create -f toolbox.yaml

# 进入 `rook-ceph-tools` 容器,查看 Ceph 集群状态
$ ceph status
  cluster:
    id:     09ee35d4-2ed2-4c33-b819-50c025a2c59d
    health: HEALTH_WARN
            mons a,d are low on available space

  services:
    mon: 3 daemons, quorum a,b,d (age 23h)
    mgr: a(active, since 9d)
    osd: 6 osds: 6 up (since 3d), 6 in (since 2w)

  data:
    pools:   2 pools, 33 pgs
    objects: 10.99k objects, 42 GiB
    usage:   131 GiB used, 2.8 TiB / 2.9 TiB avail
    pgs:     33 active+clean

  io:
    client:   84 KiB/s wr, 0 op/s rd, 3 op/s wr 

此外 Ceph 本身也提供了 Dashboard 来方便浏览集群状态,这个 Dashboard 在安装 Ceph 集群的时候已安装好,只需通过 Ingress 对象对外暴露即可。

# 注意先修改 YAML 文件中的域名为自己的,该域名指向 Worker 节点(如有多个可使用 HAProxy 这样的负载均衡器)
kubectl create -f dashboard-ingress-https.yaml 

然后在浏览器里打开 Dashboard Ingress 里配置的域名,即可访问 Ceph Dashboard。

Kubernetes + GitLab 微服务应用自动化部署

前面只是安装好了 Rook Ceph 集群,为了在 Kubernetes Workloads 里使用 Ceph 集群的存储资源,还需要创建 StorageClass。

# 创建一个三副本的存储池 CephBlockPool,以及可从该存储池获取资源的 StorageClass
kubectl create -f csi/rbd/storageclass.yaml 

创建好的 StorageClass 名为 rook-ceph-block,然后就可以创建 PVC(PersistentVolumeClaim) 来申请存储资源了。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql
spec:
  storageClassName: rook-ceph-block
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi 

部署公共服务

一个应用里除了实现业务逻辑的微服务,还有一些非业务的公共服务,比如数据库、缓存、消息队列、搜索等服务。这些服务跟具体业务无关,可以在多个应用之间共享,但要注意从命名空间上跟应用进行隔离。下面以 MySQL 服务为例:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql
spec:
  storageClassName: rook-ceph-block
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: registry.prod.bbdops.com/common/mysql:8.0.20
        name: mysql
        env:
        - name: TZ
          value: Asia/Shanghai
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql
              key: root-password
        resources:
          requests:
            memory: 400Mi
            cpu: 0.1
          limits:
            memory: 4Gi
            cpu: 1
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: mysql
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql 

上面的 YAML 文件创建了一个名为 mysql 的 MySQL 服务,假设其位于 default 命名空间,其它命名空间里的应用可通过 mysql.default 主机名来访问。

部署和暴露微服务

应用微服务一般没有状态,不需要创建 PVC 对象和挂载 PV,因此其部署比较简单,这里就不举具体例子了。如果某个微服务需要对外暴露,需要为其创建 Ingress 对象。对于有使用网关的微服务架构应用,只需要暴露其网关服务即可,其它微服务可通过网关代理访问,这样可避免创建过多 Ingress 对象。

通过 Nginx Ingress Controller 暴露的服务统一通过 Worker 节点上的 Nginx 来代理访问,如果 Worker 节点对外不可见或者有多个,那么还需在负载均衡器上配置转发。这里以 HAProxy 四层负载均衡为例:

...

listen kubernetes-nginx
    mode tcp
    balance roundrobin

    # nginx
    bind *:80
    bind *:443

    server dev-kubeworker-1 dev-kubeworker-1 check
    server dev-kubeworker-2 dev-kubeworker-2 check
    server dev-kubeworker-3 dev-kubeworker-3 check

... 

本地开发环境访问 Kubernetes 开发集群服务

微服务架构虽然有很多好处,但同时也会造成一些麻烦,其中一个就是会增加开发人员搭建本地开发环境的难度。为了开发和调试一个微服务,需要同时启动一堆依赖的微服务和数据库、缓存等公共服务。为了简化本地开发环境搭建,可以让本地正在开发的微服务直接访问 Kubernetes 集群里的服务,这样本地只需启动正在开发中的服务。

前面已学会如何使用 Ingress 对象来暴露 HTTP 服务,如果是 MySQL 这样的 TCP 服务,Nginx Ingress Controller 也是支持的。只需要在 Nginx Ingress Controller 所在命名空间 ingress-nginx 里创建如下的 ConfigMap 对象即可:

apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-services
data:
  3306: "default/mysql:3306" 

Nginx Ingress Controller 会在每个 Worker 节点上启动一个 hostNetwork 类型的 Pod,这样 Pod 直接使用宿主机网络,其监听端口在宿主机上可访问,比如可以通过访问 Worker 节点的 3306 端口来访问 MySQL 服务。如果 Worker 节点对外不可见或者有多个,同样可以在 HAProxy 负载均衡器上配置转发:

...

listen kubernetes-tcp
    mode tcp
    balance roundrobin

    # mysql
    bind *:3306

    server dev-kubeworker-1 dev-kubeworker-1 check
    server dev-kubeworker-2 dev-kubeworker-2 check
    server dev-kubeworker-3 dev-kubeworker-3 check

... 

应用微服务也可以采取类似的方式来暴露,为了减少配置 Nginx Ingress Controller,可在部署微服务时直接为其创建一个 NodePort 类型的服务。

apiVersion: v1
kind: Service
metadata:
  name: user
spec:
  type: NodePort
  ports:
    - port: 8080
      nodePort: 30010
  selector:
    app: user 

如果使用了 HAProxy,则同样需要配置端口转发。如果应用有多个微服务需要暴露,可为其分配一个端口范围(比如 30010-30019),然后利用 HAProxy 的端口范围转发来减少配置工作。

...

    # app1
    bind *:30010-30019

... 

GitLab CI/CD

介绍

GitLab 从开源 SCM(Source Code Management)开始,但很快发展成为完整的 DevOps 解决方案,提供的功能包括项目管理、私有容器注册和构建环境(包括 Kubernetes)。GitLab CI/CD 由 GitLab Runner 驱动,在自包含的环境中执行 CI/CD 流水线中的每个步骤。可以通过 gitlab-ci.yml 清单完成 CI/CD 配置,该清单支持一些高级配置,包括逻辑条件运算和导入其他清单,或者使用 Auto DevOps,无需配置即可自动创建流水线。

创建 Runner

为了能够执行流水线中的任务(Job),需要先创建至少一个 Runner。Runner 可以是所有项目共享的(Shared),也可以为某个组(Group)或某个项目(Project)创建。

首先,在要运行 Runner 的机器上安装 gitlab-runner 工具,支持多种方式,推荐 Repositories 方式,具体可参考 Install GitLab Runner

其次,为所有项目,或某个组,或某个项目创建一个 Runner,创建前请在系统、组或项目的 Settings -> CI/CD 页里获取授权 Token。Runner 的类型可以是 shell、docker、kubernetes 等。其中 shell 类型直接在本地运行构建任务,配置简单并且容易实现构建缓存,docker 类型在本地启动容器来运行构建任务,隔离性好但实现构建缓存比较麻烦,性能上也较差,推荐更简单易用的 shell 类型。

配置流水线(Pipeline)

下面我们以自动构建和部署一个 Java Spring Boot 服务为例来讲解如何配置流水线。在项目根目录下创建一个名为 .gitlab-ci.yml 的文件,内容如下(每个任务的具体内容后面会讲到):

stages:
  - build
  - package
  - deploy

maven-build:
  ...

docker-build:
  ...

.kubernetes-deploy:
  ...

kubernetes-deploy-development:
  ...

kubernetes-deploy-testing:
  ...

kubernetes-deploy-production:
  ... 

其中 stages 定义本流水线将顺序执行 build(构建)、package(打包) 和 deploy(部署) 三个阶段(Stage),每个阶段可并行执行多个任务(Job)。

在流水线配置文件中可通过 $ 来引用变量,变量名通常为大写,单词之间以 _ 分隔。变量可在流水线中通过 variables 指令来定义,也可在组或项目的 Settings -> CI/CD 页里定义,这样就不用暴露在配置文件中。GitLab 预定义了许多环境变量,具体可查阅 Predefined environment variables reference

构建

maven-build:
  stage: build
  tags:
    - java
  variables:
    MAVEN_OPTS: "-Dmaven.test.skip=true"
    MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
  script:
    - mvn $MAVEN_CLI_OPTS package
  artifacts:
    paths:
      - target/*.jar 

任务 maven-build 属于阶段 build,它使用 maven 镜像来编译 Java 代码并打包为 Jar 包。

打包

docker-build:
  stage: package
  tags:
    - java
  variables:
    DOCKER_IMAGE_NAME: registry.prod.bbdops.com/canghai/user
  script:
    - docker build -t $DOCKER_IMAGE_NAME:$CI_COMMIT_SHORT_SHA -t $DOCKER_IMAGE_NAME:$CI_COMMIT_REF_NAME -t $DOCKER_IMAGE_NAME:latest .
    - docker push $DOCKER_IMAGE_NAME:$CI_COMMIT_SHORT_SHA
    - docker push $DOCKER_IMAGE_NAME:$CI_COMMIT_REF_NAME
    - docker push $DOCKER_IMAGE_NAME:latest 

任务 docker-build 属于阶段 package,它负责将构建阶段得到的 Jar 包打包为 Docker 镜像。Docker 镜像构建所用的 Dockerfile 位于项目根目录下,内容如下:

FROM openjdk:8u252

ENV TZ Asia/Shanghai

WORKDIR /app
ADD target/user-1.0-SNAPSHOT.jar app.jar
EXPOSE 8080
CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "app.jar"] 

部署

.kubernetes-deploy:
  stage: deploy
  tags:
    - java
  before_script:
    - sed -i 's/$CI_COMMIT_SHORT_SHA/'"$CI_COMMIT_SHORT_SHA"'/' deployment.yml

kubernetes-deploy-development:
  extends: .kubernetes-deploy
  only:
    refs:
      - dev
  script:
    - sed -i 's/$SPRING_PROFILES_ACTIVE/dev/' deployment.yml
    - kubectl apply -f deployment.yml -n canghai --kubeconfig=$HOME/.kube/development-config.yml

kubernetes-deploy-testing:
  extends: .kubernetes-deploy
  only:
    refs:
      - test
  script:
    - sed -i 's/$SPRING_PROFILES_ACTIVE/test/' deployment.yml
    - kubectl apply -f deployment.yml -n canghai --kubeconfig=$HOME/.kube/testing-config.yml

kubernetes-deploy-production:
  extends: .kubernetes-deploy
  only:
    refs:
      - master
  when: manual
  script:
    - sed -i 's/$SPRING_PROFILES_ACTIVE/prod/' deployment.yml
    - kubectl apply -f deployment.yml -n canghai --kubeconfig=$HOME/.kube/production-config.yml 

部署阶段包含三个任务,不过三个任务同时只会执行其中一个,根据当前提交代码的分支来决定要执行哪一个,从而部署到对应的 Kubernetes 集群。隐藏任务 .kubernetes-deploy 将三个任务的公共部分提取了出来,以避免重复。Kubernetes 部署文件 deployment.yml 的内容如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user
spec:
  replicas: 1
  selector:
    matchLabels:
      app: user
  template:
    metadata:
      labels:
        app: user
    spec:
      imagePullSecrets:
        - name: bbd-docker-registry
      containers:
        - image: registry.prod.bbdops.com/canghai/user:$CI_COMMIT_SHORT_SHA
          name: user
          env:
            - name: spring.profiles.active
              value: $SPRING_PROFILES_ACTIVE
            - name: eureka.instance.hostname
              value: user
          resources:
            requests:
              memory: 200Mi
              cpu: 0.1
            limits:
              memory: 2Gi
              cpu: 1
          ports:
            - containerPort: 8080
              name: user
---
apiVersion: v1
kind: Service
metadata:
  name: user
spec:
  ports:
    - port: 8080
  selector:
    app: user 

其中用到了 GitLab 预定义的环境变量 CI_COMMIT_SHORT_SHA,这里需要我们自己使用 sed 命令来替换为对应的变量值,只有 GitLab CI 配置文件里的变量才会自动替换。如果是私有 Registry,还需创建存放访问 Registry 的帐号密码的 Kubernetes Secret 对象 bbd-docker-registry,否则拉取镜像会失败。

至此,GitLab 流水线就配置完成,下面是其实际执行效果:

Kubernetes + GitLab 微服务应用自动化部署
Kubernetes + GitLab 微服务应用自动化部署
Kubernetes + GitLab 微服务应用自动化部署
Kubernetes + GitLab 微服务应用自动化部署

本文转自 https://blog.jaggerwang.net/kubernetes-gitlab-microservice-application-auto-deploy/,如有侵权,请联系删除。

收藏
评论区

相关推荐

30min搭建kubernetes
master and node 操作如下 yum源修改 // 备份本地yum源 mv /etc/yum.repos.d/CentOSBase.repo /etc/yum.repos.d/CentOSBase.repo_bak // 获取阿里yum源配置 wget O /etc/yum.repos.d/CentOSBase.repo http:
Kubernetes(k8s)中文文档 Kubernetes概述
简介 Kubernetes(https://www.kubernetes.org.cn/)是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。 Kubernetes一个核心的特点就是能够自主的管理容
Kubernetes + GitLab 微服务应用自动化部署
Kubernetes GitLab 微服务应用自动化部署 Docker 简化了单个服务的部署,Kubernetes 通过强大的容器编排能力使得运维人员可以轻松管理成千上万的容器,这些容器归属于多个服务,而这些服务又组合形成了多个应用。从代码到运行中的应用,需要经历构建、打包、测试和部署等阶段,如果每个步骤都手动执行,无疑会消耗研发人员的大量时间。本文讲解
Kubernetes Ingress — NGINX
在 Kubernetes 中,Service 是一种抽象的概念,它定义了每一组 Pod 的逻辑集合和访问方式,并提供一个统一的入口,将请求进行负载分发到后端的各个 Pod 上。Service 默认类型是 ClusterIP,集群内部的应用服务可以相互访问,但集群外部的应用服务无法访问。为此 Kubernetes 提供了 NodePorts,LoadBalan
Kubernetes Ingress — Kong
Kong 是由 Mashape 公司开源的一个高性能、高可用、易扩展的 API Gateway 项目,基于OpenResty(Nginx Lua模块),并提供了插件实现 API 的 AOP 功能。可以通过负载均衡、插件扩展等方式,来处理网络请求。 Kong 主要的概念Servi
Kubernetes部署高可用PostgreSQL集群
PostgreSQL 是一个功能强大的开源关系数据库,它使用和扩展了 SQL 语言,并结合了许多安全存储和扩展最复杂数据工作负载的功能。PostgreSQL 的起源可以追溯到 1986 年,作为加利福尼亚大学伯克利分校 POSTGRES 项目的一部分,与 Linux 内核相似,PostgreSQL 是由社区驱动的开源项目,由全世界贡献者所维护。Postgre
Kubernetes自定义调度器 — 初识调度框架
Kubernetes 已经成为容器编排(Orchestration)平台的事实标准,它为容器化应用提供了简单且高效部署的方式、大规模可伸缩、资源调度等生命周期管理功能。kubescheduler作为kubernetes的核心组件,它负责整个集群资源的调度功能,根据特定的调度算法或调度策略,将Pod调度到最优的Node节点,使集群的资源得到合理且充分的利用。
Kubernetes自定义调度器 — 初窥门径
通过上一篇文章对schedulerframework调度框架已经有了大致了解,根据我们的实际生产的一些问题(如计算服务没有被调度到实际CPU最优的节点)和需求,来实现一个简单的基于CPU指标的自定义调度器。自定义调度器通过kubernetes资源指标服务metricsserver来获取各节点的当前的资源情况,并进行打分,然后把Pod调度到分数最高的节
Prometheus架构与实践分享
Prometheus已经被广泛应用于数据中心监控,尤其是和Kubernetes结合的容器监控。本文主要从架构分析到落地实践,详细介绍Prometheus原理和使用。对比Prometheus与其他监控工具(Zabbix、OpenFalcon)的特点与使用场景。然后介绍Prometheus与Kubernetes集成,主要从监控和自动伸缩两个方面。最后通过企业案
DevOps与CICD的区别 及 docker、k8s的CICD思路
1\. DevOps简介DevOps 就是开发(Development)、测试(QA)、运维(Operations)这三个领域的合并。image.png为什么要合并这三个领域?主要是开发和运维的脱节。DevOps是一种思想、一组最佳实践、以及一种文化。DevOps落地实施,从组织架构、设计人员、流程、人员分工、人员技能到工具,变化
基于k8s的DevOps实践之路
原标题:基于k8s的DevOps实践之路很多快速发展的公司都面临着一个巨大挑战:在需求不断动态横向扩容的同时继续保持系统的高可用性。如何有效解决这一问题,Kubernetes(k8s)应运而生。k8s以运行可扩展工作负载而闻名,它可以根据资源使用情况调整工作负载。白山科技云分发团队基于多年的DevOps实践经验,在白山会运维日第三期与Thoughtworks
SRE和DevOps值得关注的十大开源项目
构建可扩展且高度可靠的软件系统是每个SRE的最终目标。在SRE/DevOps领域中,有大量出色的开源项目,每个项目都有新颖而激动人心的解决方案。在本文中,我们将会介绍一些在监视,部署和维护领域最受欢迎的开源项目。 1\. Cloudprober可以主动跟踪和监视应用程序,并帮助你提前发现故障。它使用“活动(active)”监视模型来检查你的组件是否按预
2021年值得关注的五个云原生安全问题
云原生正变得越来越流行,在2020年,统计发现,其中83%的组织也在生产环境中使用kubernetes。由于,团队可以轻松地构建和使用,,,以及管理服务,而不必担心底层的服务器。但是,云原生安全性仍然是一个真正的挑战。奇怪的是,云原生安全性的最大问题与所有新技术无关。首席安全官表示,如果组织希望以更好地开始新的一年,则应着手解决五个主要的云原生安全性问题。有
2021年云原生技术趋势
2020年3月下旬的几周时间里,COVID19使全球业务停滞不前,因此每个人都在试图找出应对这种疫情的最佳方法。那时候,没有人知道会发生什么,因此会议被取消,合同被搁置,项目被推迟。一切都停止了。但是,到2020年4月初,我们见证了IT社区的工作重新焕发活力。尽管其他行业还不能恢复正常,但很快我们就明白,仍然需要IT来进行经济和社会活动。你甚至可以得出这样
PaaS失败了吗?让我们看看Cloud Foundry的优势
软件团队常见的行为方式可以总结如下:1. 软件部署从Heroku或Firebase开始。2. 在应用程序需要快速扩展时,开始使用Docker进行容器化。3. 在遇到Docker困境的时候,考虑使用Kubernetes等容器编排工具。(https://cdn.thenewstack.io/media/2020/12/5105a24aimage011.