我开源了一款k8s命令行工具,提供命令输入提示和自动补全功能

原创 吴就业 208 1 2024-02-22

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/d64b533c7e25438fb2805307a1893251

作者:吴就业
链接:https://wujiuye.com/article/d64b533c7e25438fb2805307a1893251
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

logo

kubectlx是一款基于go-prompt库开发的k8s命令行工具,目的是简化kubectl工具的一些常用命令的使用, 并提供命令输入提示、自动补全。

前往GitHub:https://github.com/kubectlx/kubectlx

kubectlx

主要功能特性:

支持多k8s集群

1.可通过启动参数指定会话连接的k8s集群

kubectlx --kubeconfig=~/.kube/my_k8s_cluster_config

2.在kubectlx进程中使用use命令切换集群,例如:

kubectlx >>> use cluster ~/.kube/my_k8s_cluster_config
success

use_cluster

支持会话默认namespace

进程中可以指定默认的namespace,减少每条命令都输入-n <namespace>,并且可以切换namespace。 默认namespace为”default”。

可以使用use命令切换namespace,例如:

kubectlx >>> use namespace xx
success

use_namespace

查询当前选择的k8s集群和namespace

如果忘记了当前kubectlx进程选择的是哪个k8s集群,或者哪个namespace,可以使用context命令查看。

例如:

kubectlx >>> context
use cluster: /Users/wjy/.kube/config
use namespace: default

context

退出和清屏

退出kubectlx进程

kubectlx >>> exit

清空屏幕

Bye!
Exiting.

使用帮助命令

使用help查询kubectl支持的命令,例如:

kubectlx >>> help
System Command:
  exit  退出
  clear 清空屏幕
Context Command:
  context       显示当前会话的配置
  use   使用该命令切换集群或Namespace
Kube Command:
  logs  查看容器日记
  get   资源查询
  delete        删除资源
  apply 通过yaml文件来创建或更新Kubernetes资源对象
  edit  编辑资源
......省略

还可以使用’-h’或者’-help’查看子命令的帮助文档,例如:

kubectlx >>> get pods -h
pods:
  (POD_NAME)    回车查看所有pod,或指定pod名称可查看指定pod
  flags:
  -h    查看当前命令帮助文档
  -help 查看当前命令的帮助文档
  options:
    -A  扫描所有Namespace
    -o  输出格式:json|yaml|wide,例如:-o yaml

扩展的命令

除了支持常用的kubectl支持的命令外,kubectlx还扩展了一些命令应对常见的工作场景需求。

1.查询资源的状态,资源名称支持前缀模糊搜索

kubectlx >>> status <资源类型> <资源名称> [options]
Results:
  Type: pods
- ResName: <资源名称> 
    Status:
      状态信息

2.查询资源树,不支持自定义资源

kubectlx >>> tree <资源类型> <资源名称>

例如:

kubectlx >>> tree jobs xxx
jobs    xxx  Complete
  |----pods     yyy    Succeeded

tree_cmd

3.简化事件查询命令

kubectlx >>> tree <资源类型> <资源名称>

例如:

event pods xxxx
LAST SEEN     TYPE     REASON      OBJECT         MESSAGE
76s          Normal    Parsed     pods/xxxx      xxxxxxxxxxx

extended_event_cmd

4.资源有Finalizers,而可能某些Finalizers有问题,导致无法删除,通过–force强制删除也无法删除,需要先移除所有的Finalizers,才能删除, 为了简化这个步骤,kubectlx提供一个扩展命令来实现真正的强制删除。

kubectlx >>> forcedel <资源类型> <资源名称>

extended_forcedel_cmd

5.明文显示Secret资源

secret show secret资源名称

支持参数: * -o:指定输出格式,支持json|yaml,默认为yaml * –show-data=true:只输出data

例如:

kubectlx >>> secret show variable-xxx --show-data=true
TF_VAR_alb_name: chenyuntest
TF_VAR_is_internal: "true"
.......

服务器上下载使用

Linux(Intel):

wget -O kubectlx https://github.com/kubectlx/kubectlx/releases/download/这里替换为最新版本号/kubectlx_linux_amd64

Linux:

wget -O kubectlx https://github.com/kubectlx/kubectlx/releases/download/这里替换为最新版本号/kubectlx_linux_arm64
chmod -R 755 kubectlx
./kubectlx --kubeconfig={kubeconfig文件的路径}
#云原生

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

通过预测Pod的request实现超卖,如果是java感觉容易大面积重启?

超卖其实就是赌徒思想,堵的就是概率。一个节点上的个别Pod异常突增的概率都很小,同时很多Pod一起异常突增的概率更小。

k8s 自定义调度器禁用了某个评分插件,对默认调度器是否有影响?

不会影响到默认调度器,只会影响到scheduler-plugins调度器本身。默认调度器不会因为自定义调度器的配置而改变。

版本回滚是否应该把配置也一起回滚?

最近跟同事们争论的一个问题:一个应用发布平台,版本回滚是否应该支持把配置一同回滚?针对这个事情的讨论,我们分成了两派,一边是赞成派,一边反对派。

Serverless服务日记收集,你们采用哪种方案?

Serverless帮助我们实现了自动扩缩容,但要实现真正的按需付费,就要使用弹性的物理节点,例如AWS的Fargate,使用EKS将Pod调度到Fargate上。这也注定了不会有固定的Node去运行Pod,因此在Node上以DaemonSet部署日记收集容器的方案就走不通了。

为什么java不适合云原生

云原生的优势在于利用Serverless技术优化基础设施成本,要求应用启动速度快且内存占用低。然而,Java应用在自动弹性扩缩容和内存消耗方面存在问题。文章以部署个人项目的视角,通过比较小明使用Go语言和小聪使用Java语言开发的博客系统的部署情况,展示了Java的启动速度慢和内存占用大的不适应性。

极致成本优化背景下,如何通过优化k8s调度器实现计算资源的按需付费(四)

验证gce的自动缩容时机以及扩容需要的时长:扩容一个节点需要等待多长时间,一个节点在没有Pod的情况下多久后会回收。结合scheduler-plugins框架验证。由于scheduler-plugins只是在Score阶段对节点打分,并未在其它阶段阻止Pod调度到分数为0的Node上,例如基于目标负载感知调度,当所有Node的负载都达到目标负载后,即便节点的requests满足Pod所需,是否能走扩容节点,而不是硬塞到现有节点上。