Giter Club home page Giter Club logo

kubectl-aks's Introduction

Azure Kubernetes Service (AKS) kubectl plugin

kubectl-aks is a kubectl plugin that provides a set of commands that enable users to interact with an AKS cluster even when the control plane is not functioning as expected. For example, users can still use the plugin to debug their cluster if the API server is not working correctly. This plugin allows users to perform various tasks, retrieve information, and execute commands against the cluster nodes, regardless of the control plane's state.

It's important to note that this plugin does not replace the Azure CLI, az. Instead, it complements it by offering additional commands and providing users with a kubectl-like experience. In practice, users will use az to create and delete their AKS cluster, and then use kubectl and kubectl-aks to interact with and debug it.

Going through the following documentation will help you to understand each available command and which one is the most suitable for your case:

Take into account that kubectl-aks expects the cluster to use virtual machine scale sets, which is the case of an AKS cluster.

You can get the node information needed to execute the commands directly from the Azure portal or you can let kubectl-aks get that information for you. If you already have such a information, you can pass it using the flags or environment variables. If you don't have it, kubectl-aks can retrieve it either from the Azure API or the Kubernetes API server. If you expect to use the same node multiple times, it is recommended to import the node information in the configuration file and set it as the default node, see the config command for further details.

Install

There is multiple ways to install the kubectl-aks.

Using krew

krew is the recommended way to install kubectl-aks. You can follow the krew's quickstart to install it and then install kubectl-aks by executing the following command:

kubectl krew install aks
kubectl aks version

It can be uninstalled using the following command:

kubectl krew uninstall aks

Install a specific release

It is possible to download the asset for a given release and platform from the releases page, uncompress and move the kubectl-aks executable to any folder in your $PATH.

VERSION=$(curl -s https://api.github.com/repos/azure/kubectl-aks/releases/latest | jq -r .tag_name)
curl -sL https://github.com/azure/kubectl-aks/releases/latest/download/kubectl-aks-linux-amd64-${VERSION}.tar.gz | sudo tar -C ${HOME}/.local/bin -xzf - kubectl-aks
kubectl aks version

It can be uninstalled by using the following command:

rm ${HOME}/.local/bin/kubectl-aks

Compile from source

To build kubectl-aks from source, you'll need to have a Golang version 1.17 or higher installed:

git clone https://github.com/Azure/kubectl-aks.git
cd kubectl-aks
# Build and copy the resulting binary in $HOME/.local/bin/
make install
kubectl aks version

It can be uninstalled by using the following command:

make uninstall

Usage

$ kubectl aks --help
Azure Kubernetes Service (AKS) kubectl plugin

Usage:
  kubectl-aks [command]

Available Commands:
  check-apiserver-connectivity Check connectivity between the nodes and the Kubernetes API Server
  completion                   Generate the autocompletion script for the specified shell
  config                       Manage configuration
  help                         Help about any command
  run-command                  Run a command in a node
  version                      Show version

Flags:
  -h, --help   help for kubectl-aks

Use "kubectl-aks [command] --help" for more information about a command.

It is necessary to sign in to Azure to run any kubectl-aks command. To do so, you can use any authentication method provided by the Azure CLI using the az login command; see further details here. However, if you do not have the Azure CLI or have not signed in yet, kubectl-aks will open the default browser and load the Azure sign-in page where you need to authenticate.

Permissions

In order to run kubectl-aks commands, the user/service principal must have the permissions to perform the following operations:

  • Run command on the instances: Microsoft.Compute/virtualMachineScaleSets/virtualmachines/runCommand/action
  • List Virtual Machine Scale Sets (VMSS): Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read
  • List Virtual Machine Scale Set Instances (VMSS Instances): Microsoft.Compute/virtualMachineScaleSets/read

Normally if you are using built-in roles e.g Contributor, you should have the above permissions. However, if you are using custom roles for a service principal, you need to make sure that the permissions are granted.

Thanks

  • az: kubectl-aks is inspired by the Azure CLI.
  • azure-sdk-for-net: it is used to interact with the Azure API.
  • krew: it is used to distribute kubectl-aks as a kubectl plugin.
  • InnovationEngine: it is used to ensure that the documentation is always up to date.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

kubectl-aks's People

Contributors

blanquicet avatar dependabot[bot] avatar kimsondrup avatar microsoft-github-operations[bot] avatar microsoftopensource avatar mqasimsarfraz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kubectl-aks's Issues

`run-command` reports the *last* 4096 bytes of the output

This 4096 bytes is a limitation of the API, check reference. However, for some commands like ig it is preferred to print the first 4096 bytes as the first container the columns header, otherwise users will not understand the output. Here an example:

$ ./kubectl-aks run-command "ig top tcp --interval 5 --timeout 5"
Running...

[stdout]
            SENT             RECV
metrics-server                 3104494          metrics-server   6                ::ffff:10.224.0. ::ffff:10.224.0. 1.074KiB         292B
metrics-server                 3104494          metrics-server   4                52.224.21.37:443 10.224.0.30:3322 337B             827B
nsenter                        2396             kubelet          4                52.224.21.37:443 10.224.0.4:34580 176B             480B
nsenter                        4053760          curl             4                169.254.169.254: 10.224.0.4:50316 141B             253B
nsenter                        4053826          curl             4                169.254.169.254: 10.224.0.4:50342 141B             253B
nsenter                        4053745          curl             4                169.254.169.254: 10.224.0.4:59348 141B             253B
nsenter                        4053743          curl             4                169.254.169.254: 10.224.0.4:59344 141B             253B
nsenter                        4053824          curl             4                169.254.169.254: 10.224.0.4:50334 141B             253B
nsenter                        4053763          curl             4                169.254.169.254: 10.224.0.4:50320 141B             253B
nsenter                        2396             kubelet          6                ::ffff:10.224.0. ::ffff:10.224.0. 131B             78B
coredns                        3104542          coredns          6                ::ffff:127.0.0.1 ::ffff:127.0.0.1 118B             92B
coredns                        3104542          coredns          6                ::ffff:127.0.0.1 ::ffff:127.0.0.1 118B             92B
coredns                        3104542          coredns          6                ::ffff:127.0.0.1 ::ffff:127.0.0.1 118B             92B
coredns                        3104542          coredns          6                ::ffff:127.0.0.1 ::ffff:127.0.0.1 118B             92B
coredns                        3104542          coredns          6                ::ffff:127.0.0.1 ::ffff:127.0.0.1 118B             92B
nsenter                        2396             kubelet          4                10.224.0.87:8080 10.224.0.4:41298 112B             94B
metrics-server                 3104494          metrics-server   6                ::ffff:10.224.0. ::ffff:10.224.0. 99B              81B
autoscaler                     875401           cluster-proport  6                ::ffff:10.224.0. ::ffff:10.224.0. 94B              112B
coredns                        3104542          coredns          4                127.0.0.1:8080   127.0.0.1:51896  92B              118B
coredns                        3104542          coredns          4                127.0.0.1:8080   127.0.0.1:51892  92B              118B
coredns                        3104542          coredns          4                127.0.0.1:8080   127.0.0.1:51866  92B              118B
coredns                        3104542          coredns          4                127.0.0.1:8080   127.0.0.1:52396  92B              118B
coredns                        3104542          coredns          4                127.0.0.1:8080   127.0.0.1:51878  92B              118B
autoscaler                     875401           cluster-proport  4                52.224.21.37:443 10.224.0.87:4645 92B              753B
nsenter                        2396             kubelet          6                ::ffff:10.224.0. ::ffff:10.224.0. 56B              100B
nsenter                        2088             containerd       4                127.0.0.1:33916  127.0.0.1:45495  12B              12B
nsenter                        2396             kubelet          4                127.0.0.1:45495  127.0.0.1:33916  12B              12B

[stderr]
time="2023-05-10T13:24:34Z" level=warning msg="Runtime enricher (docker): couldn't get current containers"
time="2023-05-10T13:24:34Z" level=warning msg="Runtime enricher (cri-o): couldn't get current containers"

For this cases, we want to possibility of getting the first 4096 bytes and not the last.

Add flag `--current-node` to `set-node` command

Current situation

Users have to set the node and set it as current node:

$ kubectl aks config set-node node1 --subscription mySubID --node-resource-group myRG --vmss myVMSS --instance-id myInstanceID1
$ kubectl aks config use-node node1

# Run command automatically on node1
$ kubectl aks check-apiserver-connectivity

Ideal situation

Allow doing it in one command:

$ kubectl aks config set-node node1 --current-node --subscription mySubID --node-resource-group myRG --vmss myVMSS --instance-id myInstanceID1

# Run command automatically on node1
$ kubectl aks check-apiserver-connectivity

NOTE

Consider changing use-node to set --current-node. Specially after #56.

Rename plugin to `kubectl-aks`

After discussing with the krew's maintainers, we decided to change the name from kubectl-az to kubectl-aks as it describes better the scope of the plugin. It implies that we have to change the repo, the binaries and make a new release.

Another request from the krew's maintainers is to improve the description, see full discussion in kubernetes-sigs/krew-index#3052.

Allow setting a default subscription as `az` does

Current situation

We must specify every time the subscription ID. Given that usually users work in one single subscription, let's allow to set it once and forever.

Ideal situation

Analogous to az, allow setting a default subscription:

az account set --subscription <mySubscriptionID>
kubectl aks config set-subscription <mySubscriptionID>

It doesn't make sense to have a use-subscription flag because we can't set more than one subscription.

Implementation details

  • The config import command should also import and set the subscription in the config file.
  • If users use the --subscription flag, it should have precedence over the one in the config file.
  • Should we add another command set-subscription or make it a sub-command of set so that we have: set --node and set --subscription?
  • Should we have unset all, unset nodes [node1,node2,...,nodeX]> (optionally, user can unset one or mode nodes) and unset subscription?

[RFE] Implement `cp` command

Current situation

kubectl-aks does not provide any way to copy files into nodes.

Ideal future situation

Investigate if it could be useful for users to have a command to copy files from host to nodes:

$ kubectl aks cp --node aks-agentpool-21361837-vmss000000 /source/path/on/host /destination/path/on/node

Start by investigating the current way to do it using the Azure CLI (az) and whether the SDK already provides the APIs to replicate it here or not.

[RFE] Check of API server connectivity for all the nodes on one single call

Current situation

Currently, the check-apiserver-connectivity command requests users to specify the node where the check will be performed:

$ kubectl get nodes
NAME                                STATUS   ROLES   AGE   VERSION
aks-agentpool-27170680-vmss000000   Ready    agent   11d   v1.22.4
aks-agentpool-27170680-vmss000001   Ready    agent   11d   v1.22.4
aks-agentpool-27170680-vmss000002   Ready    agent   11d   v1.22.4

$ kubectl aks check-apiserver-connectivity --node aks-agentpool-27170680-vmss000000
Running...

Connectivity check: succeeded

Impact

Users needs to execute kubectl-aks multiple times to check the connectivity of all the nodes.

Ideal future situation

The check-apiserver-connectivity should allow user to request this check over all the nodes on one single call:

Example:

$ kubectl aks check-apiserver-connectivity [--all-nodes]
Running...

Connectivity check on "aks-agentpool-27170680-vmss000000": succeeded
Connectivity check on "aks-agentpool-27170680-vmss000001": succeeded
Connectivity check on "aks-agentpool-27170680-vmss000002": succeeded

Implementation options

  • Please verify this discussion before proceeding with the implementation.
  • Try to perform all the checks in parallel.

[RFE] Add golang linter in CI

As mentioned in the comment we should add golang linter to this repository:

Possible Implementation

We can use golangci-lint-action and have a workflow:

name: golangci-lint
on:
  push:
    tags:
      - v*
    branches:
      - master
      - main
  pull_request:
permissions:
  contents: read
  # Optional: allow read access to pull request. Use with `only-new-issues` option.
  # pull-requests: read
jobs:
  golangci:
    name: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-go@v3
        with:
          go-version: '1.17'
      - uses: actions/checkout@v3
      - name: golangci-lint
        uses: golangci/golangci-lint-action@v3
        with:
          # Optional: version of golangci-lint to use in form of v1.2 or v1.2.3 or `latest` to use the latest version
          version: v1.29

          # Optional: working directory, useful for monorepos
          # working-directory: somedir

          # Optional: golangci-lint command line arguments.
          # args: --issues-exit-code=0

          # Optional: show only new issues if it's a pull request. The default value is `false`.
          # only-new-issues: true

          # Optional: if set to true then the all caching functionality will be complete disabled,
          #           takes precedence over all other caching options.
          # skip-cache: true

          # Optional: if set to true then the action don't cache or restore ~/go/pkg.
          # skip-pkg-cache: true

          # Optional: if set to true then the action don't cache or restore ~/.cache/go-build.
          # skip-build-cache: true
``

[RFE] Implement `check-dns` command

Current situation

If users want to check if DNS is working on a given node, they have to use the run-command:

$ kubectl az run-command "nslookup www.microsoft.com" --node aks-agentpool-21361837-vmss000000
Running...

[stdout]
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
www.microsoft.com       canonical name = www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net       canonical name = www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net        canonical name = e13678.dscb.akamaiedge.net.
Name:   e13678.dscb.akamaiedge.net
Address: 104.123.41.162
Name:   e13678.dscb.akamaiedge.net
Address: 2a02:26f0:6d00:595::356e
Name:   e13678.dscb.akamaiedge.net
Address: 2a02:26f0:6d00:5a9::356e


[stderr]

Ideal future situation

Investigate if it could be useful for users to have a dedicated command like check-dns which not just runs nslookup but additional commands that provide a more detailed output to better understand why a given URL wasn't resolved.

Not being able to resolve the URL could be caused by many reasons. For instance, did we actually received a response for our request or it went in time-out? If it went in time-out, was it because the resolver never responded or because our firewall is blocking the DNS request or response? ... etc.

In other words, how can we automate part of this investigation within a command?

[RFE] Improve credentials management to avoid authentication at every execution

Current situation

It is necessary to sign in to Azure to run any kubectl-az command. To do so, the user can use any authentication method provided by the Azure CLI using the az login command; see further details here.

In case the user does not have the Azure CLI or has not signed in yet, kubectl-az will open the default browser and load the Azure sign-in page where the user needs to authenticate:

https://github.com/Azure/kubectl-az/blob/dfc3eaae64f929547dbd9e0e22893627caa3273c/cmd/utils/auth.go#L13-L34

However, unlike the Azure CLI (az), if authentication is done with kubectl-az, the authentication token will not be stored and credentials will be requested at every kubectl-az execution.

Impact

Authentication is requested at every execution. It does not allow users to use kubectl-az within a script. So many other disadvantages.

Ideal future situation

kubectl-az should request the credentials once and use the generated token util it is valid.

Implementation options

Check how the Azure CLI (az) does it.

Allow running `check-apiserver-connectivity` on multiple nodes in parallel

Current situation

It is only possible to run check-apiserver-connectivity on one single node:

kubectl aks check-apiserver-connectivity --node aks-agentpool-27170680-vmss000000

Or:

kubectl aks config import
kubectl aks config use-node aks-agentpool-27170680-vmss000000

# Automatically run on aks-agentpool-27170680-vmss000000
kubectl aks check-apiserver-connectivity

Impact

User can only check one node at a time, or manually run the command in parallel from the shell.

Ideal situation

The check-apiserver-connectivity should allow to run it on more than one node. I see three options we should implement:

  1. Initial support could simply run on all nodes available in the config file:

    kubectl aks check-apiserver-connectivity --all-nodes
  2. But, what if we have nodes from different clusters in the config file? I should be able to specify the cluster I want to test:

    # It retrieves info for all nodes in the cluster and then run the check
    kubectl aks check-apiserver-connectivity --resource-group <myRG> --cluster-name <myCluster>

    It requires to store the cluster information (rg and cluster name) inside the config file to avoid retrieving again information we already have:

    kubectl aks config import --resource-group <myRG> --cluster-name <myCluster>
    
    # This time it reuses the info of cluster's nodes already available in the config file
    kubectl aks check-apiserver-connectivity --resource-group <myRG> --cluster-name <myCluster>
  3. But, what if the cluster is too big and I just want a subset of nodes?

    kubectl aks config import --resource-group <myRG> --cluster-name <myCluster>
    
    # On specific nodes and info is taken from config file
    kubectl aks check-apiserver-connectivity --nodes node1,node2,nodeX

Tasks

[RFE] Support non-AKS architectures (VMSS)

Current situation

kubectl-az expects the cluster to use virtual machine scale sets like AKS:

Resource_Groups
cluster_vmss

Impact

Clusters that does not use VMSS (e.g. ARO which uses VMs directly) are not supported.

Ideal future situation

All the well-known architecture should be supported.

Implementation options

There are a lot of details to discuss here.

[RFE] Add CI documentation

Current situation

#6 introduced a set of tests in the CI. However, there is no documentation about how to configure the secrets tests are using.

Ideal future situation

Describe what exactly a fork repo should configure to get the CI working. Creating a script would be highly appreciated ๐Ÿ˜.

[RFE] Handle SIGINT and interrupt command execution

Current situation

The SIGINT signal is not managed at all.

Impact

Users need to wait until that previous command execution finishes before being able to run another command:

$ ./kubectl-az run-command "ip route" --node aks-agentpool-38928455-vmss000000 -v
Command: ip route shfdsafddow
Virtual Machine Scale Set VM: {
  "SubscriptionID": "fa899caf-8f31-4531-a2c5-4e23e4bbcd0d",
  "NodeResourceGroup": "mc_mauricio-kubeaz-test_mauricio-kubeaz-test_eastus",
  "VMScaleSet": "aks-agentpool-38928455-vmss",
  "InstanceID": "0"
}

Running...
^C
$ ./kubectl-az run-command "ip route" --node aks-agentpool-38928455-vmss000000 -v
Command: ip route shfdsafddow
Virtual Machine Scale Set VM: {
  "SubscriptionID": "fa899caf-8f31-4531-a2c5-4e23e4bbcd0d",
  "NodeResourceGroup": "mc_mauricio-kubeaz-test_mauricio-kubeaz-test_eastus",
  "VMScaleSet": "aks-agentpool-38928455-vmss",
  "InstanceID": "0"
}

Error: failed to run command: couldn't run command: POST https://management.azure.com/subscriptions/fa899caf-8f31-4531-a2c5-4e23e4bbcd0d/resourceGroups/mc_mauricio-kubeaz-test_mauricio-kubeaz-test_eastus/providers/Microsoft.Compute/virtualMachineScaleSets/aks-agentpool-38928455-vmss/virtualmachines/0/runCommand
--------------------------------------------------------------------------------
RESPONSE 409: 409 Conflict
ERROR CODE: Conflict
--------------------------------------------------------------------------------
{
  "error": {
    "code": "Conflict",
    "message": "Run command extension execution is in progress. Please wait for completion before invoking a run command."
  }
}
--------------------------------------------------------------------------------

Ideal future situation

Handle SIGINT and interrupt command execution

Implementation options

According to the documentation, we can't cancel a running script. However, BeginRunCommand receives a context, maybe there is something we can do with it.

Print imported information after running `config import`

Originally posted by @blanquicet in #52 (comment):

If we check, we always execute config show after a config import. I started thinking that we should automatically print the imported data in the config import (maybe with a --quiet flag). Also for the documentation, it makes things more consistent. For instance:

Import node info:

kubectl aks config import

Run command against one of the nodes:

kubectk aks run-command --node <myNode>

Users will take the node name from the previous config import output, they we don't need to ask them to also run config show.

[RFE] Support interactive mode in `run-command`

Current situation

The current implementation of run-command command has the following limitation:

  • Scripts that prompt for information (interactive mode) aren't supported.

Ref: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/run-command#restrictions

Ideal future situation

After implementing #24, we could reuse that logic to support interactive mode. If we are not able to support it without passing through Kubernetes, then the run-command should first try the interactive mode and automatically fallback to non-interactive mode if it fails (Kubernetes control plane is down).

[RFE] Allow setting resource parameters for the next operations

Current situation

If we need to run different commands, we have to specify the resource parameters every time:

kubectl-az run-command --subscription $SUBSCRIPTION --node-resource-group $NODERESOURCEGROUP --vmss $VMSS --instance-id $INSTANCEID 'my-command'
kubectl-az run-command --subscription $SUBSCRIPTION --node-resource-group $NODERESOURCEGROUP --vmss $VMSS --instance-id $INSTANCEID 'another-command'
kubectl-az run-command --subscription $SUBSCRIPTION --node-resource-group $NODERESOURCEGROUP --vmss $VMSS --instance-id $INSTANCEID 'a-third-command'

Impact

It is annoying to have to specify those parameters if I know I am working with the same resource.

Ideal future situation

Allow setting this parameters as environment variables or add a new command to set them:

export SUBSCRIPTION=<sub> / kubectl-az config set subscription <sub> 
export NODERESOURCEGROUP=<nrg> / kubectl-az config set node-resource-group <nrg>
export VMSS=<vmss> / kubectl-az config set vmss <vmss>
export INSTANCEID=<id> / kubectl-az config set instance-id <id>

kubectl-az run-command 'my-command'
kubectl-az run-command 'another-command'
kubectl-az run-command 'a-third-command'

By default, we could read the kubectl-az config file (it doesn't exist yet) to get the values set via "kubectl-az config set", but if the environment variables SUBSCRIPTION, NODERESOURCEGROUP, etc, are set, we use them.

[RFE] Create initial integration tests

Current situation

Integration tests haven't been implemented yet.

Impact

The features are exposed to regressions when a new PR is merged.

Ideal future situation

Implement integration tests for the two commands we have right now. Consider running them on Linux, Windows and MacOS.

[RFE] Integrate `ig` as subcommand

Current situation

Running Inspektor Gadget on AKS nodes is one of the most common use cases for kubectl-az. We can run the ig tool by using the run-command sub-command:

kubectl az run-command --node aks-agentpool-12345678-vmss000000 "ig trace exec --timeout 5" 

With the improvements that #25 will bring, we will be able to run it without --timeout but in an interactive mode:

kubectl az run-command --node aks-agentpool-12345678-vmss000000 "ig trace exec"

However, it is still too expensive to simply verify the version (ig version) or the available commands (ig help). In addition, if a parameter are wrong because of a typo, we need to run the command in the node and return the error.

Ideal future situation

After this improvement in the Inspektor Gadget project, it is now possible to easily build the ig commands in a third-party application. This issue aims to investigate if it is worth to add a specific sub-command in the kubectl-az plugin to run the ig tool available on the AKS nodes:

kubectl az --node aks-agentpool-12345678-vmss000000 ig trace exec

From a very first analysis, it would definitely improve the UX as it would:

  • Allow validating ig's flags locally
  • Allow showing ig's command and flags locally (no interaction with node is needed).

However, there are some doubts:

  • How to distinguish flags intended to be used for kubectl-az and ig? Maybe based on the order kubectl-az [kubeclt-az flags] ig [ig flags]?
  • How to manage ig commands catalog?

[RFE] Provide further details when API server connectivity check fails

Current situation

Currently, the outcome of the check-apiserver-connectivity command is mainly succeeded or failed:

$ kubectl aks check-apiserver-connectivity --node aks-agentpool-27170680-vmss000000
Running...

Connectivity check: succeeded
$ echo $?
0
$ kubectl aks check-apiserver-connectivity --node aks-agentpool-27170680-vmss000000
Running...

Connectivity check: failed with returned value X: <stderr>
$ echo $?
X

However, in case of failure, the stderr could not be enough to understand what is the issue.

Impact

Output could not provide enough details to the user to understand where to start investigation.

Ideal future situation

When there's a failure, the outcome of check-apiserver-connectivity should be enough to understand, at least, when there is a problem with the DNS and when the API sever is actually unreachable.

Implementation options

Before proceeding with this implementation, find a way to simulate an issue on the DNS and verify what is the stderr of the command we are using to verify connectivity (currently kubectl --kubeconfig /var/lib/kubelet/kubeconfig version).

[RFE] Implement `ssh` command

Current situation

kubectl aks doesn't provide a way to ssh into the nodes (VMSS instances) of an AKS cluster.

Ideal future situation

Investigate if how we can implement something like this:

$ kubectl aks shh --node aks-agentpool-12345678-vmss000000
# shell in the node

Of course, the idea solution is to not depend on the Kubernetes control plane but use the Azure SDK to be able to provide this functionality even when the Kubernetes control plane is not working properly, e.g. the API server is down. Note: Check if this kind of functionality is also available for VMSS: https://learn.microsoft.com/en-us/cli/azure/ssh?view=azure-cli-latest#az-ssh-vm

However, if it is not possible, we still have the option of using kubectl-node-shell and provide this functionality only if Kubernetes is working properly.

[RFE] Support importing configuration regardless the status of the k8s control plan

Currently, we only support retrieving the nodes' information if the k8s control plan is working correctly because we use the API server. However, it is possible to use the Azure API and avoid passing through the API server so that we can improve UX by allowing users to get such information in all the cases with kubectl-aks and they don't need to go to the portal or use az.

Here the way to do it using az, we need to find the corresponding APIs to reproduce the same programatically:

Infrastructure/Node resource group: Using the cluster name and resource group, we can retrieve the infrastructure/node resource group like this:

$ az account set --subscription <subscription-id> 
$ az aks show --name <cluster-name> --resource-group <resource-name> --query nodeResourceGroup 
"MC_my-rg_my-cluster_my-location" 

VMSS: Using the infrastructure/node resource group name we can retrieve the VMSS:

$ az resource list --resource-group MC_my-rg_my-cluster_my-location --resource-type Microsoft.Compute/virtualMachineScaleSets --query [].name 
[ 
  "aks-agentpool-12345678-vmss" 
] 

VMSS Instance ID: And using the VMSS we can get the mapping between instances ID and nodes:

$ az vmss list-instances --resource-group MC_my-rg_my-cluster_my-location --name aks-agentpool-12345678-vmss --query "[].{VMSSInstanceID: instanceId, NodeName: osProfile.computerName}" -o table 
VMSSInstanceID    NodeName 
----------------  --------------------------------- 
0                 aks-agentpool-12345678-vmss000000 
1                 aks-agentpool-12345678-vmss000001 
2                 aks-agentpool-12345678-vmss000002 

[RFE] Improve run-command's output formatting

Current situation

All the run-command output is printed to the stdout, including the errors that the command executed in the node printed to the stderr in the node:

$ kubectl az run-command --node myNode "operation on files X and Y"
[stdout]
<Output of operation on file Y>
[stderr]
File X doesn't exits

Ideal future situation

As discussed here, it would be better to print to the actual stdout and stderr:

$ kubectl az run-command --node myNode "operation on files X and Y"
File X doesn't exits --> This should be printed to stderr
<Output of operation on file Y> --> This should be printed to stdout

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.