strimzi實戰之二：部署和消息功能初體驗

歡迎訪問我的GitHub 這裡分類和彙總了欣宸的全部原創(含配套源碼)：https://github.com/zq2599/blog_demos 本篇概覽本篇是《strimzi實戰》系列的第二篇，前文完成了介紹和準備工作，是時候體驗strimzi的核心功能了：發送和接受kafka消息，為了完成這個 ...

歡迎訪問我的GitHub

這裡分類和彙總了欣宸的全部原創(含配套源碼)：https://github.com/zq2599/blog_demos

本篇概覽

本篇是《strimzi實戰》系列的第二篇，前文完成了介紹和準備工作，是時候體驗strimzi的核心功能了：發送和接受kafka消息，為了完成這個目標，本篇會按照如下步驟開始實戰：

在kubernetes環境部署strimzi，這裡麵包含兩個步驟：首先是將各類資源創建好，然後再啟動strmzi
驗證基本功能：發送和接受kafka消息，這裡面有兩種操作（註意，是兩種裡面二選一，不是兩步）：如果您的kubernetes環境有pv，就可以選擇使用pv的操作步驟，如果您沒有pv，就選擇不用pv的操作步驟
刪除操作

接下來開始實戰

部署

創建namespace

kubectl create namespace kafka

部署角色、許可權、CRD等資源

kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka

啟動

接下來的啟動操作，根據您的實際情況，有兩種可選

第一種：如果您的k8s環境已經準備好了pv，請執行以下命令完成部署，strimzi會通過pvc去申請使用pv，這樣就算pod有問題被刪除重建了，kafka消息的數據也不會丟失

kubectl apply -f https://strimzi.io/examples/latest/kafka/kafka-persistent-single.yaml -n kafka

第二種，如果您的k8s環境還沒有準備好pv，請執行以下命令完成部署，這樣創建的kafka服務也能正常使用，只不過所有數據都存在pod中，一旦pod被刪除，數據就找不回來了

kubectl apply -f https://strimzi.io/examples/latest/kafka/kafka-ephemeral-single.yaml -n kafka

以上兩種方式只要選擇一種去執行即可，執行完命令後，需要等待鏡像下載和服務創建，尤其是鏡像下載，實測真的慢啊，我用騰訊雲伺服器大約等了七八分鐘

[root@VM-12-12-centos ~]# kubectl get pod -n kafka
NAME                                        READY   STATUS              RESTARTS   AGE
strimzi-cluster-operator-566948f58c-h2t6g   0/1     ContainerCreating   0          16m

等到operator的pod運行起來後，就該創建zookeeper的pod了，繼續等鏡像下載...

[root@VM-12-12-centos ~]# kubectl get pods -n kafka
NAME                                        READY   STATUS              RESTARTS   AGE
my-cluster-zookeeper-0                      0/1     ContainerCreating   0          7m59s
my-cluster-zookeeper-1                      0/1     ContainerCreating   0          7m59s
my-cluster-zookeeper-2                      0/1     ContainerCreating   0          7m59s
strimzi-cluster-operator-566948f58c-h2t6g   1/1     Running             0          24m

如下圖紅色箭頭所指，顯示正在拉取zookeeper鏡像
等到zookeeper的pod創建完成後，終於輪到主角登場了：開始kafka的pod創建，最後，來個全家福，如下所示，一套具備基本功能的kafka環境

[root@VM-12-12-centos ~]# kubectl get pods -n kafka
NAME                                          READY   STATUS    RESTARTS   AGE
my-cluster-entity-operator-66598599fc-sskcx   3/3     Running   0          73s
my-cluster-kafka-0                            1/1     Running   0          96s
my-cluster-zookeeper-0                        1/1     Running   0          14m
my-cluster-zookeeper-1                        1/1     Running   0          14m
my-cluster-zookeeper-2                        1/1     Running   0          14m
strimzi-cluster-operator-566948f58c-h2t6g     1/1     Running   0          30m

基本操作：收發消息

strimzi部署已經OK，現在收發消息試試，看kafka基本功能是否正常
接下來的操作需要兩個控制台視窗，一個用於發消息，一個用於收消息
在發消息的視窗輸入以下命令，就會創建名為my-topic的topic，並且進入發送消息的模式

kubectl -n kafka \
run kafka-producer \
-ti \
--image=quay.io/strimzi/kafka:0.32.0-kafka-3.3.1 \
--rm=true \
--restart=Never \
-- bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --topic my-topic

在收消息的視窗輸入以下命令，就會進入消費消息的模式，topic是my-topic

kubectl -n kafka \
run kafka-consumer \
-ti \
--image=quay.io/strimzi/kafka:0.32.0-kafka-3.3.1 \
--rm=true \
--restart=Never \
-- bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --topic my-topic --from-beginning

然後，在發送消息的視窗輸入一些文字後再回車，消息就會發送出去，如下圖，左側紅框顯示一共發送了四次消息，最後一次是空字元串，右側黃框顯示成功收到四條消息
如果您的kubernetes環境是按照《快速搭建雲原生開發環境（k8s+pv+prometheus+grafana）》的方法來部署的，現在就能通過grafana看到命名空間kafka下麵的資源了，如下圖
另外，如果您使用了pv，還可以關註一下pv的使用情況，如下圖，kafka的zookeeper的數據都改為外部存儲了，數據不會因為pod問題而丟失
不過由於我們還沒有將strimzi的監控配置好，現在還看不到kafka業務相關的指標情況，只能從k8s維度去查看pod的基本指標，這些會在後面的章節補齊

刪除操作

如果需要把strimzi從kubernetes環境刪除，執行以下操作即可：
如果您使用了pv，就執行以下命令完成刪除

kubectl delete -f https://strimzi.io/examples/latest/kafka/kafka-persistent-single.yaml -n kafka \
&& kubectl delete -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka \
&& kubectl delete namespace kafka

如果您沒有使用pv，就執行以下命令完成刪除

kubectl delete -f https://strimzi.io/examples/latest/kafka/kafka-ephemeral-single.yaml -n kafka \
&& kubectl delete -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka \
&& kubectl delete namespace kafka

再去檢查所有pod，已看不到strimzi的痕跡

[root@VM-12-12-centos ~]# kubectl get pod -A
NAMESPACE            NAME                                          READY   STATUS    RESTARTS   AGE
calico-apiserver     calico-apiserver-67b7856948-bg2wh             1/1     Running   0          6d2h
calico-apiserver     calico-apiserver-67b7856948-fz64n             1/1     Running   0          6d2h
calico-system        calico-kube-controllers-78687bb75f-z2r7m      1/1     Running   0          6d2h
calico-system        calico-node-l6nmw                             1/1     Running   0          6d2h
calico-system        calico-typha-b46ff96f6-qqzxb                  1/1     Running   0          6d2h
calico-system        csi-node-driver-lv2g2                         2/2     Running   0          6d2h
kafka                my-cluster-entity-operator-66598599fc-fz7wx   3/3     Running   0          4m57s
kafka                my-cluster-kafka-0                            1/1     Running   0          5m22s
kafka                my-cluster-zookeeper-0                        1/1     Running   0          5m48s
kafka                strimzi-cluster-operator-566948f58c-pj45s     1/1     Running   0          6m15s
kube-system          coredns-78fcd69978-57r7x                      1/1     Running   0          6d2h
kube-system          coredns-78fcd69978-psjcs                      1/1     Running   0          6d2h
kube-system          etcd-vm-12-12-centos                          1/1     Running   0          6d2h
kube-system          kube-apiserver-vm-12-12-centos                1/1     Running   0          6d2h
kube-system          kube-controller-manager-vm-12-12-centos       1/1     Running   0          6d2h
kube-system          kube-proxy-x8nhg                              1/1     Running   0          6d2h
kube-system          kube-scheduler-vm-12-12-centos                1/1     Running   0          6d2h
local-path-storage   local-path-provisioner-55d894cf7f-mpd2n       1/1     Running   0          3d21h
monitoring           alertmanager-main-0                           2/2     Running   0          24h
monitoring           alertmanager-main-1                           2/2     Running   0          24h
monitoring           alertmanager-main-2                           2/2     Running   0          24h
monitoring           blackbox-exporter-6798fb5bb4-4hmf7            3/3     Running   0          24h
monitoring           grafana-d9c6954b-qts2s                        1/1     Running   0          24h
monitoring           kube-state-metrics-5fcb7d6fcb-szmh9           3/3     Running   0          24h
monitoring           node-exporter-4fhb6                           2/2     Running   0          24h
monitoring           prometheus-adapter-7dc46dd46d-245d7           1/1     Running   0          24h
monitoring           prometheus-adapter-7dc46dd46d-sxcn2           1/1     Running   0          24h
monitoring           prometheus-k8s-0                              2/2     Running   0          24h
monitoring           prometheus-k8s-1                              2/2     Running   0          24h
monitoring           prometheus-operator-7ddc6877d5-d76wk          2/2     Running   0          24h
tigera-operator      tigera-operator-6f669b6c4f-t8t9h              1/1     Running   0          6d2h

不過，對於pv來說，由於使用的策略是Retain，因此還會繼續存在
至此，strimzi基本功能實戰已經完成，咱們知道瞭如何快速部署strimzi和收發消息，感受到operator給我們帶來的便利，接下來的文章，還會有更多簡單的操作，更多精彩的功能等著咱們去嘗試，歡迎您繼續關註欣宸原創，咱們一起學習共同進步

歡迎關註博客園：程式員欣宸

學習路上，你不孤單，欣宸原創一路相伴...