1 个不稳定版本

0.0.1 2023 年 1 月 27 日

#2#core-db

Apache-2.0

45KB
834

CoreDB Operator

使用 kube-rs 的 Rust Kubernetes 控制器,用于 CoreDB 资源

当检测到 CoreDB 实例的更改时,Controller 对象会进行协调,写入其 .status 对象,创建相关事件,并使用最终化程序进行确保删除处理。

要求

  • Kubernetes 集群
  • CRD
  • Opentelemetry 收集器(可选)

代码风格检查

使用 cargo fmtclippy 运行代码风格检查

Clippy

rustup component add clippy
cargo clippy

cargo fmt

rustup component add rustfmt --toolchain nightly
cargo +nightly fmt

测试

单元测试

cargo test

集成测试

  • 连接到一个可以运行测试的集群
  • 将您的 kubecontext 设置为任何命名空间,并对其进行标记以指示可以在此集群上运行测试(不要在非测试集群上运行)
kubectl label namespace default safe-to-run-coredb-tests=true
  • 启动或安装您要测试的控制台(见下文部分)
  • 运行集成测试
cargo test -- --ignored
  • 集成测试假设您已经安装或正在运行连接到集群的 operator。

其他测试说明

  • 包含 --nocapture 标志以在测试运行期间显示打印语句

集群

例如;安装 kind。安装后,按照 这些说明 创建一个连接到本地镜像仓库的 kind 集群。

CRD

缓存文件 应用 CRD,或从 crdgen 管道传输(如果更改它最好)

cargo run --bin crdgen | kubectl apply -f -

Opentelemetry(可选)

在您的集群中设置一个OpenTelemetry收集器。Temo / opentelemetry-operator / Grafana agent 都应该能够直接使用。如果您的收集器不支持grpc otlp,您需要在 main.rs 中更改导出器。

运行

本地

cargo run
  • 或者,您可以运行时自动重新加载您的本地更改。
  • 首先安装cargo-watch
cargo install cargo-watch
  • 然后,启用自动重新加载运行
cargo watch -x 'run'
  • 或者,可选的遥测(根据需求更改)
OPENTELEMETRY_ENDPOINT_URL=https://0.0.0.0:55680 RUST_LOG=info,kube=trace,controller=debug cargo run --features=telemetry

集群内

使用以下命令编译控制器

just compile

使用以下命令构建镜像

just build

使用以下命令将镜像推送到您的本地仓库

docker push localhost:5001/controller:<tag>

适当地编辑 部署 的镜像标签,然后运行

kubectl apply -f yaml/deployment.yaml
kubectl port-forward service/coredb-controller 8080:80

注意:假定命名空间为 default。如果您需要不同的命名空间,可以在yaml中将 default 替换为您想要的任何内容,并在您的当前上下文中设置命名空间,以便使这里的所有命令都正常工作。

用法

在任何运行场景中,您的应用程序都在端口 8080 上监听,并将观察 CoreDB 事件。

尝试一些

kubectl apply -f yaml/sample-coredb.yaml
kubectl delete coredb sample-coredb
kubectl edit coredb sample-coredb # change replicas

协调器将运行并在每次更改时写入状态对象。您应该在Pod的日志中看到结果,或者在 kubectl get coredb -o yaml 的 .status 对象输出中。

Webapp输出

示例Web服务器公开了一些您可以使用 curl 检查的示例指标和调试信息。

$ kubectl apply -f yaml/sample-coredb.yaml
$ curl 0.0.0.0:8080/metrics
# HELP cdb_controller_reconcile_duration_seconds The duration of reconcile to complete in seconds
# TYPE cdb_controller_reconcile_duration_seconds histogram
cdb_controller_reconcile_duration_seconds_bucket{le="0.01"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="0.1"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="0.25"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="0.5"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="1"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="5"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="15"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="60"} 1
cdb_controller_reconcile_duration_seconds_bucket{le="+Inf"} 1
cdb_controller_reconcile_duration_seconds_sum 0.013
cdb_controller_reconcile_duration_seconds_count 1
# HELP cdb_controller_reconciliation_errors_total reconciliation errors
# TYPE cdb_controller_reconciliation_errors_total counter
cdb_controller_reconciliation_errors_total 0
# HELP cdb_controller_reconciliations_total reconciliations
# TYPE cdb_controller_reconciliations_total counter
cdb_controller_reconciliations_total 1
$ curl 0.0.0.0:8080/
{"last_event":"2019-07-17T22:31:37.591320068Z"}

如果您有一个标准的 PodMonitor 用于 prometheus.io/scrape,指标将自动抓取。

依赖关系

~83MB
~1.5M SLoC