写水文啦啦啦啦啦啦啦
kubectl 可能是 Kubernetes(k8s) 最好用的用户接口, 但各种工具都得自己打磨打磨才能用得顺手, kubectl 也不例外. 日常使用起来仍然有比较繁琐的地方, 比如同时查看多个容器的日志, 自定义 get 的输出格式. 下面就讲一些 kubectl 的使用经验(具体操作大多以 zsh 和 brew 为例).
准备工作: RTFM (读文档!)
根据官方速查表配置好 kubectl 的自动补全:
- Bash shell echo “source > ~/.bashrc
- Zsh shell echo “if [ $commands[kubectl] ]; then source > ~/.zshrc
假如你对 kubectl 不太熟悉, 速查表里余下的内容能快速让你上手, 建议一读. 另外, github 上还有一份更全面的适合打印的速查表 cheatsheet-kubernetes-A4
0.别名
执行下面的命令:
1
2
3
4
5
6
7
8
|
cat>>~/.zshrckubectl-ls~/.kube/columns/deploy~/.kube/columns/prometheus
相关推荐
作者：ZadigX 微服务架构下的灰度发布挑战 在传统的单体应用架构中，灰度发布相对简单。只需要在服务的流量入口处进行分流，通过使用 K8s Service 或各种类型的网关即可实现。然而，微服务架构引入了新的复杂性，服务之间的依赖关系错综复杂。有时候，某个功能的发布可能依赖于多个服务，要求灰度流量在整个调用链中准确路由到灰度版本的服务。传统的单个服务流量入口设置分流的做法无法满足这一需求。为了解
1.1 传统的任务系统设计 传统的任务系统设计主要可以分为master(任务分配/故障感知/负载均衡)、Worker(任务执行/任务监控/任务管理)、分布式协调(etcd等存储元数据)、任务仓库(存储任务的实现比如类或者接口)等几部分， 从大的部分又可以切分为两个部分管控端(分布式协调/master/仓库)、执行端(Worker)，传统的任务系统大概就是这样 通常复杂的就是如何在master如何做
kubelet 在 k8s 架构中是工作在数据面的一个核心组件，它的主要功能包括 pod 生命周期管理（pod 创建、删除、健康检查等）、node 的状态管理等，是 k8s 中最底层的“工人”。 为了能够让管理组件能够及时了解 Node 的最新情况，kubelet 需要定期将所在的 node 的情况上报给控制面组件 kube-apiserver，而 kube-controler-mgr 会监听 k
在 Istio 中，Pilot 是 Istio 控制平面的一个重要组件，它具有以下作用： 流量管理: Pilot 负责管理和配置服务之间的网络流量。它通过与底层的服务发现机制（如 Kubernetes 或 Consul）集成，监测服务注册和注销，并将流量路由到正确的目标。Pilot 支持多种流量管理功能，如基于版本的流量切分、A/B 测试、金丝雀部署等。 负载均衡: Pilot 在服务之间执行负载
论文链接： www.vldb.org/pvldb/vol16… “Krypton 源于 DC 宇宙中的氪星，它是超人的故乡，以氪元素命名 ”。 引言 近些年， 在复杂的分析需求之外，字节内部的业务对于实时数据的在线服务能力也提出了更高的要求。大部分业务不得不采用多套系统来应对不同的 Workload，虽然能满足需求，但也带来了不同系统数据一致性的问题，多个系统之间的 ETL 也浪费了大量的资源，
回到顶部
|
