调试从为什么开始
在触及任何东西之前，BashPilot 读取受影响工作负载的事件、日志和 describe 输出。你得到实际原因，不是盲目重启。修复和诊断在同一个对话中进行。
Kubernetes 的工作原理
从一句话到经过验证的部署
无需手动编辑 YAML，无需记住 kubectl。您描述结果，BashPilot 就会走与细心的操作员相同的路径。
1
你问
“将 checkout-api 缩放到 6 并检查部署情况。”简单的话，就像你告诉队友的方式。
2
读取集群
在接触任何内容之前，直接从 API 中提取 Pod、事件和当前副本。
3
计划改变
从审阅的目录中选择确切的操作。没有临时的 YAML，没有猜测。
4
风险暂停
清空节点或删除工作负载首先等待您的明确同意。
5
在 API 上运行
通过集群的作用域服务帐户对集群应用更改。
6
验证和报告
监视直到 Pod 准备就绪，然后向您显示具体发生了什么变化。
涵盖什么
集群的每个角落，用简单的英语
深入、原生地覆盖您每天接触的物体。这是一个品味，而不是完整列表。
工作负载部署 · StatefulSets · DaemonSets · 豆荚 · 工作机会 · CronJobs · 还有更多
推出和扩展规模副本 · 滚动更新 · 回滚 · 重新启动 · HPA · 还有更多
网络和入口服务 · 入口 · 端点 · DNS · 网络政策 · 还有更多
Kubernetes
配置和秘密ConfigMaps · Secrets · 环境变量 · 限制和要求 · RBAC · 还有更多
节点和命名空间节点 · 警戒线 · 流走 · 污点 · 命名空间 · 配额 · 还有更多
存储和可观察性PersistentVolumes · PVCs · StorageClasses · 日志 · 活动 · 指标 · 还有更多
它解决的问题
凌晨 2 点页面已处理
每个 Kubernetes 操作员都对这些故障了如指掌。BashPilot 读取真实证据，修复原因并确认恢复。
CrashLoopBackOff
Fixed
读取事件和最后的日志，找到真正的原因，应用修复程序并观察 Pod 保持运行状态。
OOMKilled
Fixed
发现内存限制命中，调整请求和限制的大小，然后干净地重新启动部署。
ImagePullBackOff
Fixed
检查镜像标签、注册表身份验证和拉取机密，并清除阻止拉取的任何内容。
推出卡住
Fixed
检查部署状态和失败的 Pod，然后解除阻止或回滚到最后一个良好的修订版。
待处理的 Pod
Fixed
找出他们不安排的原因，从资源压力到污点再到缺失的 PVC，并清除它。
节点承受压力
Fixed
读取节点状况，安全地封锁和排出节点，并在其他地方重新安排工作负载。
实际上
Kubernetes
对实时工作负载的安全更改
Rollout 被监视到稳定，回滚只需一句话。任何可能中断运行的服务的东西，例如排水节点，在你批准前暂停。
你的 kubeconfig 留在原处
代理使用已经在控制平面上存在的集群凭证。没有上传，没有复制，访问在你删除代理后立即结束。
安全第一
值得生产集群信赖
团队让 BashPilot 靠近实时集群的原因是：它是有范围的，它会在中断之前进行询问，并且它会证明每一个更改。
你的kubeconfig从未离开
代理在控制平面节点上运行并使用那里已有的凭据。没有上传任何内容，也没有复制任何内容。
受 RBAC 约束
它只能执行其服务帐户允许的操作。准确地授予您认为合适的范围，并且不能超出该范围。
中断前批准
清空节点、删除工作负载或缩放至零总是会暂停以供您明确确认。
已验证，未假设
每次更改后，它都会重新读取部署和资源状态。完成意味着集群已就绪，而不是干净的退出代码。
完整的审计追踪
每个操作及其结果都会被记录，因此您始终知道更改的内容、时间和原因。
仅限出站代理
代理通过 TLS 进行轮询，并且不打开入站端口。集群上没有任何扫描仪可以到达的地方。
常见问题
常见问题
它适用于哪些 Kubernetes 设置？
任何代理可以在控制平面节点上以本地 kubectl 访问运行的集群：k3s、kubeadm 集群、单节点实验室和自管生产设置一样。
我必须上传我的 kubeconfig 吗？
不必。这就是设计的要点。代理使用已经在你的控制平面上存在的凭证，它们从不离开机器。
它可以删除工作负载吗？
仅在你批准后。删除部署或排水节点等破坏性操作总是在任何东西运行前显示确认卡。
它替代 kubectl 吗？
对于日常工作，基本上是。你随时可以使用 kubectl。BashPilot 简单地更快地完成日常工作并记录改变的内容。