掘力計(jì)劃第 20 期：Flutter 混合開(kāi)發(fā)的混亂之治
在掘力計(jì)劃系列活動(dòng)第20場(chǎng)，《Flutter 開(kāi)發(fā)實(shí)戰(zhàn)詳解》作者，掘金優(yōu)秀作者，Github GSY 系列目負(fù)責(zé)人戀貓的小郭分享了Flutter 混合開(kāi)發(fā)的混亂之治。Flutter 基于自研的 Skia 引擎
如果你是一名 Kubernetes Operator 的開(kāi)發(fā)者，你曾經(jīng)是否面臨過(guò)這樣一個(gè)棘手的問(wèn)題：如何在本地環(huán)境中高效地調(diào)試 Webhook，尤其是在涉及有效證書回調(diào)的情況下。這篇文章旨在提供一種清晰的指南，幫助你克服這一挑戰(zhàn)，優(yōu)化本地開(kāi)發(fā)和測(cè)試流程。
當(dāng)我們初步涉足 Kubernetes Webhook 時(shí)，面對(duì)的首個(gè)挑戰(zhàn)通常是 Validation Webhook。對(duì)于這種驗(yàn)證型 Webhook 來(lái)說(shuō)，我們可以通過(guò)編寫自動(dòng)化測(cè)試來(lái)驗(yàn)證其功能。
這不僅確保了我的 Webhook 按預(yù)期工作，還允許我在日常開(kāi)發(fā)中臨時(shí)禁用它，從而加快了整個(gè)開(kāi)發(fā)過(guò)程。這種方法讓我能夠巧妙地避免復(fù)雜的調(diào)試問(wèn)題，而不對(duì)整體功能造成任何影響。
if os.Getenv("ENABLE_WEBHOOKS") != "false" { if err = (&webappv1.Guestbook{}).SetupWebhookWithManager(mgr); err != nil { setupLog.Error(err, "unable to create webhook", "webhook", "Guestbook") os.Exit(1) }}然而，對(duì)于 Mutating Webhook 來(lái)說(shuō)，情況就變得有點(diǎn)復(fù)雜了。這類 Webhook 通常負(fù)責(zé)埋點(diǎn)的行為甚至更深層次的集群操作，比如注入 sidecar，這時(shí)候單靠自動(dòng)化測(cè)試顯然是不夠的。我們需要一個(gè)更加高效的本地測(cè)試和調(diào)試方法。
在我們團(tuán)隊(duì)中，有同事采用 Kind 來(lái)部署和測(cè)試服務(wù)，這種方法非常值得稱贊。它完全符合 K8s 的操作模式，為我們提供了一個(gè)接近生產(chǎn)環(huán)境的本地測(cè)試平臺(tái)。但是，大家可能也注意到了，這種方式存在一個(gè)效率瓶頸：每次進(jìn)行代碼更改后，都需要重新構(gòu)建 Docker 鏡像并部署到集群中，這一過(guò)程既耗時(shí)又影響開(kāi)發(fā)流程的連貫性。
作為開(kāi)發(fā)工程師，我們渴望的是一個(gè)極速的內(nèi)部開(kāi)發(fā)循環(huán)，一個(gè)不再需要頻繁的 docker build、docker push 或繁瑣的部署流程，即使這些已經(jīng)完全自動(dòng)化。
我們希望能夠使用本地熟悉的開(kāi)發(fā)工具，如 VS Code 或者 IntelliJ IDEA 進(jìn)行本地調(diào)試，而不是先部署到集群環(huán)境，再通過(guò)日志來(lái)分析錯(cuò)誤這種遠(yuǎn)程調(diào)試模式。
在不禁用 Webhook 的情況下，我們?cè)诒镜貑?dòng) controller 后會(huì)有如下錯(cuò)誤。這個(gè)比較好處理，我們只要使用自簽證書，注入到 WebhookServer 即可，在前面的文章中我介紹過(guò)很多次，這里不再贅述。
2023-11-26T12:55:17+08:00 INFO Stopping and waiting for webhooks...2023-11-26T12:55:17+08:00 INFO Wait completed, proceeding to shutdown the manager2023-11-26T12:55:17+08:00 ERROR setup problem running manager {"error": "open /var/folders/hn/v2s5bx...00000gn/T/k8s-webhook-server/serving-certs/tls.crt: no such file or directory"}...我們來(lái)運(yùn)行一個(gè)示例，想必下面這個(gè)錯(cuò)誤大家都非常熟悉吧，這個(gè)是因?yàn)?Webhook 注冊(cè)的地址'不對(duì)'，它是集群內(nèi)的地址。
? kubectl apply -f ./config/samplesError from server (InternalError): error when creating "config/samples/webapp_v1_guestbook.yaml": Internal error occurred: failed calling webhook "vguestbook.kb.io": failed to call webhook: Post "https://testing-webhooks-webhook-service.testing-webhooks-system.svc:443/validate-webapp-foobar-ai-v1-guestbook?timeout=10s": no endpoints available for service "testing-webhooks-webhook-service"我們?cè)賮?lái)看下 ValidatingWebhookConfiguration 的配置。
apiVersion: admissionregistration.k8s.io/v1kind: ValidatingWebhookConfigurationmetadata: name: testing-webhooks-validating-webhook-configurationwebhooks:- admissionReviewVersions: - v1 clientConfig: service: name: testing-webhooks-webhook-service namespace: testing-webhooks-system path: /validate-webapp-foobar-ai-v1-guestbook port: 443 failurePolicy: Fail matchPolicy: Equivalent name: vguestbook.kb.io rules: - ... ...在這個(gè)配置中，webhooks 字段定義了一個(gè)或多個(gè)要注冊(cè)的 Webhook。每個(gè) Webhook 通過(guò) clientConfig 配置與 Kubernetes API 服務(wù)器的連接方式。
正如大家所看到的 https://testing-webhooks-webhook-service.testing-webhooks-system.svc:443/validate-webapp-foobar-ai-v1-guestbook，這個(gè)默認(rèn)地址其實(shí)就是 K8s 集群內(nèi)部的地址。這恰是 K8s 中處理 Webhook 的常規(guī)方法，其中 service 字段指向集群內(nèi)運(yùn)行的特定服務(wù)。
然而，在本地開(kāi)發(fā)環(huán)境中，我們只在本地運(yùn)行了我們的 Operator，直接使用內(nèi)部服務(wù)是不大可能的，因?yàn)樗?Webhook 服務(wù)必須部署在 K8s 集群中。
當(dāng)我們?cè)?K8s 中配置 Webhook 時(shí)，了解其配置細(xì)節(jié)是非常重要的。kubectl explain 是一個(gè)非常實(shí)用的小工具，它可以幫助我們深入理解 K8s 資源的各個(gè)屬性。
以 ValidatingWebhookConfiguration.webhooks.clientConfig 為例：
? kubectl explain ValidatingWebhookConfiguration.webhooks.clientConfigGROUP: admissionregistration.k8s.ioKIND: ValidatingWebhookConfigurationVERSION: v1FIELD: clientConfig <WebhookClientConfig>:DESCRIPTION:FIELDS: caBundle <string> `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. service <ServiceReference> `service` is a reference to the service for this webhook. Either `service` or `url` must be specified. If the webhook is running within the cluster, then you should use `service`. url <string> `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.通過(guò)以上提供的詳細(xì)信息，不難發(fā)現(xiàn) clientConfig 它除了通過(guò)定義 Service 讓 API 服務(wù)器連接到 WebhookServer 外，還有另外一種方式，那就是直接通過(guò) URL 連接。
為了解決這個(gè)問(wèn)題，我們可以將 Webhook 的配置從服務(wù)轉(zhuǎn)變?yōu)橹苯邮褂?URL。
通過(guò)將 clientConfig 中的 service 字段替換為 url 字段，我們可以指定 Webhook 服務(wù)的外部 URL。這樣一來(lái)，開(kāi)發(fā)者可以在本地運(yùn)行 Webhook 服務(wù)，并通過(guò)公開(kāi)的 URL 使其可被 Kubernetes API 服務(wù)器訪問(wèn)。
例如：
webhooks:- admissionReviewVersions: - v1 clientConfig: url: https://testing-webhooks.loca.lt/validate-webapp-foobar-ai-v1-guestbook這種方法使得在本地開(kāi)發(fā)環(huán)境中調(diào)試 Webhook 變得更加靈活和便捷。開(kāi)發(fā)者可以使用本地服務(wù)器或通過(guò)隧道（如 ngrok[1] 或 localtunnel[2]）暴露的服務(wù)，從而實(shí)現(xiàn)在本地環(huán)境中的有效調(diào)試。
事實(shí)上，我最初的首選是 ngrok，因?yàn)檫@玩意確實(shí)好用，它還有個(gè) localhost:4040 非常的實(shí)用，但遺憾的是，它的 tls 能力是付費(fèi)的。幸好，有很多平替工具可以選擇，比如 localtunnel，用起來(lái)也非常的方便。
步驟 1: 在我們的 main.go 需要接收一個(gè)證書路徑
...var certDir stringflag.StringVar(&certDir, "webhook-cert-dir", "/tmp/k8s-webhook-server/serving-certs", "Admission webhook cert/key dir.")...mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{ Scheme: scheme, Metrics: metricsserver.Options{BindAddress: metricsAddr}, HealthProbeBindAddress: probeAddr, WebhookServer: webhook.NewServer(webhook.Options{ CertDir: certDir, Port: 9443, }), LeaderElection: enableLeaderElection, LeaderElectionID: "dcc993a0.foobar.ai",})...步驟 2：調(diào)整 Makefile，并啟動(dòng)我們的程序
修改 Makefile 文件，讓其可以接收證書目錄：
.PHONY: runrun: manifests generate fmt vet ## Run a controller from your host. go run ./cmd/main.go --webhook-cert-dir ./config/certs啟動(dòng)程序：
? make run...go run ./cmd/main.go --webhook-cert-dir ./config/certs2023-11-26T11:18:42+08:00 INFO controller-runtime.builder Registering a mutating webhook {"GVK": "webapp.foobar.ai/v1, Kind=Guestbook", "path": "/mutate-webapp-foobar-ai-v1-guestbook"}2023-11-26T11:18:42+08:00 INFO controller-runtime.webhook Registering webhook {"path": "/mutate-webapp-foobar-ai-v1-guestbook"}2023-11-26T11:18:42+08:00 INFO controller-runtime.builder Registering a validating webhook {"GVK": "webapp.foobar.ai/v1, Kind=Guestbook", "path": "/validate-webapp-foobar-ai-v1-guestbook"}2023-11-26T11:18:42+08:00 INFO controller-runtime.webhook Registering webhook {"path": "/validate-webapp-foobar-ai-v1-guestbook"}...2023-11-26T11:18:42+08:00 INFO controller-runtime.webhook Starting webhook server...2023-11-26T11:18:42+08:00 INFO controller-runtime.webhook Serving webhook server {"host": "", "port": 9443}...步驟 3：將本地主機(jī)服務(wù)器通過(guò)隧道公開(kāi)
# 安裝npm install -g localtunnel# 使用 lt 命令啟動(dòng)隧道lt --port 9443 / --local-https / --local-ca $(pwd)/certs/ca.crt / --local-cert $(pwd)/certs/tls.crt / --local-key $(pwd)/certs/tls.key / --subdomain testing-webhooksyour url is: https://testing-webhooks.loca.lt步驟 4：修改 ValidatingWebhookConfiguration 配置
我們將默認(rèn)的 service 服務(wù)。
webhooks:- admissionReviewVersions: - v1 clientConfig: service: name: testing-webhooks-webhook-service namespace: testing-webhooks-system path: /validate-webapp-foobar-ai-v1-guestbook port: 443...替換換成 url 直連模式
webhooks:- admissionReviewVersions: - v1 clientConfig: url: https://testing-webhooks.loca.lt/validate-webapp-foobar-ai-v1-guestbook...以上僅以 ValidatingWebhookConfiguration 為例，如果你的 controller 同時(shí)使用了 MutatingWebhookConfiguration，別忘了，處理方式是一樣的。
步驟 5：看看實(shí)際效果如何
最后，我們?cè)賵?zhí)行同樣一個(gè)用例，就可以被當(dāng)前的 ValidatingWebhook 攔截到了。
? kubectl apply -f ./config/samples/webapp_v1_guestbook.yamlThe Guestbook "guestbook-sample" is invalid: metadata.name: Invalid value: "guestbook-sample": Guestbook name must be no more than 5 characters for test purposes
本文鏈接：http://www.www897cc.com/showinfo-26-34633-0.html云原生小技巧 : 如何在本地調(diào)試 Kubernetes Webhook？
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 四種消息隊(duì)列，如何選型？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)