While i'm wirting the github action to run the Run the kubectl command i'm geeting below error "The connection to the server 127.0.0.1:6443 was refused - did you specify the right host or port?"

GitOps
#1

action i have written :

  • name: Run the kubectl command
    run: kubectl version --output=yaml

above will be run on “ubuntu-latest” runner

Output:

image
image709×452 23.6 KB

#2

Are you doing the lab, or are you trying to install ArgoCD locally, and do it that way?

#3

yes. i’m doing lab session on githun action.

#4

A link to the lab would be very useful here.

#5

here is the lab link

https://learn.kodekloud.com/user/courses/github-actions/module/92928734-1d5a-462d-9414-2d3865f5ef79/lesson/4a9a503e-6df4-4021-a8a4-f6b7c0283299

Navigate to your GitHub account and use github-actions-solar-system repository within feature/workflow branch

Explore and modify the workflow file named solar-system.yml

Do the following:

  1. Append a new job with id as dev-deploy
    a. This job should execute on this operating system - ubuntu-latest
    b. This job should run after docker job.
    c. The job should be associated with the development environment
    d. Add the following steps,
  • Step 1 - use an action to checkout the repository
  • Step 2 - use an azure/setup-kubectl action to Install Kubectl with the below config
    version: ‘v1.26.0’
  • Step 3 - use an azure/k8s-set-context action to set kube context using below config
    method: kubeconfig
    kubeconfig: use KUBECONFIG secret added in the development environment
  • Step 4 - add a step run the below kubectl command to verify Step 2 and 3
    cmd: kubectl version --short -o yaml
  1. Commit the changes and checkout the workflow execution
#6

That explains a good deal. THIS IS NOT ARGOCD!! I’ll change the title, deal with this later.

#7

OK, the problem here – and I’m not sure why this is – but the kubeconfig file supplied in the lab won’t work in the github actions environment, since it assumes that there is an apiserver at 127.0.0.1:6443. Which there won’t be. Not sure why the lab does this, since that can’t work. For the lab to work, you need to

  1. Create a K8s cluster that is available to the github actions runner, say, via AWS or Azure, and get a kubeconfig file that points to it.
  2. Use that instead for the lab.

The only thing I can think of is that they designed the lab to do a test of kubectl that might return a zero exit code, i.e., kubectl version --short, even when the cluster is not accessible. As it would not be with the supplied kubeconfig file.