kubernetes-8：kibana容器化

Posted 2023-05-04

参考技术A

受限图片大小限制，有些图片不是很清晰，可以到微信公众号查看；

前置阅读：

kubernetes-7：elasticsearch容器化

http://toutiao.com/item/6699441606832947723/

提供helm和yaml两种部署方式。

Helm部署步骤详见笔者git地址：

https://github.com/hepyu/k8s-app-config/tree/master/helm/min-cluster-allinone/kibana-min

yaml部署步骤详见笔者git地址：

https://github.com/hepyu/k8s-app-config/tree/master/yaml/min-cluster-allinone/kibana-min

1.progressDeadlineSeconds

2.pod滚动升级

3.readinessProbe

4.restartPolicy

容器化成功后的组件：

docker pull kibana:6.4.3

重命名镜像为：docker.elastic.co/kibana/kibana:6.4.3

docker images |grep kibana |awk \'print "docker tag ",$1":"$2,$1":"$2\' |sed -e \'s#kibana#docker.elastic.co/kibana/kibana#2\' |sh -x

Add the elastic helm charts repo：

helm repo add elastic https://helm.elastic.co

helm容器化Kibana的命令：

helm install --name es-min-kibana elastic/kibana --namespace es-min-kibana --version 6.4.3 --set elasticsearchHosts=http://es-min-ingest.es-min:9200,elasticsearchURL=http://es-min-ingest.es-min:9200

helm参数详解：

--name：指定本次部署的名字，通过helm list可以查看通过helm部署的组件；

elastic/kibana：指定chart的名字，helm执行过程是先取到chart配置，从chart配置中取到资源的URL；

--namespace：指定kibana部署到容器中所归属的命名空间；

--version：指定kibana版本；

--set：指定Kibana的详细参数；

elasticsearchHosts与elasticsearchUrl：指定kibana要关联的elasticsearch集群的地址；es-min-ingest是容器内部es的service域名，es.min是指的es集群的命名空间，因为这里涉及到了跨命名空间访问，所以需要带namespace的后缀；

笔者github提供elasticsearch的yaml配置文件：

https://github.com/hepyu/k8s-app-config/tree/master/yaml/min-cluster-allinone/kibana-min

提供了一个deploy.sh，可以直接运行sh deploy.sh完成容器化；

或者依次执行命令：

kubectl apply -f kibana-min-deployment.yaml

kubectl apply -f kibana-min-service.yaml

笔者的yaml配置文件中做了详细注释，可以直接进入github去阅读相关yaml配置文件，这里只罗列其中的重点：

1.progressDeadlineSeconds

Deployment失败判定标准，由于elasticsearch相关服务的启动/就绪都挺慢，特别当elasticsearch集群和kibana同时容器的时候，所以需要设置此判定参数。

2.pod滚动升级

支持两种滚动方式：按照比例启动；也可以指定具体个数。

3.readinessProbe

pod就绪判定标准, 很有必要；当es集群负荷过高时，kibana与es的联通会不通畅，需要K8S去识别是kibana pod是不是真的宕机了。

4.restartPolicy

Pod保活的重要手段。

OPNFV支持容器化的OpenStack和Kubernetes

导读

    

      10月24日，OPNFV项目宣布推出第五版平台—— Euphrates。这是首个提供容器集成和Kubernetes支持的版本。它能够通过Kolla部署容器化的OpenStack（Kolla提供用于运行OpenStack云的生产就绪容器和部署工具）。

Linux基金会OPNFV主管Heather Kirksey介绍了Euphrates和开源项目的最新活动。该小组正在展示另一种CORD型项目。OPNFV的管理层一直在全球几个重点区域与OPNFV社区成员和运营商举行会议。

Q：Euphtates版本的亮点是什么？

Kirksey：这次我们添加的一个重大功能是支持Kubernetes和支持容器化的OpenStack。这是朝更轻松地管理平台和部署用于部署OpenStack的Kolla的云原生前进的基础。围绕容器和Kubernetes的旅程和对云原生的支持是一段时间以来我们一直在谈论的，现在开始看到它的实现。这是多个社区协作的成果——Kolla是OpenStack基金会做的，OpenDaylight和FD.io在容器支持项目和Kubernetes方面做了一些工作。这是一个跨社区的工作。

这一版本的其他亮点是：我们一直在谈论跨社区CI （持续集成）项目，它将多个项目的CI / CD（持续交付）管道集成在一起，使开发人员能够更快速地测试集成堆栈。我们可以在开发周期中进行集成和端到端测试而不用一直等待稳定版本。我们现在可以在几天之内就向上游开发者提供反馈，而不是六周什么也做不了只能等着。这就意味着能够更快地实现和测试功能。

我们还在MANO方面添加了Open Baton集成。Open Baton是另一种MANO堆栈。OPNFV的原则之一是开放与多个开源项目的集成。Open Baton项目希望能够与我们集成其MANO堆栈。我们已经有了为运营商提供多种选择并允许所有这些多重集成的方法。例如，在SDN控制器方面，我们有OpenContrail、ONOS和OpenDaylight集成的场景。

Q：据了解，OPNFV正在构建功能性Virtual Central Office（VCO）概念验证，描述了虚拟化的业务和住宅服务。这听起来有点像Central Office Rearchitectured as a Data Center（CORD）。

Kirksey：我们在北京的OPNFV峰会上介绍了这一点，还在台上做了一个现场演示。这个演示的重点是与CORD正在考虑的相同用例，即在COTS硬件上运行的虚拟化中心办公室及其现代化。我们在这个演示中使用了不同的软件堆栈。这是OpenStack、OpenDaylight、FD.io以及来自不同供应商的一些专有和开源VNF的组合。我们也在一些开放计算项目硬件上运行它。CORD使用ONOS，还具有用于编排的XOS片段。VCO演示解决了相同的用例，但使用了不同的堆栈。

Q：为什么OPNFV做这种CORD类型演示？

Kirksey：为了提供新的选择。很多运营商都在使用ONOS，也有很多在使用OpenDaylight。用OpenDaylight显示用例的能力是许多运营商想要看到的。我看到中国的运营商同时在做ONOS和OpenDaylight。他们喜欢有更多选择。这是我们在北京展示的PoC，但也指出了边缘用例的重要性。我最近与运营商进行了很多交流，他们开始关注5G计划，从而使工作负载更接近用户。

Q：听说还有一个即将到来的OPNFV合规和验证计划。这是什么，什么时候上线？

Kirksey：会在今年晚些时候出现，这是一个全新的事情。想法是为运营商带来NFV的商业化产品。而且据了解，他们认为有一个像OPNFV这样的中立第三方对不同产品进行合规测试是有用的。我们最初的重点将放在NFV基础设施和VIM （虚拟基础设施管理器）上，并进行一些功能测试。随着时间的推移，该计划将纳入其他元素。我们可能要与ONAP一起验证应用程序，这是很有前瞻性的想法 。真正的重点在于实际的商业化产品。

Q：OPNFV最近在巴黎、米兰、斯德哥尔摩、伦敦、特拉维夫和日本参加了Linux基金会的新开源网络日。这样做的目的是什么？

Kieksey：目的是走出去，到社区去，并与许多不同的人交流。不是每个人都能够参加我们的峰会。这是深入社区的好方法，将当地人聚集在一起，让他们有机会互相沟通，谈论项目。我们允许本地站点主机指导编程，而有趣的是有些事情是相当一致的，但是每个网站都有不同的风格。在日本的时候，我们可以和KDDI、SoftBank和Docomo共同组建一个panel，这是非常罕见的。我们在巴黎举行了另一次很棒的会议，意大利电信、英国电信、Orange和DT都出现了。能够广泛听取运营商的意见和建议是一件很令人高兴的事。

阅读推荐：

活动推荐：

还不快来添加小助手进群报名？

投稿邮箱：[e-mail]