Running Solr on Kubernetes

原创

黎明你好

修改于 2020-02-10 11:13:33

6.1K0

修改于 2020-02-10 11:13:33

文章被收录于专栏：SolrSolr

原文地址：https://lucidworks.com/post/running-solr-on-kubernetes-part-1/
包括自己在试验过程的一些测试、解释和注意事项

我们将为搜索工程师介绍在Kubernetes（k8s）上运行Solr的基础知识。具体来说，我们涵盖以下主题：

Getting started with Google Kubernetes Engine (GKE)。 (GKR入门)
Helm charts.
StatefulSets, initContainers, ConfigMaps, and Persistent Volumes。
Liveness and Readiness Probes
Cross pod synchronization。 (跨pod同步)
Load-balancing services and pod selectors。 (负载平衡服务和Pod选择器)
Upgrading Solr with zero-downtime canary style deployments。 (丝雀零停机的Solr升级)
Performance and Load Testing。 (性能和负载测试)
Monitoring Solr metrics with Prometheus and Grafana。 (使用Prometheus and Grafana进行监控Solr metrics)
Encrypting traffic between Solr instances using TLS。 (使用TLS加密Solr实例之间的流量)

在下一篇文章中，我们将深入探讨有关自动缩放，性能和负载测试以及其他高级操作的问题。在深入研究细节之前，让我们探讨为什么可能要在Kubernetes上运行Solr的问题。也就是说，k8s为Solr运算符提供了三个主要优点：

帮助实施最佳实践和成熟的分布式系统设计模式，
降低了诸如Solr之类的复杂系统的拥有成本，并且
在用户希望运行基于微服务的应用程序的相同操作环境中运行Solr。

就最佳实践和设计模式而言，Kubernetes提供了一种通用语言来声明如何在生产环境中安装，配置和维护分布式应用程序。运营工程师学习如何管理Solr使用Kubernetes native resources like services, StatefulSets, and volume claims，而不必担心内部实现细节。借助Kubernetes，运维团队可以使用标准工具专注与集群调整，监控，性能测试，日志，报警等。

关于降低拥有成本，Kubernetes使一般运营工程师可以运行Solr，而我们的客户无需投资培训或雇用专家。这对于Solr尤为重要，因为在Solr中，操作大型Solr集群通常需要非常专业的技能。在当今的就业市场上，让Solr专家离开以获得更好的机会是一个真正的风险。当然，k8s并不能消除大规模运行Solr的所有复杂性，但是要走很长一段路。

Kubernetes专为管理基于云的微服务的应用程序而构建。 Solr能够在不到一秒的时间内搜索大量数据集，并通过流表达式提供低延迟的专业分析，因此对于数据密集型应用程序来说，Solr是一个有吸引力的后端。

但是，在几秒钟内将微服务部署到Kubernetes不会产生任何效果，因为随后必须为k8之外的Solr进行复杂的部署过程。理想情况下，运维团队只需将Solr以及与其相关的微服务应用程序一起部署即可。 Lucidworks提供的Solr helm chart 使这成为现实。

既然您已经知道了为什么在Kubernetes上运行Solr是个好主意，那么让我们振作起来，在云中启动Solr集群。

Prerequisites 先决条件

在本节中，我们将介绍如何使用Kubernetes进行设置以及如何在GKE中启动您的第一个集群。如果您已经熟悉kubectl，helm，gcloud和GKE，则可以安全地跳到下一部分。

Kubernetes

在整个文档中，我们展示了如何部署到基于Google Kubernetes Engine（GKE）的集群。建议使用GKE选项，因为您可以快速部署多个节点，GKE是一个学习k8s概念的有趣环境，Google会给您$ 300的免费赠金以开始使用。在继续之前，请按照以下说明设置Google Cloud访问和SDK： https : //cloud.google.com/sdk/docs/quickstarts 。您也可以在minikube上本地运行一个单节点Solr集群，但是这里不做介绍。

Kubectl

kubectl是用于与Kubernetes集群进行交互的命令行工具。它应该已经与minikube或gcloud SDK一起安装了。要验证kubectl是否可用，请执行：kubectl version。如果尚未安装，只需执行以下操作：

gcloud components install kubectl

最终，您将厌倦了键入“ kubectl”，因此现在为将来的自己提供帮助，并在您的shell初始化脚本中添加以下别名（例如〜/ .bash_profile）：

alias k=kubectl

Launch GKE Cluster

启动一个kubernetes实例。

可以使用docker desktop：

https://github.com/AliyunContainerService/k8s-for-docker-desktop

Helm

Helm是k8s生态系统中流行的用于部署应用程序的工具。我们在下面使用Helm来部署Solr，因此请按照此处的说明进行Helm的设置： https : //github.com/helm/helm 。安装Tiller是使用Helm的最常见方法，但并不需要按照本文进行操作。在Mac上简短地尝试：

安装helm v2版本
brew install kubernetes-helm@2

添加环境变量：
echo 'export PATH="/usr/local/opt/helm@2/bin:$PATH"' >> ~/.bash_profile

添加tiller到 [k8s] service account
kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

安装tiller
helm init --service-account tiller

helm version

Deploy Solr to GKE

首先，将带有Zookeeper的3节点Solr集群部署到GKE。克隆仓库或从以下地址下载zip文件： https : //github.com/lucidworks/solr-helm-chart 。我们已将Helm图表提交到https://github.com/helm/charts，但仍在等待批准。

Helm的一个不错的功能是chart可以动态链接到其他charts。例如Solr chart依赖于Zookeeper chart。让我们通过以下操作将Zookeeper chart拖入Solr chat：

# 先移除原先的仓库
helm repo remove stable

# 添加新的仓库地址
helm repo add incubator https://storage.googleapis.com/kubernetes-charts-incubator

# 添加新的仓库地址（阿里云）
helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

# 更新charts列表
helm repo update

# 查询仓库列表
helm search incubator

cd solr-helm-chart/solr

# 下载requirements.yaml文件中定义的其他Chart，这些Chart会存放在charts目录
helm dependency update

在部署之前，请花一点时间查看values.yaml中定义的配置变量。该文件允许您为Solr部署自定义最常见的变量，例如资源分配，传递给Solr的JVM args和Solr版本（当前为7.6.0）。

对于生产来说，通常向在k8s中运行的Helm Tiller服务提交helm charts，但是对于本练习让我们跳过Tiller并使用helm template命令从Solr和Zookeeper helm charts中呈现Kubernetes清单。让我们还将Solr版本更改为7.5.0，以便稍后在练习中可以升级到7.6.0：

# 生成solr.yaml模板文件
helm template . --name solr > solr.yaml

helm template . --set image.tag=7.5.0 --name solr > solr.yaml

现在，使用以下命令将Solr清单（solr.yaml）部署到Kubernetes：

kubectl apply -f solr.yaml

在Zookeeper和Solr初始化时要耐心等待。Kubernetes可能需要从Docker Hub提取Docker映像以及设置持久卷。此外，在Pod初始化时，您也不必担心在GCloud控制台UI中看到的任何警告。根据我们的经验，在配置Pod时，集群工作负载UI的警告有点过于激进，可能会给人错误的感觉。如果首次执行此操作后3到4分钟内Solr和Zookeeper并没有全部运行，则可以开始故障排除。

查看pods状态，：

kubectl get pods

当它们准备就绪时，您将看到类似以下的输出：

NAME               READY     STATUS    RESTARTS   AGE
solr-0             1/1       Running   0          38m
solr-1             1/1       Running   0          35m
solr-2             1/1       Running   0          34m
solr-zookeeper-0   1/1       Running   0          38m
solr-zookeeper-1   1/1       Running   0          37m
solr-zookeeper-2   1/1       Running   0          36m

如果Pod无法进入“Running”状态或上线速度较慢，请使用describe命令查看Pod的特定活动，例如“ kubectl describe pod solr-0”。describe命令输出包括Kubernetes启动Pod所发生的事件。花一点时间查看为solr-0 pod报告的事件。

看起来一切正常，那么现在呢？大多数将Solr用作后端的应用程序都不会将其公开给互联网，而是使用无状态微服务搜索应用程序（例如Lucidworks Fusion）作为前端。因此，我们使用以下kubectl port-forward solr-0 28983:8983将本地端口转发到集群： kubectl port-forward solr-0 28983:8983

Now, point your browser to: http://localhost:28983/solr/#/~cloud?view=nodes

You should see something like:

avatar

创建一个集合：

curl -v "http://localhost:28983/solr/admin/collections?action=CREATE&name=perf3x1&numShards=3&replicationFactor=1&maxShardsPerNode=1&collection.configName=_default"

增加一些测试数据：

wget https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/exampledocs/books.json
curl "http://localhost:28983/solr/perf3x1/update/json/docs?commit=true" -H "Content-Type: application/json" --data-binary @books.json

此时，您将在Kubernetes中运行一个3节点的Solr集群。现在，我们将详细介绍部署的工作方式，并介绍一些基本操作，例如在Solr实例之间启用TLS。

Kubernetes Nuts & Bolts

在本节中，我们介绍了Solr部署的一些有趣方面。为了节省时间，我们将不介绍Zookeeper，而是为您提供有关Zookeeper如何在Kubernetes中工作的以下指南： https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/

而且，这里没有涵盖许多重要的Kubernetes概念。有关k8s概念的更深入介绍，请参见：https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Pod

Pod是一组共享网络和存储的一个或多个容器（通常是Docker）。简单的说，可以将pod视为在安装了特定应用程序的逻辑主机上的一组相关的进程。Pod中的容器共享相同的IP地址和端口空间，因此它们可以通过localhost进行通信，但不能绑定到相同的端口。

由于k8s是一个容器编排框架，您可能想知道为什么他们发明了一个新术语而不是仅仅使用“容器”？事实证明，尽管许多部署在Pod中只有一个容器，而我们的Solr部署就是这种情况，但部署具有多个容器的Pod并不少见。

一个很好的例子是Istio部署的sidecar Envoy代理。具有多个相关容器的pod的经典示例是在同一pod中运行Apache httpd和memcached。互联网上有很多关于Pod的丰富资源，因此让我们继续研究更有趣的概念，并根据需要介绍Solr Pod的重要方面。

StatefulSet启动solr

如果您是Kubernetes的新手，那么您需要了解的第一件事是Pod在集群中移动，您对此没有太多控制权！实际上，您不必在乎Pod是否在集群中移动，因为该过程对于Kubernetes的设计至关重要。

Kubernetes执行的主要任务之一是平衡群集资源的利用率。作为此过程的一部分，k8可能会决定将Pod移动到另一个节点。或者，一个节点可能由于各种原因而发生故障，而k8则需要替换集群中另一个运行正常的节点上的那些发生故障的Pod。

因此，请稍等一会，如果k8将Solr pod移至另一个节点会发生什么情况。如果Solr使用的磁盘没有附带，则在新节点上初始化Solr时，它将没有任何可用的cores（Lucene索引），并且必须从磁盘中的另一个副本执行可能昂贵的快照复制。又由于该信息也存储在磁盘上，它将如何知道需要复制哪些cores？对于使用一个replication因子的集合，情况将更加糟糕，因为没有其他副本可以与之同步。

这个问题并非Solr独有。值得庆幸的是，Kubernetes为Solr等系统提供了一种出色的解决方案，该系统需要在磁盘上保持状态并在Pod移动（或崩溃并重新启动）时恢复状态，即StatefulSets。

我们可以花整个blog来研究StatefulSet的详细信息，但是从https://cloud.google.com/kubernetes-engine/docs/concepts/statefulset上，已经有大量资源可以做到这一点。

我们确实想消除一个误解，即在讨论在Kubernetes上运行Solr时听到过的喃喃自语，即k8s不适合有状态应用程序。的确，k8s与运行有状态应用程序的历史混杂在一起，但这是个老新闻。 StatefulSet是k8中的一流功能，并且有许多成功的有状态应用程序的示例。在helm github站点上搜索带StatefulSet的charts有110个： https://github.com/helm/charts/search?l=YAML&q=StatefulSet.

现在，让我们来看一个StatefulSet的运行情况。如果列出了pod（ kubectl get pods ），您将看到以下输出：

NAME                             READY   STATUS    RESTARTS   AGE
solr-0                           1/1     Running   0          120m
solr-1                           1/1     Running   0          113m
solr-2                           1/1     Running   0          112m
solr-exporter-58dbb665db-46wfx   1/1     Running   0          120m
solr-zookeeper-0                 1/1     Running   0          120m
solr-zookeeper-1                 1/1     Running   0          120m
solr-zookeeper-2                 1/1     Running   0          119m

这些是StatefulSet中名为“solr”的pods。注意，每个都获得一个稳定的hostname，其主机索引以0开头；如果Pod销毁，它将返回相同的主机名但具有不同的IP地址。尽管对于Solr而言并不重要，但是由于它使用Zookeeper来协调集群活动，因此集合中的副本将以升序初始化，并以降序删除。

所以如果需要修改pods数量，则修改values.yaml定义的变量，然后进行一次发布即可。

# 修改values.yaml文件：
replicaCount: 5

# 重新发布：
> helm template . --name solr > solr.yaml
> kubectl apply -f solr.yaml

poddisruptionbudget.policy/solr-zookeeper configured
service/solr-zookeeper-headless configured
service/solr-zookeeper configured
statefulset.apps/solr-zookeeper configured
statefulset.apps/solr configured
configmap/solr-config-map configured
poddisruptionbudget.policy/solr configured
service/solr-exporter configured
deployment.apps/solr-exporter configured
service/solr-headless configured
service/solr-svc configured

# 查看节点：
> kubectl get pods
NAME                             READY   STATUS     RESTARTS   AGE
solr-0                           1/1     Running    0          21m
solr-1                           1/1     Running    0          19m
solr-2                           1/1     Running    0          18m
solr-3                           1/1     Running    0          34s
solr-4                           0/1     Init:1/2   0          9s

添加副本：

avatar

Statefulset介绍

StatefulSet 是Kubernetes中的一种控制器，他解决的什么问题呢？我们知道Deployment是对应用做了一个简化设置，Deployment认为一个应用的所有的pod都是一样的，他们之间没有顺序，也无所谓在那台宿主机上。需要扩容的时候就可以通过pod模板加入一个，需要缩容的时候就可以任意杀掉一个。但是实际的场景中，并不是所有的应用都能做到没有顺序等这种状态，尤其是分布式应用，他们各个实例之间往往会有对应的关系，例如：主从、主备。还有数据存储类应用,它的多个实例，往往会在本地磁盘存一份数据，而这些实例一旦被杀掉，即使从建起来，实例与数据之间关系也会丢失，而这些实例有不对等的关系，实例与外部存储有依赖的关系的应用，被称作“有状态应用”。StatefulSet与Deployment相比，相同于他们管理相同容器规范的Pod，不同的时候，StatefulSet为pod创建一个持久的标识符，他可以在任何编排的时候得到相同的标识符。

StatefulSet由以下几个部分组成：

Headless Service（无头服务）用于为Pod资源标识符生成可解析的DNS记录。
volumeClaimTemplates （存储卷申请模板）基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
StatefulSet，用于管控Pod资源。

kubectl explain sts.spec 主要字段解释：

replicas 副本数
selector 那个pod是由自己管理的
serviceName 必须关联到一个无头服务商
template 定义pod模板（其中定义关联那个存储卷）
volumeClaimTemplates 生成PVC

Statefulset优点

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序、平滑的收缩、删除既Pod是有顺序的，在收缩或者删除的时候要依据定义的顺序依次进行（既从N-1到0，既倒序）。
有序的滚动更新，或金丝雀发布。

Persistent Volumes

为了证明StatefulSet中的副本返回了相同的hostname和附加的存储，我们需要杀死Pod。在开始杀死集群中的Pod之前，让我们介绍一下Solr StatefulSets的重要方面，即PersistentVolumes。如果查看Solr helm chart，您会注意到StatefulSet具有以下volumeMount：

volumeMounts:
  - name: solr-pvc
    mountPath: /opt/solr/server/home

让我们登录solr-0，看看它是什么：

kubectl exec -it solr-0 --container solr -- /bin/bash

solr@solr-1:/opt/solr-8.4.0$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  59.6G  0 disk
└─sda1   8:1    0  59.6G  0 part /etc/hosts
sr0     11:0    1 470.7M  0 rom
sr1     11:1    1   148K  0 rom
sr2     11:2    1 824.6M  0 rom

这表明我们在/opt/solr/server/home安装了20G磁盘。那是怎么发生的？为了使永久卷附加到集中的每个副本，您需要一个卷声明模板，该模板设置组标识（对于Solr，gid = 8983和所需的大小（20 GB）：

statefulset.yaml生成到solr.yaml文件

volumeClaimTemplates:
  - metadata:
      name: solr-pvc
      annotations:
        pv.beta.kubernetes.io/gid: "8983"
    spec:
      accessModes:
        - ReadWriteOnce
        
      resources:
        requests:
          storage: 20Gi

显然，真正的Solr部署需要更多磁盘空间，可以通过更改values.yaml文件中的volumeClaimTemplates.storageSize参数来增加磁盘空间。在后台，GKE从Google计算引擎分配磁盘。您可以使用UI从UI获取有关持久卷附加的存储的详细信息，如下所示：

avatar

或者通过命令：

kubectl describe PersistentVolumeClaim solr-pvc-solr-0

得到的结果：

Name:          solr-pvc-solr-0
Namespace:     default
StorageClass:  hostpath
Status:        Bound
Volume:        pvc-a0b488d5-90e6-4ad2-918c-d36f0aa2ee9a
Labels:        app=solr
               component=server
               release=solr
Annotations:   control-plane.alpha.kubernetes.io/leader:
                 {"holderIdentity":"32e0bba2-4724-11ea-bfa0-3c15c2dd97b4","leaseDurationSeconds":15,"acquireTime":"2020-02-04T13:28:09Z","renewTime":"2020-...
               pv.beta.kubernetes.io/gid: 8983
               pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: docker.io/hostpath
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      20Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Mounted By:    solr-0
Events:        <none>

Using an initContainer to Bootstrap Solr Home

如果查看/opt/solr/server/home目录，则会看到solr.xml文件。这里发生了一些有趣的事情。首先，StatefulSet的pod规范，使用环境变量将以下内容传递给Solr：

- name: "SOLR_HOME"
  value: "/opt/solr/server/home"

Solr 7.x要求SOLR_HOME目录包含solr.xml文件。当k8s挂载solr-pvc卷时，它最初是一个空目录。因此，我们利用另一个有用的Kubernetes工具initContainer将solr.xml引导到我们的持久卷目录中。

statefulset.yaml生成到solr.yaml文件

initContainers:
  - name: check-zk
    image: busybox:latest
    command:
      - 'sh'
      - '-c'
      - |
        COUNTER=0;
        while [  $COUNTER -lt 120 ]; do
          for i in "solr-zookeeper-0.solr-zookeeper-headless" "solr-zookeeper-1.solr-zookeeper-headless" "solr-zookeeper-2.solr-zookeeper-headless" ;
            do mode=$(echo srvr | nc $i 2181 | grep "Mode");
              if [ "$mode" == "Mode: leader" ] || [ "$mode" == "Mode: standalone" ]; then
                exit 0;
              fi;
            done;
          let COUNTER=COUNTER+1;
          sleep 2;
        done;
        echo "Did NOT see a ZK leader after 240 secs!";
        exit 1;
  - name: "cp-solr-xml"
    image: busybox:latest
    command: ['sh', '-c', 'cp /tmp/solr.xml /tmp-config/solr.xml']
    volumeMounts:
    - name: "solr-xml"
      mountPath: "/tmp"
    - name: "solr-pvc"
      mountPath: "/tmp-config"

cp-solr-xml initContainer只是将solr.xml文件从/tmp 复制到/tmp-config，该文件恰好与Solr容器在/opt/solr/server/home看到的永久卷（solr-pvc）相同。但是，等等，solr.xml是如何进入initContainer的/tmp的呢？使用Kubernetes ConfigMap和StatefulSet的volume进行定义：

solr-xml-configmap.yaml生成到solr.yaml

apiVersion: "v1"
kind: "ConfigMap"
metadata:
  name: "solr-config-map"
  labels:
    app: solr
    chart: solr-1.0.0
    release: solr
    heritage: Tiller
data:
  solr.xml: |
    <?xml version="1.0" encoding="UTF-8" ?>
    <solr>
      <solrcloud>
        <str name="host">${host:}</str>
        <int name="hostPort">${jetty.port:8983}</int>
        <str name="hostContext">${hostContext:solr}</str>
        <bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>
        <int name="zkClientTimeout">${zkClientTimeout:30000}</int>
        <int name="distribUpdateSoTimeout">${distribUpdateSoTimeout:600000}</int>
        <int name="distribUpdateConnTimeout">${distribUpdateConnTimeout:60000}</int>
        <str name="zkCredentialsProvider">${zkCredentialsProvider:org.apache.solr.common.cloud.DefaultZkCredentialsProvider}</str>
        <str name="zkACLProvider">${zkACLProvider:org.apache.solr.common.cloud.DefaultZkACLProvider}</str>
      </solrcloud>
      <shardHandlerFactory name="shardHandlerFactory"
        class="HttpShardHandlerFactory">
        <int name="socketTimeout">${socketTimeout:600000}</int>
        <int name="connTimeout">${connTimeout:60000}</int>
      </shardHandlerFactory>
    </solr>

现在，在ConfigMap的solr.xmlkey中包含一个solr.xml文件内容。为了使其可用于StatefulSet中的pod，我们使用以下命令将ConfigMap挂载为volume：

statefulset.yaml生成到solr.yaml

volumes:
  - name: solr-xml
    configMap:
      name: solr-config-map
      items:
      - key: solr.xml
        path: solr.xml

使用initContainers和ConfigMaps将solr.xml引导到Solr的主目录中非常麻烦。它确实是使用initContainers在启动主容器之前使pod处于良好状态的一个很好的例子。将来，Solr应该对此内置的问题有更好的解决方案，请参阅： https : //issues.apache.org/jira/browse/SOLR-13035 。

概括地说，Solr StatefulSet已根据集合名称和副本序号为集群中的每个节点分配了主机名，例如solr-0，solr-1等，并为每个pod分配了20G永久volume在/opt/solr/server/home目录。

Replacing Lost Stateful Replicas

首先查看solr pod运行在哪个node上。

> kubectl get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name
NODE             NAME
docker-desktop   solr-0
docker-desktop   solr-1
docker-desktop   solr-2
docker-desktop   solr-exporter-58dbb665db-46wfx
docker-desktop   solr-zookeeper-0
docker-desktop   solr-zookeeper-1
docker-desktop   solr-zookeeper-2

现在kill调一个solr pod看会发生什么：

kubectl delete po solr-2 --force --grace-period 0

查看现在solr pod状态：

kubectl get pods
NAME                             READY   STATUS     RESTARTS   AGE
apple-app                        1/1     Running    0          17h
banana-app                       1/1     Running    0          17h
solr-0                           1/1     Running    0          4h19m
solr-1                           1/1     Running    0          4h12m
solr-2                           0/1     Init:0/2   0          1s

等待片刻后，请注意丢失的solr-2 pod已重新添加到集群中。如果您重新运行get nodes，您将看到solr-2 pod已经在之前相同的nodes上重新创建。这是因为k8s在努力维持平衡集群。

Liveness and Readiness Probes

Kubernetes使用liveness和readiness探针时刻监控你的pods的状态。目前，Solr helm chart使用以下命令/solr/admin/info/system：

# solr.yaml文件 由statefulset生成

livenessProbe:
  initialDelaySeconds: 20
  periodSeconds: 10
  httpGet:
    scheme: "HTTP"
    path: /solr/admin/info/system
    port: 8983
readinessProbe:
  initialDelaySeconds: 15
  periodSeconds: 5
  httpGet:
    scheme: "HTTP"
    path: /solr/admin/info/system
    port: 8983

Coordinating Pod Initialization

在继续下一节之前，让我们看一下k8s如何协调Solr和Zookeeper pods之间的时序性。具体来说，Solr要求Zookeeper在完全初始化并处理请求之前可用。但是，对于k8s，我们希望能够在无需协调顺序的情况下部署pods。实际上，在Kubernetes中没有在StatefulSets之间命令pod初始化的概念。为此，我们依靠initContainer在k8s调用主Solr容器之前测试ZK运行状况。如果ZK不健康，则initContainer睡眠几秒钟，然后一分钟重试。

statefulset.yaml生成到solr.yaml文件

initContainers:
  - name: check-zk
    image: busybox:latest
    command:
      - 'sh'
      - '-c'
      - |
        COUNTER=0;
        while [  $COUNTER -lt 120 ]; do
          for i in "solr-zookeeper-0.solr-zookeeper-headless" "solr-zookeeper-1.solr-zookeeper-headless" "solr-zookeeper-2.solr-zookeeper-headless" ;
            do mode=$(echo srvr | nc $i 2181 | grep "Mode");
              if [ "$mode" == "Mode: leader" ] || [ "$mode" == "Mode: standalone" ]; then
                exit 0;
              fi;
            done;
          let COUNTER=COUNTER+1;
          sleep 2;
        done;
        echo "Did NOT see a ZK leader after 240 secs!";
        exit 1;

如果Solr不在线，请使用以下命令检查initContainers的状态：

kubectl describe pod <pod name>

Upgrading Solr

还记得我们说过Kubernetes帮助实施最佳实践和经过验证的设计模式吗？在不停机的情况下执行滚动升级是StatefulSet中内置的最佳实践之一。要查看实际效果，只需重新运行helm template命令，而无需使用–set image.tag参数：

helm template . --name solr > solr.yaml

kubectl apply -f solr.yaml

请注意，它如何检测到Solr StatefulSet发生了变化，但其他所有资源均保持不变。从solr-2开始，k8s进行从Solr 7.5.0容器到7.6.0容器的滚动升级。 solr-2初始化之后，查看一下日志，您会看到它现在正在运行Solr 7.6.0：

一切都很好，只是它没有考虑到要升级的节点上所有leader的重新选举。在这种情况下，Kube也支持我们，因为它向solr进程发送了SIGTERM，这触发了solr开始卸载内核并正常关闭。 k8s将等待30秒以使Solr正常关闭，这对于大多数用例来说已经足够了。如果需要，您可以使用Pod规范上的terminationGracePeriodSeconds增加超时时间。

Kubernetes升级策略

在Kubernetes 1.7及更高版本中，通过.spec.updateStrategy字段允许配置或禁用Pod、labels、source request/limits、annotations自动滚动更新功能。

OnDelete：通过.spec.updateStrategy.type 字段设置为OnDelete，StatefulSet控制器不会自动更新StatefulSet中的Pod。用户必须手动删除Pod，以使控制器创建新的Pod。
RollingUpdate 滚动更新：通过.spec.updateStrategy.type 字段设置为RollingUpdate，实现了Pod的自动滚动更新，如果.spec.updateStrategy未指定，则此为默认策略。StatefulSet控制器将删除并重新创建StatefulSet中的每个Pod。它将以Pod终止（从最大序数到最小序数）的顺序进行更新每个Pod。在更新下一个Pod之前，必须等待这个Pod Running and Ready。
Partitions 滚动更新的分区更新：通过指定 .spec.updateStrategy.rollingUpdate.partition 来对 RollingUpdate 更新策略进行分区，如果指定了分区，则当 StatefulSet 的 .spec.template 更新时，具有大于或等于分区序数的所有 Pod 将被更新。具有小于分区的序数的所有 Pod 将不会被更新，即使删除它们也将被重新创建。如果 StatefulSet 的 .spec.updateStrategy.rollingUpdate.partition 大于其 .spec.replicas，则其 .spec.template 的更新将不会更新Pod。默认partition的值是0，简单来说就是当partition等N，N+的都会更新。

示例：修改更新策略，以partition方式进行更新，更新值为2，只有myapp编号大于等于2的才会进行更新。类似于金丝雀部署方式。

# 修改分区更新必须大于等于2的pods
> kubectl patch sts solr -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":2}}}}'

# 进行升级，将solr版本修改为8.3
> kubectl set image sts/solr solr=solr:8.3.0

# 查看状态
> kubectl get pods solr-2 -o yaml |grep image

    image: solr:8.3.0
    imagePullPolicy: Always
    image: busybox:latest

则只会将solr-2升级为8.3.0版本。

多StatefulSet的金丝雀发布

在StatefulSet上滚动更新升级所有Pod，但是如果要在整个集群上滚动发布Solr更新之前进行试验，即要执行所谓的“canary release”，那该怎么办。

例如，假设我们想尝试Solr 8.0.0，但是仅升级一部分，以防万一我们的实验出错了。或者，可以尝试一些不同的Solr配置参数组合。关键是您的canary pod有了一些更改，需要在跨群集推出之前进行验证。

对于本实验，我们只想将发布单个canary pod。在实施该解决方案之前，让我们介绍一下Kubernetes服务如何与一组Pod一起工作。首先，使用以下命令查看为Solr集群定义的服务：

> kubectl get svc -o wide -l app=solr

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE   SELECTOR
solr-exporter   ClusterIP   10.105.249.59    <none>        9983/TCP   10m   app=solr,component=exporter,release=solr
solr-headless   ClusterIP   None             <none>        8983/TCP   10m   app=solr,component=server,release=solr
solr-svc        ClusterIP   10.103.229.114   <none>        8983/TCP   10m   app=solr,component=server,release=solr

Kubernetes使用Pod标签选择器为一组Pod提供上层请求的负载均衡服务。例如，solr-svc服务选择带有以下标签的容器：app=solr，release=solr和component=server：

# solr.yaml文件内容：

---
# Source: solr/templates/service-headless.yaml
---

apiVersion: "v1"
kind: "Service"
metadata:
  name: "solr-headless"
  labels:
    app: solr
    chart: solr-1.0.0
    release: solr
    heritage: Tiller
spec:
  clusterIP: "None"
  ports:
  - port: 8983
    name: "solr-headless"
  selector:
    app: "solr"
    release: "solr"
    component: "server"

因此，只要Pod的标签与服务的选择器匹配，Pod来自哪个StatefulSet（或Deployment）都无关紧要。这意味着我们可以在集群中部署多个StatefulSet，每个StatefulSet指向不同版本的Solr，并且该服务将流量路由到这些SstatefulSet。

我们将其作为练习，供读者使用不同的Solr版本使用单个副本部署另一个StatefulSet。canary pod上线后，您需要使用Solr集合API将集合中的副本添加到canary Solr实例上。

扩展伸缩pods

使用kubectl的scale命名，设置pod数量，则可以扩展或减少pods数量。

有序扩展，有序收缩。

# 将solr应用扩容到6个pod
> kubectl scale sts solr --replicas=6

# 查看pods状态
> kubectl get pods
NAME                             READY   STATUS            RESTARTS   AGE
solr-0                           1/1     Running           2          4h41m
solr-1                           1/1     Running           2          4h40m
solr-2                           1/1     Running           2          4h39m
solr-3                           1/1     Running           2          4h21m
solr-4                           1/1     Running           2          4h20m
solr-5                           0/1     PodInitializing   0          8s

Performance Smoke Test

我们现在不会花很多时间在性能和负载测试上，因为我们将在下一篇文章中更详细地介绍它。目前，我们要回答的问题之一是Solr在Kubernetes中是否较慢。

首先，我们需要大数据的索引，因此我们选择使用在Dataproc中运行的Spark和Lucidworks提供的spark-solr库。以下Scala脚本从存储在Google Cloud Storage（GCS）中的Spark索引导出750万个文档：

该脚本允许我们根据需要使用Spark将其扩展到尽可能多的并发索引核心，因此我们可以测试存储在GCS中的海量Solr集群和任意大小的数据集。索引到以“ n1-standard-4”实例类型运行的3节点群集导致了16,800个文档/秒（3个分片/每个分片1个副本）。我们在Spark端使用了12个并发执行程序核心。

相比之下，我们对在GCE（虚拟机而非容器）上运行的Solr进行了相同的测试，并获得了约15,000个文档/秒。因此，在这种情况下，在Kube上运行速度更快，但这是一个相当小的数据集，并且云VM的性能可能会略有不同。重要的是，Kube在使用相同的n1-standard-4实例类型的GCE中具有与基于VM的性能相当的性能。在下一篇文章中，我们将在启用Solr复制的情况下在更大的集合上运行更长的性能和负载测试。

Solr Metrics in Prometheus

Encrypting Traffic Between Solr Instances Using TLS

Wrap Up

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

lucene/solr

kubernetes

zookeeper

https

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。