How to Install and Uninstall kube-no-trouble Package on openSuSE Tumbleweed

Last updated: November 08,2024

1. Install "kube-no-trouble" package

Please follow the guidelines below to install kube-no-trouble on openSuSE Tumbleweed


    
        
            $
        

        
            
                sudo zypper refresh
            
                    
    
    Copied


    
        
            $
        

        
            
                sudo zypper install
            
                        
                kube-no-trouble
            
                    
    
    Copied

2. Uninstall "kube-no-trouble" package

This guide let you learn how to uninstall kube-no-trouble on openSuSE Tumbleweed:


    
        
            $
        

        
            
                sudo zypper remove
            
                        
                kube-no-trouble
            
                    
    
    Copied

3. Information about the kube-no-trouble package on openSuSE Tumbleweed

Information for package kube-no-trouble:
----------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : kube-no-trouble
Version : 0.7.2-1.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 40.3 MiB
Installed : No
Status : not installed
Source package : kube-no-trouble-0.7.2-1.1.src
Upstream URL : https://github.com/doitintl/kube-no-trouble
Summary : Easily check your cluster for use of deprecated APIs
Description :
Easily check your cluster for use of deprecated APIs
Kubernetes 1.16 is slowly starting to roll out, not only across various managed Kubernetes offerings, and with that come a lot of API deprecations1.
Kube No Trouble (kubent) is a simple tool to check whether you're using any of these API versions in your cluster and therefore should upgrade your workloads first, before upgrading your Kubernetes cluster.
This tool will be able to detect deprecated APIs depending on how you deploy your resources, as we need the original manifest to be stored somewhere. In particular following tools are supported:
* file - local manifests in YAML or JSON
* kubectl - uses the kubectl.kubernetes.io/last-applied-configuration annotation
* Helm v2 - uses Tiller manifests stored in K8s Secrets or ConfigMaps
* Helm v3 - uses Helm manifests stored as Secrets or ConfigMaps directly in individual namespaces