Azure / k8s-set-context

GitHub Action for setting context and retrieving Kubeconfig before deploying to Kubernetes clusters
MIT License
85 stars 34 forks source link

Question: where is kubectl? #82

Open sgdc-raymondong opened 8 months ago

sgdc-raymondong commented 8 months ago

What happened?

Hi there, sorry for my newbie question. The k8s-set-context also installs kubectl as per the documentation. I was using kubectl inside a workflow like the yml snippet below. It was working fine as of May 2023 if I remember correctly. Today when I ran the workflow, the kubectl is no longer inside "/usr/local/bin/" (I ls'ed "/usr/local/bin/" and it's not there). May I know where it could be located now? (ubuntu-latest in May2023 could be Ubuntu 20.04. Now it's Ubuntu 22.04)

name: Test CI
on:
  push:
    branches: [ test ]
    paths:
    - '.github/workflows/test.yml'
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: setting the azure kubernetes context
        uses: Azure/k8s-set-context@v1
        with:
          kubeconfig: ${{ secrets.KUBE_CONFIG }}
      - name: Check pods
        run: /usr/local/bin/kubectl get pods -o wide --namespace ab71f066-5279-46bc-8cb8-d15f3cca9a67

The error for the above workflow is as follows: image

I am not sure why I had to use the kubectl inside "/usr/local/bin/" instead of calling kubectl directly. If I call kubectl directly today, I am getting some TLS errors. Does this mean kubectl is actually there, and maybe some certificate field inside {{secrets.KUBE_CONFIG}} just needs to be updated? (Sorry i don't have access to the Secrets Page in our Github repo) image

Other things I tried (no success): • use "ubuntu-20.04" in the "runs-on" field • use Azure/k8s-set-context@v3 • calling "kubectl version" also leads to TLS errors

Version

Runner

ubuntu-latest and ubuntu-20.04

Relevant log output

image

davidgamero commented 5 months ago

If I call kubectl directly today, I am getting some TLS errors.

this looks more like an issue with your auth/kubeconfig, but it could potentially be related to the default version of kubectl being bumped in those runner images?

you could try running which kubectl to find out where the kubectl binary you are using is located