1、告警逻辑框架

Prometheus的告警逻辑框架：

1）指标获取：Prometheus从监控目标中获取指标数据；

2）设置规则：运维人员根据运维管理需要，设置告警规则（rule_files）；

3）推送告警：在Pometheus中指定指定告警规则，并设置告警服务器（prometheus.yml），当发生符合告警的规则时，Prometheus就会将告警信息发送给设置的告警服务器；

4）发送告警：在告警服务器中，设置告警路由和告警接收，告警服务器将会根据告警管理配置将告警信息发送给告警接收器（email等）；

5）处理告警：运维人员接收到告警信息后，对告警信息进行处理，保证被监控对象的正常运行。

2、指定告警服务和规则文件

告诉Promentheus，将告警信息发送给那个告警管理服务，以及使用那个告警规则文件。这里的告警服务在Kubernetes中部署，对外提供的服务名称为alertmanager，端口为9093。告警规则文件为“/etc/prometheus/rules/”目录下的所有规则文件。

global:
 scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
 evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
 # scrape_timeout is set to the global default (10s).

# 指定告警服务器
alerting:
 alertmanagers:
 - static_configs:
 - targets:
 - alertmanager:9093

# 指定告警规则文件
rule_files:
 - "/etc/prometheus/rules/*.yml"
 # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
 - job_name: 'prometheus'

# metrics_path defaults to '/metrics'
 # scheme defaults to 'http'.

static_configs:
 - targets: ['localhost:9090']
 - job_name: 'redis'
 static_configs:
 - targets: ['redis-exporter-np:9121']
 - job_name: 'node'
 static_configs:
 - targets: ['prometheus-prometheus-node-exporter:9100']
 - job_name: 'windows-node-001'
 static_configs:
 - targets: ['10.0.32.148:9182']
 - job_name: 'windows-node-002'
 static_configs:
 - targets: ['10.0.34.4:9182']
 - job_name: 'rabbit'
 static_configs:
 - targets: ['prom-rabbit-prometheus-rabbitmq-exporter:9419']

3、设置告警规则

设置告警的规则，Prometheus基于此告警规则，将告警信息发送给告警服务。这将未启动的实例信息发送给告警服务，告知哪些实例没有正常启动。

#rules
groups:
 - name: node-rules
 rules:
 - alert: InstanceDown # 告警名称
   expr: up == 0 # 告警判定条件
   for: 3s # 持续多久后，才发送
   labels: # 标签
    team: k8s
   annotations: # 警报信息
    summary: "{{$labels.instance}}: has been down"
    description: "{{$labels.instance}}: job {{$labels.job}} has been down "

4、设置告警信息路由和接受器

这里设置通过邮件接收告警信息，当告警服务接收到告警信息后，会通过邮件将告警信息发送给被告知者。

global:
 resolve_timeout: 5m
 smtp_smarthost: 'smtp.163.com:25' # 发送信息邮箱的smtp服务器代理
 smtp_from: 'xxx@163.com' # 发送信息的邮箱名称
 smtp_auth_username: 'xxx' # 邮箱的用户名
 smtp_auth_password: 'SYNUNQBZMIWUQXGZ' # 邮箱的密码或授权码

route:
 group_by: ['alertname']
 group_wait: 10s
 group_interval: 10s
 repeat_interval: 1h
 receiver: 'email'
receivers:
 - name: 'email'
 email_configs:
 - to: 'xxxxxx@aliyun.com' # 接收告警的邮箱
 headers: { Subject: "[WARN] 报警邮件"} # 接收邮件的标题

inhibit_rules:
 - source_match:
 severity: 'critical'
 target_match:
 severity: 'warning'
 equal: ['alertname', 'dev', 'instance']

5、验证

在方案中Prometheus所监控的实例中，redis和windows-node-002没有正常启动，因此根据上述的告警规则，应该会将这些信息发送给被告警者的邮箱。

在被告警者的邮箱中，接收的告警信息如下。

 

作者简介：

本文版权归（微博：ik8s）拥有者所有。

咨询合作：微博：ik8s

二、工具包管理的痛点——缺乏稳定性

三、解决方案——使用JFrog Artifactory的远程仓库

四、示例一——Chocolatey

五、示例二——Homebrew

六、示例三——Yum

七、示例四——Docker

八、总结

1、安装和配置rabbitmq-exporter

1.1 使用helm安装rabbitmq-exporter

这里的rabbitmq-exporter通过helm在Kubernetes中进行安装，这里需要通过rabbitmq.url，rabbitmq.user和rabbitmq.password，设置正确的rabbitmq的url地址和用户/密码。

$ helm install prom-rabbit stable/prometheus-rabbitmq-exporter --set "rabbitmq.url=http://rabbit-service:15672" 
/ --set "rabbitmq.user=user" --s set "rabbitmq.password=bitnami" --namespace=kube-public

rabbitmq-exporter具体配置信息请参考下表：

Parameter	Description	Default
replicaCount	desired number of prometheus-rabbitmq-exporter pods	1
image.repository	prometheus-rabbitmq-exporter image repository	kbudde/rabbitmq-exporter
image.tag	prometheus-rabbitmq-exporter image tag	v0.29.0
image.pullPolicy	image pull policy	IfNotPresent
service.type	desired service type	ClusterIP
service.internalport	service listening port	9419
service.externalPort	public service port	9419
resources	cpu/memory resource requests/limits	{}
loglevel	exporter log level	{}
rabbitmq.url	rabbitmq management url	http://myrabbit:15672
rabbitmq.user	rabbitmq user login	guest
rabbitmq.password	rabbitmq password login	guest
rabbitmq.existingPasswordSecret	existing secret name containing password key	~
rabbitmq.capabilities	comma-separated list of capabilities supported by the RabbitMQ server	bert,no_sort
rabbitmq.include_queues	regex queue filter. just matching names are exported	.*
rabbitmq.skip_queues	regex, matching queue names are not exported	^$
rabbitmq.include_vhost	regex vhost filter. Only queues in matching vhosts are exported	.*
rabbitmq.skip_vhost	regex, matching vhost names are not exported. First performs include_vhost, then skip_vhost	^$
rabbitmq.skip_verify	true/0 will ignore certificate errors of the management plugin	false
rabbitmq.exporters	List of enabled modules. Just “connections” is not enabled by default	exchange,node,overview,queue
rabbitmq.output_format	Log ouput format. TTY and JSON are suported	TTY
rabbitmq.timeout	timeout in seconds for retrieving data from management plugin	30
rabbitmq.max_queues	max number of queues before we drop metrics (disabled if set to 0)	0
annotations	pod annotations for easier discovery	{}
prometheus.monitor.enabled	Set this to true to create ServiceMonitor for Prometheus operator	false
prometheus.monitor.additionalLabels	Additional labels that can be used so ServiceMonitor will be discovered by Prometheus	{}
prometheus.monitor.interval	Interval at which Prometheus Operator scrapes exporter	15s
prometheus.monitor.namespace	Selector to select which namespaces the Endpoints objects are discovered from.	[]

1.2 查看rabbitmq指标数据

在浏览器中访问rabbitmq-exporter，能够看到所要监控的指标。

 

2、Prometheus监控

2.1 配置Prometheus

在Prometheus的配置文件（Prometheus.yaml）中，添加红色字体部分的内容。

global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
alertmanagers:
– static_configs:
– targets:
# – alertmanager:9093

# Load rules once and periodically evaluate them according to the global ‘evaluation_interval’.
rule_files:
# – “first_rules.yml”
# – “second_rules.yml”

# A scrape configuration containing exactly one endpoint to scrape:
# Here it’s Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
– job_name: ‘prometheus’

# metrics_path defaults to ‘/metrics’
# scheme defaults to ‘http’.

static_configs:
– targets: [‘localhost:9090’]

# 配置从redis-exporter中获取数据，目标地址为：10.0.32.148:9182

 – job_name: ‘rabbit’
static_configs:
– targets: [‘prom-rabbit-prometheus-rabbitmq-exporter:9419’]

2.2 配置验证

在浏览器的地址栏访问http://{prometheus}/targets，将会看到新配置的rabbitmq。

 

3 Grafana监控

3.1 配置Windows监控dashboard

下载rabbitmq-exporter的dashboard（rabbitmq-monitoring_rev4.json），下载地址：https://grafana.com/grafana/dashboards/4279

 

在grafana中导入dashboard：rabbitmq-monitoring_rev4.json。

 

导入后，通过此dashborad，管理员就可以监控rabbitmq的运行状态、内存、磁盘空间、消息队列和消息状态等指标。

 

作者简介：

季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。微博：ik8s

通过Portworx云原生存储，在Amazon EKS里运行高可用SQL Server容器

在本文我们将分析，如何使用Amazon Elastic Container Service for Kubernetes (Amazon EKS, https://amazonaws-china.com/eks/)，来在容器中部署Microsoft SQL Server。文中讨论的方式和与原理，也适用于其他需要高可用和持久性、并符合可复用的DevOps方式的有状态应用。例如运行MongoDB、Apache Cassandra、MySQL、或者大数据处理等。

首先能够被支持在容器中运行的是SQL Server 2017版本。我们可以在Linux容器中，使用Kubernetes (https://amazonaws-china.com/kubernetes/)来运行SQL Server生产负载。

Microsoft SQL Server是被广泛使用的数据库。SQL Server提供一系列很不错的功能，也有很不错的开发者社区。但是它需要比较多的运维，也比开源的或者云端的数据库成本要更高。很多为了降低成本的用户会转向开源方案来降低软件授权的成本。另一些用户会迁移工作负载到关系数据库管理系统（RDBMS）服务里，比如Amazon RDS for Microsoft SQL Server或者Amazon Aurora。

但也有许多情况，用户无法离开SQL Server。这有很多可能的原因，比如需要重新部署和开发的成本，以及需要配置具备相关技能的开发工程师和运维工程师资源的成本等。用户可能无法使用云服务，可能是软件授权和支持的问题，或者一些技术问题。

在这样的情况下，可以通过把SQL Server数据库部署到Amazon Elastic Compute Cloud (Amazon EC2, https://amazonaws-china.com/ec2/)实例上，来使用云服务。这种方式保持了需要满足特定需要的灵活性，也提供了云的各种好处。这些好处包括对于物理硬件层的抽象，以及按需付费的模式，以及其他的云端服务能力。虽然这种方式比本地部署SQL Server要更有优势，但管理额外的数据库实例的管理成本仍然有可提升的空间。

使用Kubernetes来运行SQL Server会有更多优势：

• 简化：在容器中部署和运维SQL Server会很简单和快捷，比起传统的部署模式会大幅降低工作量。这是因为部署不需要安装，而是通过上载新的镜像来完成。容器提供了一个可以任何环境运行的抽象层。
• 更优化的资源使用：容器化的SQL Server提供了高密度，允许内部负载共享一个通用的资源池（内存、CPU、存储）。因此减少了闲置的资源，增加了基础架构资源的利用率。
• 降低软件授权的成本：在容器中运行SQL Server的一些场景，不论是高密度还是低密度，都会降低软件授权的成本。我们会在本文后面详细介绍软件授权的成本。

容器服务

目前，AWS里有四种容器服务：

• Amazon      Elastic Container Service (Amazon ECS，https://amazonaws-china.com/ecs/)：一个高度可扩展的，高性能的调度服务，与AWS的多项服务原生集成。
• Amazon Elastic Container Service for Kubernetes (Amazon EKS)：一个AWS提供的管理服务，可以方便的使用Kubernetes部署、管理和扩展容器应用。
• AWS      Fargate (https://amazonaws-china.com/fargate/)：一个Amazon ECS的计算引擎，可以帮助用户在不需要管理服务器/集群的情况下，来运行容器。
• Amazon Elastic Container Registry (Amazon ECR，https://amazonaws-china.com/ecr/)：一个完整的被管理的Docker容器注册表，便于用户来存储、管理和部署Docker容器镜像。

在AWS上作架构的一个重要原则是 Multi-AZ部署，来产生高可用的和高性能的负载。你可以直接使用Amazon Elastic Block Storage (Amazon EBS, https://amazonaws-china.com/ebs/) 卷作为SQL Server容器的存储解决方案，但这会限制这些容器只能在单一的可用区域内。Portworx可以用来解决这个问题。

Portworx是AWS全球的合作伙伴，也是微软的高可用和容灾方案合作伙伴。Portworx使得SQL Server能够以高可用的方式，跨多个AWS可用区域，作为EKS集群来运行。Portworx也可以配置成跨越AWS Auto Scaling Groups的高可用。当使用SQL Server实例的存储层的时候，这些功能确保了存储的可用性。存储的可用性是保证容器化SQL Sever实例高可用性所必须的。

这篇文章介绍了，如何使用Amazon EKS和Portworx云原生存储（基于Amazon EBS 卷）来在生产环境中运行SQL Server负载。我们也提供了一份样例脚本( https://github.com/awslabs/aws-eks-portworx-sql)  ，来自动地在几分钟内完成SQL Server实例的部署过程。

在容器中运行SQL Server的好处

使用容器最大的好处是简单和有效。不需要安装SQL Server或者配置容错集群。使用简单的命令就可以部署SQL Server容器，然后Kubernetes会提供SQL Server部署的高可用。在一些情况下，Kubernetes中部署的SQL Server的容器实例，可用性甚至高于那些部署在容错集群上的。后面“高可用性”部分我们会介绍更多细节。

在容器中运行SQL Server的主要好处来自于高密度部署和资源共享。容器和虚拟机（VMs）的根本性的不同是：在运行过程中，与虚拟机不同，容器并不是被限定到一系列固定的资源上的。一个共享的资源池经常被一组容器在同一个主机上共享来使用。这使得容器可以随时调整使用更多或者更少的资源。只要资源的总消耗不高于总资源池的资源容量，所有的容器都能有足够的资源来运行。

如图中所示，一个按照自身配置满负荷资源运行的VM，无法在使用主机上闲余的资源。在这个例子中，资源池有两台物理主机，包括8个CPU核。尽管有3个CPU核仍然闲余未被使用，VM4和VM7仍然在自身满资源的状态下运行，而无法扩展使用闲余的资源。

让我们来看一下能够更有效利用资源的另一种方式。假设存在一种情况，你不需要担心物理主机资源的数量。你只需部署一个满资源的VM来运行一组应用，比如一些SQL Server实例。假设你可以让你的应用共享所有资源，并且确保互相之间没有冲突。图右侧的部分就是这样的解决方案：使用Amazon EC2实例上的容器服务。

使用这种解决方案。没有容器存在资源限制，总体的CPU核资源从8个减少到了6个。对于内存资源来说也是一样的。容器化，可以增加底层架构的使用效率和有效性。这对于运行SQL Server这样的有峰值使用量的应用来说尤其合适。

另一个在容器中运行SQL Server的好处是可以减少软件授权的成本。SQL Server是一个商业产品，使用授权的限制会影响我们从技术角度的决策，或者可能大幅推高我们的商业成本。微软授权SQL Server在容器中使用的方式，会很大程度上缓解这些问题。在后续“SQL Server容器软件授权”部分有更多的细节。

Amazon EKS架构上的SQL Server

Kubernetes是一个开源软件，可以用来部署和管理可扩展的容器化应用。它是一个中心化管理的分布式系统，用来运行和调度容器。

当你手边已经有一个Kubernetes集群，使用和部署应用还是比较直接的。但是部署和运维一个Kubernetes集群本身还是比较复杂的。

Amazon EKS把复杂的Kubernetes集群的进行抽象。它提供一个完整的受管理的Kubernetes，用户可以调用AWS API进行部署和管理。作为响应，用户会收到一个上游Kubernetes api-server端点，这个端点允许用户连接到新的Kubernetes集群并使用。

SQL Server在每一个Pod (一组总是一起运行的容器)中，被部署为一个单独的容器。多个SQL Server的实例可以被部署为多个Pods。Kubernetes调度这些位于集群的节点上的Pods，确保有足够的资源来运行它们。

为了在Kubernetes上运行SQL Server，你需要创建一个Kubernetes部署。这个部署创建了一个属于该部署且可以被管理的复制集（ReplicaSet）。这个ReplicaSet确保包含一个单独SQL Server容器的一个单独的Pod，可以在集群上运行。当然，你也可以在同一个集群上部署SQL Server的多个实例来达到高密度。

存储的使用也进行了抽象化。对Kubernetes来说，持久卷（PV）是一个封装了存储解决方案实施细节的对象。这可能是Amazon EBS卷，一个网络五年间系统（NFS）共享，或者其他解决方案。PV的生命周期跟使用它的Pod的生命周期互相独立不相干。

要使用PV，另一个对象 – 持久卷声明（PVC, Persistent Volume Claim）需要被创建。PVC是一个使用请求，用来请求使用定义了大小和访问模式（读/写）的存储。一个PVC也可以定义存储类（Storage Class）的值。存储类是另一类抽象，允许用户定义存储解决方案的一些参数，比如延迟（latency）和IOPS。

管理员需要定义一个存储类，例如AWS标准目的GP2 EBS卷，或者Portworx高(中) I/O卷。管理员然后可以基于这个存储类来创建PV，或者允许用户基于PVCs来动态的创建PV。而后应用可以Include一个PVC，把PV分配给某个特定的pod。为了让这个过程更加简单，你可以定义一个默认的存储类。例如，假设一个Amazon EBS标准目的SSD （gp2）卷，被定义成Kubernetes集群上的默认存储类，即使一个PVC没有Include某一个特定的存储类注解，Kubernetes将会自动注解它到AWS GP2 EBS存储类上。

存储的选择

存储是SQL Server部署中的一个关键部分。在AWS上部署SQL Server最常用的存储方式是使用EBS卷。在Kubernetes集群中有两种存储类可以直接用来使用EBS卷。

• Aws-gp2 (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 提供了一个平衡成本和性能的解决方案。
• Aws-io1 (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)，适用于需要稳定的IOPS和通道速度的生产环境负载。

你可以直接在EBS卷上存储SQL Server文件。然而，在许多情况下，一个单独的EBS卷并不能满足要求。例如，你也许需要在Multi – AZ架构下的高可用性，需要超出单独EBS卷限制的存储容量，或者需要单独卷无法达到的IOPS和通道速度。你可以尝试使用SQL Server Always On可用性组来解决高可用性问题，但是它无法解决存储容量、IOPS、和通道速度问题。同时针对SQL Server容器的Always On可用性组功能，目前也仅在SQL Server 2019是Preview发布。

你可以满足所有这些要求，包括高可用性、IOPS和通道速度，通过把几个EBS卷合并成存储池，在每一个EC2实例里Striping卷，并且把存储池延展到不同可用性区域的多个实例里。你可以部署一个独立的存储集群，并且通过NFS存储类在Kubernetes集群中使用该存储集群。但这些操作会增加一些管理复杂度。

Portworx云原生存储

Portworx是一个存储集群解决方案，可以在Kubernetes集群中服务应用和部署。Portworx是部署在Kubernetes之上的。Portworx使用Kubernetes来抽象化所有复杂的管理存储集群的操作。Portworx提供一个简单的存储类，可以被Kubernetes集群里的所有的有状态应用来使用。

在AWS里，Portworx通过对附加在Kubernetes集群（EC2实例）上的Worker Node上的EBS卷进行声明，来提供存储类。Portworx会把所有卷放进一个抽象的存储池里，然后从存储池里创建逻辑卷。当SQL Server的应用创建一个包括Portworx存储类的PVC，并且限定卷大小，一个包括具体大小的Portworx PV就被分配给了应用。

Portworx可以创建快照，称为3DSnaps。通过这个功能，你可以在SQL Server不停机的情况下，或者把SQL Server调成 read-only模式的情况下，来创建SQL Server卷的连续快照。Portworx的另一个功能是可以导入已有的EBS卷到Portworx逻辑集群卷里。这使得负载的迁移变得很容易。通过Portworx，集群可以变得密度很高，意味着你可以在一个主机上运行更多的容器。针对Kubernetes的一般性建议是每个VM/100个Pods。Portworx有一些客户甚至可以在每个主机上运行200~300个Pod (https://portworx.com/architects-corner-aurea-beyond-limits-amazon-ebs-run-200-kubernetes-stateful-pods-per-host/)。

Portworx在EBS卷之上，使用自己最佳颗粒度的快照层。

Portworx快照的创建和存储都是实时的。这是因为Portworx的快照是re-direct-on-write快照，实际上，Portworx可以通过书签方式（bookmark）即时地创建一个卷的实时快照。因为实际上的存储块并没有被copy，不论作多少次快照，都没有由于写入带来的资源使用。你可以创建一个每15分钟一次的快照组，而不影响到任何使用性能。快照可以跨多个EBS卷，集群，并且以应用一致持续的状态。

Portworx也支持重新定义虚拟卷的尺寸。你可以使用这个功能，结合EBS弹性卷，动态的来扩大或者缩小存储，来避免由于过度部署带来的额外成本损失。Portworx快照并不消耗额外的空间，这是因为存储方式是redirect-on-write，包括一个B-tree–based的文件系统，这样Portworx可以保持追踪同一个块的不同版本的数据。因此，这些快照非常节省空间。

你可以使用Portworx云快照策略来自动上载所有的快照到Amazon Simple Storage Service (S3, https://amazonaws-china.com/s3/)，并且删除本地的快照。这个功能帮助防止本地不断增加的快照来消耗EBS卷空间。Portworx也有一个本地快照保留策略，来帮助在本地保存一些特定的快照。这个策略可以基于每个卷，也可以在卷被创建或者卷被更新的时候动态的来配置。Amazon S3是一个对象存储服务，提供99.999999999百分比的可用性。被上载到S3的Portworx快照，包括实际的存储块，而不仅仅是书签。因此它提供了预防数据丢失的另一个保护层。

对本地的快照来说，恢复操作也是即时的，对于cloudsnaps (https://docs.portworx.com/cloud/backups.html) 来说，恢复操作也几乎是即时的，因为Portworx仅仅在Amazon S3中存储快照的不同部分。

关于性能和延迟，Portworx逻辑卷被每个Pod在本地访问。在后台，Portworx把block复制到其他可用性区域的其他worker node上。这样，当pod意外恢复到其他可用性区域后，可以快速的重新访问本地数据，继续运行。

Portworx有客户运行大规模数据库比如Cassandra和Elasticsearch (https://portworx.com/ge-mesosphere-dcos-portworx/)，在AWS上成功运行上百T的数据。这些客户认可在EBS上运行Portworx带来的成本节省收益。需要了解更多Portworx的功能，可以访问Portworx的网站 (https://portworx.com/products/features/)。

以上我们解释了，你可以结合使用Amazon EKS和Portworx存储，作为一个运行SQL Server的可靠的并且灵活的解决方案。接下来，我们将描述把SQL Server部署到Amazon EKS上的具体步骤。你可以按照下面的说明，在自己的环境里快速部署并验证解决方案。

一些前置条件

本文描述的解决方案基于PowerShell脚本。可以是Windows PowerShell或者PowerShell Core。如果你希望在Windows 10或者Windows Server 2016来运行脚本，你可以使用自带的Windows PowerShell。你也可以在MacBook或者Linux机器上来运行这些脚本。首先你需要在你的目标设备上安装PowerShell Core (https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell?view=powershell-6)。另一种选择，Mac的用户可以使用ReadMe文件里的说明来部署一个本地的Docker容器，来包括所有这些前置条件。

这个脚本会调用在AWS Tools for PowerShell ( https://amazonaws-china.com/powershell/) 里的PowerShell cmdlets 。确保你的机器上安装了最新版本的 AWS Tools for Windows PowerShell (https://www.powershellgallery.com/packages/AWSPowerShell/3.3.343.0)，或者AWS Tools for PowerShell Core （https://www.powershellgallery.com/packages/AWSPowerShell.NetCore/3.3.343.0）

这些脚本有时候需要AWS 命令行界面（AWS CLI）工具来调用Amazon EKS APIs。确保你安装了最新版本的AWS CLI (https://docs.aws.amazon.com/cli/latest/userguide/installing.html)。

最后，你需要必须的AWS账户的权限来运行脚本。这包括运行AWS CloudFormation模板、创建虚拟私有云（VPCs）、子网、安全组、以及EC2实例，并且部署和访问EKS集群。你可以使用一个IAM用户（在你的计算机上保存一对可长期使用的Keys）。这种情况下，你需要允许AWS在PowerShell 和 AWS CLI上使用这些Keys。

另一种方式，你可以使用IAM角色，它具有被分配给EC2实例的所有必须的权限，可以用来运行脚本。这个方式，不需要额外的配置，AWS PowerSheel Tool和AWS CLI会从EC2实例的元数据那里自动获得临时的身份信息。

作为可选，这个包里面包括一个Docker文件，它会直接创建脚本，以及直接创建以上所有的必须的部分（AWS CLI、AWS cmdlets这些）到microsoft/powershell Docker镜像里。这样你就可以直接使用docker run来setup环境，不论是在MacOS、Linux或者Windows上，只要你安装了Docker。

在Amazon EKS上部署SQL Server

你可以通过运行被include的脚本，传递必须的参数，来部署SQL Server。脚本包括许多参数，最重要的一些参数已经有默认的值，来帮助不熟悉的用户。反复运行同样参数的脚本也是安全的，它会检查底层的资源是不是已经存在，如果已经存在，会复用它们。

以下是脚本运行的所有步骤：

1.   首先，它为Amazon EKS创建一个IAM服务角色。这个角色会允许AWS来创建必要的资源。

2.   你需要一个VPC来运行你的集群。脚本会接收一个AWS CloudFormation VPC Stack的名称作为一个参数。如果Stack已经存在，它就会复用这个Stack，否则，它就通过AWS提供的模板创建一个新的Stack。Stack包括VPC、子网和安全组，这些必须的内容来运行集群。

3.   你使用一个客户端工具kubectl来配置和与Kubernetes交互。脚本会下载AWS版本的Kubectl，并且安装到你的本地计算机。

4.   当你使用Kubectl来查询Amazon EKS，你正在使用的AWS PowerShell工具的身份信息也会被传递给Amazon EKS。这个任务是被另一个工具aws-iam-authenticator来完成的，这个工具也会被脚本下载并安装。

5.   它创建了一个新的EKS集群。这个EKS集群包括被管理的一组3个 Master节点，分布在3个AWS可用区域上。

6.   它配置Kubectl来连接到上面步骤创建的EKS集群上。

7.   它创建了新的EC2实例，并且配置它们加入到EKS集群和Worker nodes上。

8.   它创建了一个Etcd集群，让Portworx与之通信。

9.   它然后下载一个DaemonSet规格参数，并且应用到EKS集群上。这就自动安装了Portworx云原生存储 – 含有GP2和IO1 EBS卷，供用户选择其中一种或者全部。

10.  它为Portworx卷创建了一个存储类，其中EKS集群内的复制因子数值为3。这样你就可以在主机发生错误的时候，维持SQL Server集群的高可用。甚至Kubernetes可以把你的SQL Server Pod调度到另一个可用性区域。

11.  它在EKS集群内，为gp2 EBS卷创建了一个存储类。

12.  它在EKS集群内创建了一个新的Persistent Volume声明（PVC）。PVC允许Portworx来部署由Amazon EBS卷支持的持久卷（PV）。

13.  它提示你输入SQL Server SA用户的密码。输入符合SQL Server密码要求的强度较高的密码。脚本会把密码作为Secret保存到EKS集群里。

14.  然后它会创建SQL Server的部署。部署包括一个复制集，它会按顺序创建Kubernetes的Pods。Pod是由一个运行SQL Server的单独容器组成。PVC卷被Mount到了这个容器里。SA的密码也被使用。

15.  最后，它输出端点的名称，在连接字符串里使用来连接到SQL Server实例里。

运行脚本会部署EKS集群，以及一个单独的SQL Server实例。你也可以在同一个EKS集群上部署另一个SQL Server实例，只需要再次运行同一个脚本即可。然后为appName参数传递一个不同的名称。

高可用性

脚本部署SQL Server使用Multi-AZ Kubernetes集群，和一个有Portworx卷支持的存储类（Storage Class）。由于Portworx在SQL Server容器里保护和复制数据，部署针对下列情况具备高可用：

• 容器错误
• Pod错误
• EC2实例错误
• EC2主机错误
• EBS磁盘错误
• EC2网络分区
• AWS有效性区域错误

如果一个容器或者Pod错误，Kubernetes会立即调度另一个容器或者Pod。甚至Kubernetes把Pod调度到了另一个可用性区域。你也不会有数据损失，因为Portworx自动的在可用性区域之间复制数据。

在前面的部分，我们注意到Portworx复制因子的数值被设定成了3。这意味着除了我们的主PV之外，Portworx会在集群上的其他地方一直保持两个额外的PV副本。因为Amazon EBS卷只在一个单独的可用性区域保持高可用性，默认情况下，Portworx把这些复制扩展到多个可用性区域里。相对于本地部署时：通常一个SQL Server错误恢复集群实例（FCI）是部署在同一个数据中心里的，很大的进步就是Kubernetes和Portworx集群是分布在多个可用性区域里的。因此，可用性更高。

在Portworx存储集群上的Kubernetes里运行SQL Server容器，类似在跨多个可用性区域的Storage Spaces Direct 集群（https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview）上运行SQL Server Always On FCI。这样Recovery Point Objective (RPO)是零，而且Recovery Time Objective (RTO，https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sqlallproducts-allversions) 小于10分钟，这样可以应对可能出现的可用性区域的错误，达到极高的可用性。区别是在EKS里运行容器，比起在Windows Server容错恢复集群上配置和维护SQL Server要更加容易。

如果你运行SQL Server标准版，你也可以通过使用容器和Amazon EKS获得相比于传统Windows部署的更高的可用性。这是因为SQL Server标准版FCI只能授权最多两个节点的使用。（一个第二节点）。然而，容器可以被部署到含有任何数量节点的集群上。SQL Server Always On FCI的企业版可以超过两个节点。取决于你的软件授权协议，你可能要为每个额外的实例购买新的授权。这不是容器的使用方式。你可以只支付一个容器的费用，不论你在集群上有多少standby的实例。

也可以把SQL Server容器和Always On可用性组（SQL Server 2019 preview版本）一起部署。这样的配置类似部署Always On可用性组（每个节点自己就是一个Always On FCI集群）。这样，容器就会摆脱一些Always On可用性组和FCI的限制。例如，这些限制包括从一个可用性组的节点自动容错恢复到另一个节点，和为每一个节点设置FCI的复杂操作。

SQL Server容器软件授权

基于SQL Server 2017软件授权说明：“SQL Server 2017使用授权给虚拟机和容器，为客户的部署提供灵活性。有两种可选的给虚拟机和容器的授权方式，为每个虚拟机和容器授权，以及为高度虚拟化或高密度容器环境的最大密度授权（每物理主机授权）”。

有机会通过把SQL Server负载容器化来降低软件授权成本。你可以基于不同的实际场景，使用每容器授权的模式，或者使用每物理主机授权的模式（高密度），来降低软件授权的数量。

如果你有一些应用在EC2实例上运行，并且希望在同一个主机上运行应用的同时，也运行SQL Server，你可以使用每容器授权的模式。如果没有容器，是在虚拟机上直接运行SQL Server，包括EC2实例，你就需要为VM包括的所有vCPU购买授权，不论SQL Server到底使用了多少vCPU资源。然而，如果你是在VM之上的容器里运行SQL Server，你只需要为容器访问到的vCPU数量购买授权。你可以仅仅为能访问到的核数量购买授权，这样你最小的情况可以只够买4核的授权，或者6核，8核这样，视情况而定。

如果你的SQL Server实例存在突发峰值的使用情况，你可以在高密度环境的容器内运行它们。这种情况下，你可以选择每物理机授权的模式。只要所有的物理核资源得到了正确的授权，就会允许你运行物理核资源之上的不限数量的容器，以及不限数量的vCPU。

在上面的图里，有12个vCPU核和20个容器。但因为这些容器都运行在一个6核的物理机器上，只需要为这6个物理机的核授权。这对那些已经在本地物理环境里过度部署了SQL Server虚拟机的情况非常有用。EC2实例有一个固定的hyperthreading比例：2vCPU对应一个物理主机核。这样迁移过度部署的负载（3:1，4:1，5:1或者更高）到EC2实例里会带来更高的成本问题。容器化解决成本问题，相应也会带来更好的收益。

Portworx授权

Portworx支持高密度容器环境的授权模式。Kubernetes本身推荐一个节点最多不要超过100个pod（https://kubernetes.io/docs/setup/cluster-large/）。这样理论上，你可以在每个EC2实例里运行不超过100个SQL Server Pods，这样可以大量节省SQL Server授权。Portworx针对每个EC2实例只需要一个授权，不论运行多少容器，或者消耗多少存储。这样对于集群，你并不是简单的用一个授权来换另外一个，实际上，每个主机运行的SQL Server数量越多，你的平均授权成本越低。Portworx支持每个集群数千节点，以及支持每个节点数百个有状态容器（https://portworx.com/architects-corner-aurea-beyond-limits-amazon-ebs-run-200-kubernetes-stateful-pods-per-host/）。

什么情况下不适合使用SQL Server容器

在现有版本的功能上，并不是所有的SQL Server都能够被容器化。目前仅仅只有SQL Server2017支持容器。2017之前的版本都不能支持容器。但SQL Server本身是兼容SQL Server 2008之后的版本的，这意味着你可以导入从SQL Server 2008（或之后版本）中创建的数据库到SQL Server2017实例里（包括在容器里运行的SQL Server 2017里），用兼容模式来运行即可。

虽然SQL Server on Linux支持与Microsoft Active Directory的集成，SQL Server容器目前不支持Active Directory集成。

SQL Server一个经常使用的功能是horizontal read-scaling，它在Always on可用性组里。这个功能对容器目前只是Preview版本，不能用在生产环境。

另一个云带来的可能的好处是License Included services模式。对于许多商业来说，管理已购买的授权和实际软件授权使用是非常复杂的工作。经常会不一致，导致客户要么为未使用的软件授权多花钱，要么合规地软件授权不足。SQL Server容器支持Bring Your Own License (BYOL)模式，因此在决策前好好考虑下授权的问题。

也有其他一些功能目前还不能使用，比如Distributed Transaction Coordinator (DTC)和custom CLR user types。如果你的SQL Server负载是一个比较静态平稳的资源消耗模式，也许传统的部署模式更加适用。

结论

在本篇文章中，我们讨论了为什么要考虑在容器中使用SQL Server和Portworx，并且讨论了需要考虑的各个方面。

这样的方式有下面的好处：

• 简单，而且会帮助你降低一些管理的复杂度。
• 可以通过释放闲置的资源给需要的负载，来增加应用的性能。
• 可以增加数据保护，以及部署的容灾恢复。
• 可以减少基础架构的成本。
• 可以减少SQL Server软件授权的成本。

这篇文章演示了在Amazon EKS上与Portworx一起部署SQL Server是比较简单的。你可以部署基础架构和EKS集群，并且通过使用一个简单的脚本来调用AWS API，从而来运行SQL Server容器。基于你的情况，你可以使用两种存储方案：

• 使用单独的EBS卷作为一个PVC，在一个单一的高可用区域里提供高可用性，最少的存储成本。
• 使用一个集群化的存储解决方案Portworx来跨多个可用性区域，提供支持可用性区域错误恢复级别的高可用。

1、安装和配置wmi-exporter

1.1 使用helm安装redis-exporter

通过下面的连接：https://github.com/martinlindhe/wmi_exporter/releases/download/v0.10.2/wmi_exporter-0.10.2-amd64.exe

下载wmi_exporter-0.10.2-amd64.exe，并将名称改为wmi_exporter.exe。在本文中，将wmi_exporter.exe放置在”d:\”目录下，通过执行下面的命名将wmi_exporter.exe注册成windows系统服务。

sc create wmi_exporter binpath= "d:\wmi_exporter.exe" start= auto

1.2 查看Windows操作系统的指标数据

在浏览器中访问：http://{ip}:9182，能够看到所要监控的指标。

2、Prometheus监控

2.1 配置Prometheus

在Prometheus的配置文件（Prometheus.yaml）中，添加红色字体部分的内容。

global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
alertmanagers:
– static_configs:
– targets:
# – alertmanager:9093

# Load rules once and periodically evaluate them according to the global ‘evaluation_interval’.
rule_files:
# – “first_rules.yml”
# – “second_rules.yml”

# A scrape configuration containing exactly one endpoint to scrape:
# Here it’s Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
– job_name: ‘prometheus’

# metrics_path defaults to ‘/metrics’
# scheme defaults to ‘http’.

static_configs:
– targets: [‘localhost:9090’]

# 配置从redis-exporter中获取数据，目标地址为：10.0.32.148:9182

– job_name: ‘windows-node-001’
static_configs:
– targets: [‘10.0.32.148:9182’]

2.2 配置验证

在浏览器的地址栏访问http://{prometheus}/targets，将会看到新配置的redis。

3 Grafana监控

3.1 配置Windows监控dashboard

下载wmi-exporter的dashboard（windows-host-metrics_rev1.json），下载地址：https://grafana.com/api/dashboards/10171/revisions/1/download/

在grafana中导入dashboard：windows-host-metrics_rev1.json。

导入后，通过此dashborad，管理员就可以监控Windows操作系统的CPU、内存、磁盘空间、网络等性能指标。

 

作者简介：

季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。微博：ik8s

我们很高兴宣布Kubernetes 1.18的交付，这是我们2020年的第一版！Kubernetes 1.18包含38个增强功能：其中15个功能已趋于稳定，beta版本中有11个，alpha版本中有12个。

Kubernetes 1.18是一个“完美”的版本。为了改善用户体验，我们在beta和 stable 功能改进方面进行了大量工作：增加新的开发和新功能。对alpha，beta和 stable 版进行几乎一样多的增强是一项伟大的成就。这说明，社区在提高Kubernetes的可靠性以及继续扩展其现有功能方面所做的巨大努力。

Kubernetes 1.18主要更新内容

Kubernetes拓扑管理器（Topology Manager ） 升级到Beta版 ！

拓扑管理器功能 是1.18版中Kubernetes的beta版本功能，它可以使CPU和设备（如SR-IOV VFs）实现NUMA，这将使你的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前，CPU和设备管理器会做出彼此独立的资源分配决策，那么可能会导致在多套接字（ multi-socket ）系统上分配不良，从而导致关键型应用程序的性能下降。

Serverside Apply引入Beta 2版本

Server-side Apply 在1.16中被升级为Beta，在1.18中引入Beta 2版本。这个新版本将跟踪和管理所有新Kubernetes对象的字段更改，从而使你知道更改了什么资源以及何时更改的。

使用IngressClass扩展Ingress，并用IngressClass替换不推荐使用的注释

在Kubernetes 1.18中，Ingress有两个重要的补充：一个新pathType字段和一个新IngressClass资源。该pathType字段允许指定路径应如何匹配。除了默认ImplementationSpecific类型外，还有new Exact和Prefixpath类型。

该IngressClass资源用于描述Kubernetes集群中的Ingress类型。入口可以通过ingressClassName在入口上使用新字段来指定与它们关联的类。这个新资源和字段替换了不建议使用的kubernetes.io/ingress.class注释。

SIG-CLI引入kubectl debug命令

SIG-CLI一直在争论是否需要调试实用程序。随着临时容器(ephemeral containers)的发展，开发人员越来越需要更多类似kubectl exec的命令。该kubectl debug命令的添加（它是Alpha版本，但欢迎你提供反馈），使开发人员可以轻松地在集群中调试其Pod。我们认为这种增加是无价的。此命令允许创建一个临时容器，该容器在要检查的Pod旁边运行，并且还附加到控制台以进行交互式故障排除。

Alpha版本引入Windows CSI

随着Kubernetes 1.18的发布，用于Windows的CSI代理的Alpha版本也已发布。CSI代理使非特权（预先批准）的容器能够在Windows上执行特权存储操作。现在，可以利用CSI代理在Windows中支持CSI驱动程序。

Kubernetes 1.18其他更新

稳定特性💯

• 污点驱逐
• kubectl diff
• CSI块存储支持
• API Server 干运行
• 在CSI中传递Pod信息
• 支持树形vSphere Cloud Provider
• 为Windows工作负载支持GMSA
• 跳过非附加CSI卷
• PVC克隆
• 将kubectl软件包代码移至暂存
• Windows的RunAsUserName
• 适用于服务和端点的AppProtocol
• 扩展大页面功能(Hugepage Feature)
• 客户端签名重构，以标准化选项和上下文处理
• 节点本地DNS缓存

主要变化

• EndpointSlice API
• 将kubectl软件包代码移至暂存
• CertificateSigningRequest API
• 扩展大页面功能
• 客户端签名重构，以标准化选项和上下文处理

发行说明

在我们的发行说明中查看Kubernetes 1.18发行版的完整详细信息。

可用性

Kubernetes 1.18可以在GitHub上下载。如果要开始使用Kubernetes，可以看看这些互动式教学或使用 kind.运行本地Kubernetes集群。你还可以使用kubeadm轻松安装1.18 。

发布团队

通过数百名贡献了技术和非技术内容的个人的努力，使此发行成为可能。特别感谢Searchable AI网站可靠性工程师Jorge Alarcon Ochoa领导的发布团队。34位发布团队成员协调了发布的许多方面，从文档到测试，验证和功能完整性。

随着Kubernetes社区的发展，我们的发布过程很好地展示了开源软件开发中的协作。Kubernetes继续快速地获得新用户。这种增长创造了一个积极的反馈周期，其中有更多的贡献者提交了代码，从而创建了更加活跃的生态系统。到目前为止，Kubernetes已有超过40,000个人贡献者，活跃社区有3,000多人。

发布徽标

为什么选择大型强子对撞机？

LHC是世界上最大，功能最强大的粒子加速器。这是来自世界各地成千上万科学家合作的结果，所有这些都是为了促进科学的发展。以类似的方式，Kubernetes已经成为一个项目，它聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力！发行名称“ A Quarky”的意思是提醒我们，非常规的想法可以带来巨大的变化，对开放性保持开放态度将有助于我们进行创新。

关于设计师

Maru Lango是目前居住在墨西哥城的设计师。尽管她的专长是产品设计，但她还喜欢使用CSS + JS进行品牌，插图和视觉实验，并为技术和设计社区的多样性做出了贡献。你可能会在大多数社交媒体上以@marulango的身份找到她，或查看她的网站： https://www.marulango.com/

Kubernetes 用户实践亮点

• 爱立信正在使用Kubernetes和其他云原生技术来交付高要求的5G网络，从而节省多达90％的CI / CD。
• Zendesk正在使用Kubernetes 运行约70％的现有应用程序。它还构建了所有也可以在Kubernetes上运行的新应用程序，这节省了时间，提高了灵活性并提高了其应用程序开发的速度。
• 由于改用Kubernetes，LifeMiles已将基础设施支出减少了50％。它还使他们可以将其可用资源容量增加一倍。

生态系统更新

• CNCF公布了其年度调查的结果，该结果表明Kubernetes在生产中的使用量正在猛增。调查发现，有78％的受访者在生产中使用Kubernetes，而去年这一比例为58％。
• CNCF举办的“ Kubernetes简介”课程已超过100,000个注册。

项目速度

CNCF继续完善DevStats，这是一个雄心勃勃的项目，旨在可视化项目中的大量贡献。K8s DevStats展示了主要公司贡献者的贡献细目，以及一系列令人印象深刻的预配置报告，包括从各个贡献者到请求生命周期时间的所有内容。

在过去的一个季度中，有641家不同的公司和6,409多名个人为Kubernetes做出了贡献。查看DevStats，以了解有关Kubernetes项目和社区整体速度的更多信息。

活动更新

Kubecon + CloudNativeCon EU 2020推迟发布-有关最新信息，请查看Novel Coronavirus更新页面。

Kubernetes 1.18即将举行的在线讲座

将于2020年4月23日举行在线讲座，以了解Kubernetes 1.18版本的主要功能，包括 kubectl debug ，Topology Manager，Ingress to V1 graduation 和 client-go 。在此处注册： https://www.cncf.io/webinars/kubernetes-1-18/ 。

欢迎你参与其中

参与Kubernetes的最简单方法是加入符合你的兴趣的众多特殊兴趣小组（SIG）之一。你有什么想向Kubernetes社区广播的内容吗？在我们的每周社区会议上以及通过以下渠道分享你的声音。感谢你一直以来的反馈和支持。

• 在Twitter @Kubernetesio上关注我们以获取最新更新
• 加入的社群讨论讨论
• 在Slack上加入社区
• 在Stack Overflow上发布问题（或回答问题）
• 分享你的Kubernetes 故事
• 在博客上详细了解Kubernetes的情况
• 了解有关Kubernetes发布团队的更多信息

前一段时间写了使用keepalived+haproxy部署k8s高可用集群，核心思想是利用keepalived生成vip实现主备容灾，以及haproxy负载k8s-apiserver流量。k8s高可用部署：keepalived + haproxy

这种方式是自己实现了负载均衡。本文将探讨在用户已有SLB的场景下如何实现k8s高可用

SLB概念

阿里云文档中SLB（Server Load Balancer）介绍如下:

负载均衡基础架构是采用集群部署，提供四层（TCP协议和UDP协议）和七层（HTTP和HTTPS协议）的负载均衡，可实现会话同步，以消除服务器单点故障，提升冗余，保证服务的稳定性。

负载均衡作为流量转发服务，将来自客户端的请求通过负载均衡集群转发至后端服务器，后端服务器再将响应通过内网返回给负载均衡。

本文还涉及到SLB的一个关键技术限制：

在 4 层（TCP 协议）服务中，不支持添加进后端的服务器既作为 Real Server，又作为客户端向所在的 SLB 实例发送请求。因为，返回的数据包只在服务器内部转发，不经过负载均衡，所以通过配置在 SLB 后端的 服务器去访问其 VIP 是不通的。

另外对于SLB的健康检查、调度算法等最佳实践不做探讨，请查阅相关文档。文本探讨的范围仅限于架构可行性验证。

架构

1 keepalived+haproxy

 

由于4层SLB不支持后端服务访问其VIP，根据kubeadm官方安装文档：

 

 

 

 

 

 

指定vip会发生如下超时错误：

[etcd] Creating static Pod manifest for local etcd in “/etc/kubernetes/manifests”

[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory “/etc/kubernetes/manifests”. This can take up to 4m0s

[kubelet-check] Initial timeout of 40s passed.

查看kubele日志：

# sudo journalctl -u kubelet.service

k8s.io/kubernetes/pkg/kubelet/kubelet.go:442: Failed to list *v1.Service: Get https://172.16.105.26:9443/api/v1/services?limit=500&resourceVersion=0: dial tcp 172.16.105.26:9443: connect: connection refused

还记得之前说的4层负载的技术限制吗？

基于此我们出了一个比较”脏”的方案：keepalived+haproxy。安装步骤与上一篇文章一样，只是结果不同：

•  这种方式还是先启用keepalived绑定vip，此时对vip的请求属于本地访问，不会转发出去，因此不会出现访问不通的情况。
• 三台keepalived都必须是leader, 否则只有一台能绑定vip，其他两台还是加入不了
• 如何使三台都是keepalived leader? 两种方式： 1）关闭vrrp协议（阿里云默认关闭），此时keepalived backup收不到其他节点的广播信息，将自己设为leader; 2)用单播方式启动keepalived

问题：

1.  这种实现方式相当于在LB的后端又实现一次LB，但是用户请求多了一次转发, 显然不是一个令人满意的方案。

2. 这种keepalived全主模式不能应用在纯vip场景下（如openstack）。这种情况安装是没问题的，master1先绑定vip，master2,3通过vip访问apiserver时走本地流量，由于本地apiserver:6443还未启动，被haproxy负载到健康节点。这么做安装是没问题的。但是不能保证高可用。当master1 done时，子网内部访问vip还是能找到另外两台健康节点，但是子网外部访问时，路由器还是会路由到master1。

2 绑定vip方式

keepalived的解决方式其实是将vip绑定三台k8s-master，使得三台主机初始化时走本地网络，解决后端访问不了slb的问题。那么其实我们不需要在keepalived后面再加一层haproxy，使得请求多一次转发，更进一步，我们不需要keepalived来绑定vip，手动绑定就好了。

安装步骤：

2.1 init k8s-master-leader

绑定vip：

# ip addr add 172.16.105.26/32 dev eth0

查询绑定结果：

#ip a| grep eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    inet 172.16.104.54/24 brd 172.16.104.255 scope global eth0

    inet 172.16.105.26/32 scope global eth0

kubeadm-config.yaml

apiVersion: kubeadm.k8s.io/v1beta1

kind: ClusterConfiguration

kubernetesVersion: v1.14.1

imageRepository: registry.aliyuncs.com/google_containers

networking:

  podSubnet: 10.244.0.0/16

controlPlaneEndpoint: 172.16.105.26:6443

join

sudo kubeadm init –config=kubeadm-config.yaml –experimental-upload-certs

记录下日志中的join命令

2.2 join k8s-master-follower

分别将k8s-master-follower加入k8s-master-leader

 sudo kubeadm join 172.16.105.26:6443 –token c1d2cb.vx086ez76bpggqj5 \

>     –discovery-token-ca-cert-hash sha256:bc749b4e7e75f93ea9c0055d1c6e36c814b04247ca9e5bb6168ec3a27e5693bd \

>     –experimental-control-plane –certificate-key cdb31f173bf87a573217a4cd1d6e22dc1d396a4da5050e36bdec407bd2aab29d

2.3 为k8s-master-follower绑定vip

您可能注意到follower join时没有先绑定vip。原因是follower join时需要访问k8s-apiserver获取证书等信息，绑定vip直接走本地，获取失败。而此时slb健康检查认为k8s-master-leader是可以负载的，所以直接访问前端slb会负载到k8s-master-leader，可以访问k8s-apiserver。

那为什么还要为k8s-master-follower绑定vip呢？在每个k8s-master-follower请求slb时有1/3的几率负载到自身，此时访问不通。绑定vip后，每个k8s-master-follower访问slb都是访问的本机。

总结

第一篇文章讲述了只有vip，没有实际slb设备的模式下，采用keepalived+haproxy实现高可用的方式。本篇讲述了依赖云厂商SLB高可用和负载均衡时安装k8s。方案一并不完美，通过改良后形成了方案二。当然业内肯定还有很多其他的解决方案，作者才疏学浅，还没来得及一一拜读。

完成本篇的同时又接到了一个新的需要：SLB不是以vip形式提供，而是域名。域名SLB当然比IP要强，大部分云厂商负载均衡肯定不是一台设备，背后都是大规模的集群，会保证SLB服务本身的高可用。这种场景下已经不能通过绑定vip来实现，如何解决呢？敬请期待第三篇。

报名链接：https://www.bagevent.com/event/6433326

如果您是k8s的新手，此时您被安排为您的企业研究供应商支持平台，你很有可能不知所措。你会遇到一个看似永无止境的供应商列表，当然，所有的供应商或多或少都一样。

为了帮助你浏览并向供应商询问正确的问题，我们创建了此 no- BS Kubernetes 清单。清单中包括了面向未来的Kubernetes策略的所有“必备品”。

企业级Kubernetes必备

• 基础架构管理

默认情况下，Kubernetes无法配置基础架构，因此如果节点崩溃，Kubernetes将无法配置新的基础架构。Kubernetes所能做的就是在可用节点内重组Pod。但是，如果没有足够的可用基础架构资源，Kubernetes将无法保证自我修复。这里有一个小秘密；至今为止，市场上的大多数解决方案尚未管理基础架构，或者仅仅在选定的环境中进行配置。

• 自我修复的Kubernetes

几乎每个平台都有望实现自愈。但是，您需要在三个不同的层面进行自我修复：（1）基础架构：取决于上述基础架构的管理能力；（2）Kubernetes组件：这是您必须验证以确认这一点；（3）应用程序级别：默认情况下，由Kubernetes通过自我修复的容器（自愈容器）提供。对于真正可靠的应用程序，您需要在所有层上进行自我修复。

• 多集群支持和集中管理

虽然早期采用Kubernetes的方法可能包括一个或几个静态集群，但随着业务规模的增长和成熟的DevOps实践，就需要将Kubernetes集群视为牛，而不是宠物。大多数组织必须同时运行多个集群，根据需要创建和销毁它们，并为其开发团队启用自助服务。如果对每个群集分别进行管理，则此方案很快就变得难以管理。

• 多环境支持

随着云和软件变得越来越复杂，托管应用程序的位置将越来越影响系统性能。根据451 Research的调查，所有的企业中，超过一半选择混合云和多云作为他们理想的IT架构，大约63％的企业正在使用两个或多个云。这就是为什么您需要一种可在各种环境下工作的解决方案的原因。

• 多站点支持可靠性和容灾

大型企业不会在一个数据中心、区域或云中运行其关键任务应用程序。它们分布在不同的站点，以确保可靠性和容灾。在这种情况下，您的平台必须支持多站点部署，并且能够在多个站点之间协调自动故障转移和恢复过程。

• 集中记录和监控

集中日志记录和监控对于Ops和DevOps团队快速识别并修复基础架构、Kubernetes和应用程序问题至关重要。与很多零碎的视图相比，它提供了单个集成图片。趋势和相关性更容易发现，有助于尽早采取预防或纠正措施。此外，为了安全性和审计，infosec需要一些所有遥测的集中图片。

• 安全

Kubernetes本身具有强大的安全功能特点，但正在寻找可以将这些功能连接到企业系统的提供商。这不仅应包括集群和容器的安全功能（例如TLS，密钥和证书的轮换和管理，AAA和身份管理等），而且具有企业IDM（SAML，OIDC，LDAP）和Kubernetes的RBAC集成能力。

• 第2天操作的完全自动化

该解决方案应处理在集群上的所有管理任务。恢复、还原，更新、升级等等。如果不是自动化的，则需要您自己去做，这很快会让您的资源和预算紧张。

• “开放”开源

开源的主要好处是它开放且灵活，允许用户根据市场需求进行调整。但是，我们看到了一些新的“自以为是的开源​​”产品，这些产品会锁定您。虽然有些将您绑定到特定的基础结构或技术堆栈，但有些则在修改原始的开源技术。尽管后者可能是开源的，但它们特定于该供应商，并且不受社区支持。确保您的平台没有被绑定到特定的技术堆栈或基础架构，从而损害了敏捷性。

• 可配置性

尽管利用供应商支持的Kubernetes平台的整体想法是所有东西都已预先配置，但是一旦冒险进入更高级的用例，您需要能够覆盖参数。由于Kubernetes是一个复杂的多组件系统，因此配置灵活性可能会有所不同，例如，数据科学集群配置会与无状态应用程序或微服务的配置不同。根本就没有那种四海皆准的方法。确保您有权访问主节点和工作节点组件配置，包括交换机，资源请求和限制，操作系统级别的配置等。

• 命令行和API

当您的Kubernetes和与容器相关的用例成熟时，一些团队成员将更喜欢通过命令行（CLI）进行工作。CLI和API支持复杂的自动化和集成方案，包括将Kubernetes集群操作集成到CI / CD管道、扩展、平衡、故障转移和恢复方案等。

• 智能监控和警报

Kubernetes和容器化的应用程序会生成大量原始数据，您必须转换这些原始数据才能了解集群的状况。早期发现和干预对于预防灾难至关重要。如果您无法理解Kubernetes告诉您的内容，那么您就有问题了。通过合并自动智能监视和警报（不会给您充斥不重要的细节），您会从状态、错误、事件和警告等关键信息中受益，从而使您的团队拥有采取行动所需的洞察力。

• 支持多个Kubernetes版本

企业中任何有意义的Kubernetes部署都将包含多个集群和环境，无论是dev、prod、staging、QA环境，还是组织内不同部门和组或不同应用程序使用的环境和集群。希望所有的都维持相同的配置和补丁/ Kubernetes版本级别是不可行的，因此企业Kubernetes解决方案必须能够同时支持多个Kubernetes版本和配置。

• 支持Kubernetes升级和更新

Kubernetes平台由整个堆栈组成。仅Kubernetes每年就有四个主要版本。其他项目也有自己的版本。如何处理更新和升级？故障期怎么办？请注意，尽管有些供应商声称支持升级，但如果您进行更深入的研究，您会发现他们需要（有时甚至是很长时间）停机才能进行集群的重新初始化。

• 24/7支持

最后，随着您的团队开始学习Kubernetes技能，重要的是要有一家提供24/7支持和培训的供应商，以确保您的Kubernetes旅程顺利。

乐于助人

• 对初学者的用户友好型UI

友好的用户界面对刚接触Kubernetes的企业特别有利。它们通过提供方便的下拉菜单简化了大部分部署，确保几乎不可能创建故障集群。这将使您的团队组织在开始构建内部专业知识时迅速上手Kubernetes。

• 与Kubernetes“Essentials”的集成

有很多组件不是Kubernetes的一部分，但是对于Kubernetes用户实现任何有意义的目标来说都是必不可少的。其中包括组件和框架，例如容器覆盖网络提供商、入口控制器、Kubernetes自动缩放器、云原生存储系统、用于不同类型卷的持久卷供应器、GPU集成等。

显然，在迁移到基于Kubernetes的面向未来的架构时，企业需要进行多方面的考虑。不幸的是，并不是所有的企业在研究其选择方案时都完全理解他们的要求。如果您考虑一下大多数情况下很新的Kubernetes和云原生技术，这并不让人感到很意外。

无论您选择Kublr的企业级平台还是其他替代产品，我们希望该清单将帮助您浏览生态系统并找到适合您需求的平台。

 

作者：Oleg Chunikhin

原文地址：https://thenewstack.io/a-no-bs-checklist-for-kubernetes/

 

作者 | 罗松(西流)  阿里巴巴技术专家

本文整理自架构师成长系列 2 月 12 日直播课程。

关注“阿里巴巴云原生”公众号，回复 “212”，即可获取对应直播回放链接及 PPT 下载链接。

前言

随着计算机技术和 Internet 的日新月异，视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐，而在当前， 云计算平台厂商的产品线不断成熟完善， 如果想要搭建视频点播类应用，告别刀耕火种， 直接上云会扫清硬件采购、 技术等各种障碍，以阿里云为例：

这是一个非常典型的解决方案， 对象存储 OSS 可以支持海量视频存储，采集上传的视频被转码以适配各种终端，CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求， 比如鉴黄、鉴恐等。

而在视频点播解决方案中， 视频转码是最消耗计算力的一个子系统，虽然您可以使用云上专门的转码服务，但在很多情况下，您会选择自己搭建转码服务。比如：

• 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务，能否在此基础上让它有更弹性、更高的可用性？
• 您的需求只是简单的转码需求，或是一些极其轻量的需求，比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长，自己搭建成本更低；
• 各种格式的音频转换或者各种采样率自定义、音频降噪等功能；
• 您有更高级的自定义处理需求，比如视频转码完成后， 需要记录转码详情到数据库， 或者在转码完成后， 自动将热度很高的视频预热到 CDN 上， 从而缓解源站压力；
• 您有并发处理大量视频的需求；
• 您有很多超大的视频需要批量快速处理完， 比如每周五定期产生几百个 4G 以上的大视频， 但是希望当天几个小时后全部处理完;
• 自定义视频处理流程中可能会有多种操作组合， 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求，比如调整转码参数，希望新功能发布上线对在线服务无影响；
• 您的视频源文件存放在 NAS 或者 ECS 云盘上，自建服务可以直接读取源文件处理，而不需要将它们再迁移到 OSS 上。

如果您的视频处理系统有上述需求，或者您期望实现一个 弹性、高可用、低成本、免运维、灵活支持任意处理逻辑 的视频处理系统，那么本文则是您期待的最佳实践方案。

Serverless 自定义音视频处理

在介绍具体方案之前， 先介绍两款产品：

• 函数计算 ：阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，并提供日志查询、性能监控、报警等功能；
• 函数工作流：函数工作流（Function Flow，以下简称 FnF）是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序，分支，并行等方式来编排分布式任务，FnF 会按照设定好的步骤可靠地协调任务执行，跟踪每个任务的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。

免费开通函数计算，按量付费，函数计算有很大的免费额度。

免费开通函数工作流，按量付费，函数工作流有很大的免费额度。

函数计算可靠的执行任意逻辑， 逻辑可以是利用 FFmpeg 对视频任何处理操作， 也可以更新视频 meta 数据到数据库等。

函数工作流对相应的函数进行编排, 比如第一步的函数是转码， 第二步的函数是转码成功后，将相应 meta 数据库写入数据库等。

至此，您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求，接下来，本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统，并与传统方案进行性能、成本和工程效率的对比。

简单视频处理系统

假设您是对短视频进行简单的处理， 架构方案图如下：

如上图所示， 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行， 函数调用 FFmpeg 进行视频转码， 并且将转码后的视频保存回 OSS。

OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数，当 OSS 系统捕获到指定类型的事件后，会自动调用函数处理。例如，您可以设置函数来处理 PutObject 事件，当您调用 OSS PutObject API 上传视频到 OSS 后，相关联的函数会自动触发来处理该视频。

附：简单视频处理系统示例工程地址

您可以直接基于示例工程部署您的简单音视频处理系统服务，因为音视频是强 CPU 密集型计算，强烈建议直接函数内存设置为 3G(2vCPU)，但是当您想要处理大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候， 您会发现函数还是大概率会执行失败，原因是函数计算的执行环境有最大执行时间为 10 分钟的限制，如果最大的 10 分钟不能满足您的需求， 您可以选择：

• 对视频进行分片 -> 转码 -> 合成处理， 详情参考：fc-fnf-video-processing， 下文会详细介绍。
• 联系函数计算团队(钉钉群号: 11721331) 或者提工单
  • 适当放宽执行时长限制
  • 申请使用更高的函数内存 12G(8vCPU)

为了突破函数计算执行环境的限制（或者说加快大视频的转码速度），引入函数工作流 FnF 去编排函数实现一个功能强大的全功能视频处理系统是一个很好的方案。

全功能视频处理系统-Example

如上图所示， 假设用户上传一个 mov 格式的视频到 OSS，OSS 触发器自动触发函数执行， 函数调用 FnF，并行进行提取音频文件，同时进行 avi，mp4，flv 格式的转码。 所以您可以实现如下需求：

• 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理，比如增加水印处理或者在 after-process 更新信息到数据库等；
• 当有多个文件同时上传到 OSS，函数计算会自动伸缩， 并行处理多个文件；
• 对于每一个视频，先进行切片处理，然后并行转码切片，最后合成，通过设置合理的切片时间，可以大大加速较大视频的转码速度；

所谓的视频切片，是将视频流按指定的时间间隔，切分成一系列分片文件，并生成一个索引文件记录分片文件的信息。

• 结合 NAS + 视频切片， 可以解决超大视频（大于 3G ）的转码。

附：全功能视频处理系统示例工程地址

当然， 具体的处理流程是可以根据您的需求修改 fnf 工作流流程， 上面的只是一个示例。

示例效果:

函数计算 + 函数工作流 Serverless 方案 VS 传统方案

卓越的工程效率

	自建服务	函数计算 + 函数工作流 Serverless
基础设施	需要用户采购和管理	无
开发效率	除了必要的业务逻辑开发,需要自己建立相同线上运行环境， 包括相关软件的安装、服务配置、安全更新等一系列问题	只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署
并行&分布式视频处理	需要很强的开发能力和完善的监控系统来保证稳定性	通过 FnF 资源编排即可实现多个视频的并行处理以及单个大视频的分布式处理，稳定性和监控交由云平台
学习上手成本	除了编程语言开发能力和熟悉 FFmpeg 以外，可能使用 K8S 或弹性伸缩( ESS )，需要了解更多的产品、名词和参数的意义	会编写对应的语言的函数代码和熟悉 FFmpeg 使用即可
项目上线周期	在具体业务逻辑外耗费大量的时间和人力成本，保守估计大约 30 人天，包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等	预计 3 人天， 开发调试（2人天）+ 压测观察（1 人天）

弹性伸缩免运维，性能优异

	自建服务	函数计算 + 函数工作流 Serverless
弹性高可用	需要自建负载均衡 (SLB)，弹性伸缩，扩容缩容速度较 FC 慢	FC系统固有毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力，免运维，全功能视频处理系统 (FnF + FC) 压测；性能优异, 详情见下面的转码性能表
监控报警查询	ECS 或者容器级别的 metrics	提供更细粒度的 FnF 流程执行以及函数执行情况, 同时可以查询每次函数执行的 latency 和日志等， 更加完善的报警监控机制

比如短视频处理系统的监控的一个 Example：

函数计算 + 函数工作流 Serverless 方案转码性能表

实验视频为是 89s 的 mov 文件 4K 视频: 4K.mov，云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s， 将这个参考时间记为 T。

视频切片时间	FC 转码耗时	性能加速百分比
45s	160s	117.5%
25s	100s	188%
15s	70s	268.6%
10s	45s	417.8%
5s	35s	537.1%

性能加速百分比 = T / FC转码耗时

从上表可以看出，设置的视频切片时间越短， 视频转码时间越短， 函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。

更低的成本

• 具有明显波峰波谷的视频处理场景(比如只有部分时间段有视频处理请求，其他时间很少甚至没有视频处理请求)，选择按需付费，只需为实际使用的计算资源付费；
• 没有明显波峰波谷的视频处理场景，可以使用预付费（包年包月），成本仍然极具竞争力；

函数计算成本优化最佳实践文档。

• 假设有一个基于 ECS 搭建的视频转码服务，由于是 CPU 密集型计算， 因此在这里将平均 CPU 利用率作为核心参考指标对评估成本，以一个月为周期，10 台 C5 ECS 的总计算力为例， 总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下:

由上图预估出如下计费模型：

• 函数计算预付费 3CU 一个月: 246.27 元， 计算能力等价于 ECS 计算型 C5；
• ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元；
• 函数计算按量付费占整个计算量的占比 <= 10%，费用约为 3×864×10% = 259.2 元，（3G 规格的函数满负载跑满一个月费用为：0.00011108×3×30×24×3600 = 863.8，详情查看计费）。

ITEM	平均CPU利用率	计算费用	总计
函数计算组合付费	>=80%	998（246.27×3+259.2）	<= 998
按峰值预留ECS	<=30%	2190（10*219）	>=2190

• 在这个模型预估里面，可以看出 FC 方案具有很强的成本竞争力，在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%， 理由如下：可能只有部分时间段有视频转码请求；为了用户体验，视频转码速度有一定的要求，可能一个视频转码就需要 10 台 ECS 并行处理来转码， 因此只能预备很多 ECS；
• 因此，在实际场景中， FC 在视频处理上的成本竞争力远强于上述模型；
• 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力

经实验验证， 函数内存设置为3G，基于该方案从 mov 转码为 mp4 的费用概览表：

实验视频为是 89s 的 mov 文件视频， 测试视频地址：
480P.mov 720P.mov 1080P.mov 4K.mov
测试命令: ffmpeg -i test.mov -preset superfast test.mp4

• 格式转换

分辨率	bitrate	帧率	FC 转码耗费时间	FC 转码费用	腾讯云视频处理费用	成本下降百分比
标清 640*480	618 kb/s	24	11s	0.00366564	0.032	88.5%
高清 1280*720	1120 kb/s	24	31s	0.01033044	0.065	84.1%
超清 1920*1080	1942 kb/s	24	66s	0.02199384	0.126	82.5%
4K 3840*2160	5250 kb/s	24	260s	0.0866424	0.556	84.4%

成本下降百分比 = （腾讯云视频处理费用 – FC 转码费用）/ 腾讯云视频处理费用

腾讯云视频处理，计费使用普通转码，转码时长不足一分钟，按照一分钟计算，这里计费采用的是 2 min，即使采用 1.5 min 计算， 成本下降百分比也在 80% 左右。

从上表可以看出， 基于函数计算 + 函数工作流的方案在计算资源成本上具有显著优势。

操作部署

• 免费开通函数计算，按量付费，函数计算有很大的免费额度。
• 免费开通函数工作流，按量付费，函数工作流有很大的免费额度。
• 免费开通文件存储服务NAS， 按量付费

详情见各自示例工程的 README：

• 简单视频处理系统示例工程地址
• 全功能视频处理系统示例工程地址

总结

基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点:

• 无需采购和管理服务器等基础设施，只需专注视频处理业务逻辑的开发，大幅缩短项目交付时间和人力成本
• 提供日志查询、性能监控、报警等功能快速排查故障
• 以事件驱动的方式触发应用响应用户请求
• 免运维，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力，性能优异
• 成本极具竞争力

Q & A

最后一一回答一下之前列出的问题：

Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务，能否在此基础上让它更弹性，更高的可用性？

A: 如工程示例所示，在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算， FFmpeg 相关命令可以直接移值到函数计算，改造成本较低， 同时天然继承了函数计算弹性高可用性特性。

Q2：您的需求只是简单的转码需求，或是一些极其轻量的需求，比如获取 OSS 上视频前几帧的 GIF 等。 自己搭建成本更低。

A: 函数计算天生就是解决这些自定义问题， 你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。
典型示例: fc-oss-ffmpeg

Q3: 您有更高级的自定义处理需求，比如视频转码完成后， 需要记录转码详情到数据库， 或者在转码完成后， 自动将热度很高的视频预热到 CDN 上， 从而缓解源站压力。

A: 详情见全功能视频处理系统(函数计算 + 函数工作流方案)，after-process 中可以做一些自定义的操作， 您还可以基于此流程再做一些额外处理等， 比如：再增加后续流程；最开始增加 pre-process。

Q4: 您有并发同时处理大量视频的需求。

A: 详情见全功能视频处理系统(函数计算 + 函数工作流方案), 当有多个文件同时上传到 OSS, 函数计算会自动伸缩， 并行处理多个文件。详情可以参考 全功能视频处理系统 (FnF + FC) 压测。

Q5: 您有很多超大的视频需要批量快速处理完， 比如每周五定期产生几百个 4G 以上的大视频， 但是希望当天几个小时后全部处理完。

A: 详情可以参考 全功能视频处理系统 (FnF + FC) 压测,  可以通过控制分片的大小， 可以使得每个大视频都有足够多的计算资源参与转码计算， 大大提高转码速度。

Q6: 自定义视频处理流程中可能会有多种操作组合， 比如转码、加水印和生成视频首页 GIF，后续为视频处理系统增加新需求，比如调整转码参数，希望新功能发布上线对在线服务无影响。

A: 详情见全功能视频处理系统(函数计算 + 函数工作流方案), FnF 只负责编排调用函数， 因此只需要更新相应的处理函数即可，同时函数有 version 和 alias 功能， 更好地控制灰度上线， 函数计算版本管理。

Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上，自建服务可以直接读取源文件处理，而不需要将他们再迁移到 OSS 上。

A: 函数计算可以挂载 NAS, 直接对 NAS 中的文件进行处理。

如果你对函数计算的能力还不是很了解，欢迎加入钉钉交流群：

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”

一、背景和痛点

大企业内部，跨团队，跨地域，导致文件共享困难

如果不使用Artifactory，如何实现跨数据中心的文件共享呢？

• 挂载NFS文件系统，开通跨数据中心的rsync/sftp协议
• 自研解决方案，通过REST API或者CLI方式， 例如，雅虎的dist工具
• 私有或者公有的云储存方案
• 利用SCM版本控制系统

–         对于编译构建效率影响很大

 

NFS和云储存的方式对网络要求很高，稳定性得不到保证。自研的方式需要投入很多人力物力，利用SCM版本控制工具对二进制文件支持不好，尤其是大文件，还有可能会对构建效率造成影响。可以看到上面几种方式稳定性不能保证，而且需要额外的投入。

 

 二、 Artifactory用作文件共享中心

那么，Artifactory 如何解决这个问题：

首先，虽然Artifactory被当做管理全语言二进制文件的制品仓库。Artifactory通常被集成到构建流程中，这样构建工件可以方便的部署到不同环境或者用于后续Docker镜像和亚马逊系统镜像的构建。

然而，Artifactory首先是一个支持元数据的文件管理系统，可以管理任何类型文件以及相关数据，利用其可以在集群之间同步复制的功能，也可以被用作跨数据中心分发不同类型文件的通用平台。

架构图

只允许在指定的一个Artifactory集群上传，然后同步到其它生产环境。例如： IDC1，IDC2，AWS这几个环境不允许手动上传，只允许从Corp环境同步，确保数据的来源只有一个，保证数据的一致性。

 

搭建步骤

对于Artifactory用户来说，只需要创建相应对的共享仓库，然后开启同步功能即可，不需要增加额外的投入。而且同步功能对网络要求不高。

开启Artifactory的同步功能：

 

上传下载文件

例如, 将sharefile.tgz上传到my-local-repo仓库

 

命令行方式：

jfrog rt u  sharefile.tgz  my-local-repo

REST API方式：

curl -H "X-JFrog-Art-Api: ${API_KEY}" -X PUT "${artURL}/ my-local-repo/sharefile.tgz " -T sharefile.tgz

 

下载sharefile.tgz 文件

 

命令行方式：

jfrog rt dl my-local-repo/sharefile.tgz

 

REST API方式：

curl -H "X-JFrog-Art-Api: ${API_KEY}" -X GET "${artURL}/my-local-repo/ sharefile.tgz " -o sharefile.tgz

这样即可进行文件的上传和下载，一旦上传成功，会自动触发同步机制，推送到远端的 Artifactory Server 或者公有云的 Artifactory Server。

三、 收益

l  使用Artifactory的好处

Artifactory已经是CI/CD流程的一部分，可以方便的集成

对于跨数据中心的文件分发只需要开启同步功能

• 对网络要求不高
• 具备友好的界面供用户使用
• 支持REST API方式上传和下载文件，方便实现自动化
• 统一多数据中心的文件来源，确保文件一致

 

使用Artifactory可以解决的问题

• 管理第三方工具和包

–  可以指定特殊版本

– 解决网络访问受限的情况

•  作为DevOps流程中配置文件和资源文件管理的中心
• 储存不适合在代码版本控制系统中管理的文件

–  大文件

–  二进制文件

• 储存数据库备份和应用目录的快照

– 可以作为灾备系统的一部分

 

更多精彩内容可以专注我们的在线课堂

微信搜索公众号：jfrogchina 获取课程通知