GithubHelp home page GithubHelp logo

setup-k3d-k3s's Introduction

Setup K3d/K3s for GitHub Actions

Install K3d/K3s and start a local Kubernetes cluster of a specific version.

K8s is Kubernetes. K3s is a lightweight K8s distribution. K3d is a wrapper to run K3s in Docker.

K3d/K3s are especially good for development and CI purposes, as it takes only 20-30 seconds of time till the cluster is ready. For comparison, Kind takes 1.5 minutes, Minikube takes 2 minutes till ready (as of Sep'2020).

Quick start

Start with the simplest way:

jobs:
  some-job:
    steps:
      - uses: nolar/setup-k3d-k3s@v1

Change versions with the verbose way:

jobs:
  some-job:
    steps:
      - uses: nolar/setup-k3d-k3s@v1
        with:
          version: v1.21  # E.g.: v1.21, v1.21.2, v1.21.2+k3s1
          github-token: ${{ secrets.GITHUB_TOKEN }}

Inputs

version

Required version of Kubernetes and/or K3s -- either full or partial.

The following notations are supported:

  • v1.21.2+k3s1
  • v1.21.2
  • v1.21
  • v1
  • latest

Defaults to latest.

Keep in mind that K3d dates back only to v1.16. There are no 1.15 and older versions of K8s. Besides, 1.16 and 1.17 are broken and will not be fixed (see #11).

When the version is partial, the latest detected one will be used, as found in K3s releases, according to the basic semantical sorting (i.e. not by time of releasing).

k3d-tag

A tag/version of K3d to use. Corresponds to GitHub tags at https://github.com/rancher/k3d/releases. For example, v5.0.0. latest is also accepted, but converted to an empty string for the installation script.

By default (i.e. if no value is provided), the latest version is used.

k3d-name

A name of the cluster to be created.

By default (i.e. if no value is provided), K3d/K3s define their own name. Usually it is k3d-k3s-default.

Note: the name should not include the k3d- prefix, but must be used with it. The k3d- prefix is enforced by K3d and cannot be disabled.

k3d-args

Additional args to pass to K3d. See k3d cluster create --help for available flags.

github-token

A token for GitHub API, which is used to avoid rate limiting.

The API is used to fetch the releases from the K3s repository.

By default, or if it is empty, then the API is accessed anonymously, which implies the limit of approximately 60 requests / 1 hour / 1 worker.

Usage:

with:
  github-token: ${{ secrets.GITHUB_TOKEN }}

skip-creation

Whether to return from the action as soon as possible without the cluster creation (the cluster readiness is also skipped). This can be useful to only install the tools for manual cluster creation, or to parse the available versions and return them as the action's outputs.

By default (false), the cluster is created.

skip-readiness

Whether to return from the action as soon as possible, possibly providing a cluster that is only partially ready.

By default (false), the readiness is awaited by checking for some preselected resources to appear (e.g., for a service account named "default").

Outputs

k3d-version

The specific K3d version that was detected and used. E.g. v5.0.0.

k3s-version

The specific K3s version that was detected and used. E.g. v1.21.2+k3s1.

k8s-version

The specific K8s version that was detected and used. E.g. v1.21.2.

Examples

With the latest version of K3d/K3s/K8s:

steps:
  - uses: nolar/setup-k3d-k3s@v1

With the specific minor version of K8s, which implies the latest micro version of K8s and the latest possible version of K3s:

steps:
  - uses: nolar/setup-k3d-k3s@v1
    with:
      version: v1.21

With the very specific version of K3s:

steps:
  - uses: nolar/setup-k3d-k3s@v1
    with:
      version: v1.21.2+k3s1

The partial versions enable the build matrices with only the essential information in them, which in turn, makes it easier to configure GitHub branch protection checks while the actual versions of tools are upgraded:

jobs:
  some-job:
    strategy:
      fail-fast: false
      matrix:
        k8s: [ v1.21, v1.20, v1.19, v1.18 ]
    name: K8s ${{ matrix.k8s }}
    runs-on: ubuntu-22.04
    steps:
      - uses: nolar/setup-k3d-k3s@v1
        with:
          version: ${{ matrix.k8s }}

Multiple clusters in one job are possible, as long as there is enough memory (note: k3d- prefix is enforced by K3d):

jobs:
  some-job:
    name: Multi-cluster
    runs-on: ubuntu-22.04
    steps:
      - uses: nolar/setup-k3d-k3s@v1
        with:
          version: v1.20
          k3d-name: 1-20
      - uses: nolar/setup-k3d-k3s@v1
        with:
          version: v1.21
          k3d-name: 1-21
      - run: kubectl version --context k3d-1-20 
      - run: kubectl version --context k3d-1-21 

Custom version of K3d can be used, if needed:

jobs:
  some-job:
    name: Custom K3d version
    runs-on: ubuntu-22.04
    steps:
      - uses: nolar/setup-k3d-k3s@v1
        with:
          k3d-tag: v4.4.8
      - run: k3d --version

Custom args can be passed to K3d (and through it, to K3s & K8s):

jobs:
  some-job:
    name: Custom args
    runs-on: ubuntu-22.04
    steps:
      - uses: nolar/setup-k3d-k3s@v1
        with:
          k3d-args: --servers 2 --no-lb
      - run: kubectl get nodes  # there must be two of them

For real-life examples, see:

setup-k3d-k3s's People

Contributors

cbandy avatar nolar 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  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

Watchers

 avatar  avatar  avatar

setup-k3d-k3s's Issues

Got `No matching K3s versions were found. ` when setup v1.21

When I use this script in gitlab ci to setup my test environment, it returns a fail message: No matching K3s versions were found.

image

I checked the code, found that currently action.sh only support latest 200 versions ( which >= v1.24.7-rc3+k3s1, and continue growth day by day), can we fix this?
image

Running this via Github Action runner (Docker-In-Docker and host k3s cluster) results in wierd behavior

Environment:

Running Github Actions runners inside a existing k3s Kubernetes cluster inside CI namespace.

Somehow the readiness things keeps on yelling about no CI namespace? Any ideas, or should I make an issue upstream?

Preparing to install k3d into /usr/local/bin
k3d installed into /usr/local/bin/k3d
Run 'k3d --help' to see what you can do with it.
k3d version v5.4.6
k3s version v1.24.4-k3s1 (default)
Detected k3d-version::v5.4.6
Detected k3s-version::v1.22.12+k3s1
Detected k8s-version::v1.22.12
INFO[0000] Prep: Network                                
INFO[0001] Created network 'k3d-k3s-default'            
INFO[0001] Created image volume k3d-k3s-default-images  
INFO[0001] Starting new tools node...                   
INFO[0002] Creating node 'k3d-k3s-default-server-0'     
INFO[0003] Pulling image 'ghcr.io/k3d-io/k3d-tools:5.4.6' 
INFO[0006] Pulling image 'rancher/k3s:v1.22.12-k3s1'    
INFO[0011] Starting Node 'k3d-k3s-default-tools'        
INFO[0018] Creating LoadBalancer 'k3d-k3s-default-serverlb' 
INFO[0020] Pulling image 'ghcr.io/k3d-io/k3d-proxy:5.4.6' 
INFO[0036] Using the k3d-tools node to gather environment information 
INFO[0038] HostIP: using network gateway 172.18.0.1 address 
INFO[0038] Starting cluster 'k3s-default'               
INFO[0038] Starting servers...                          
INFO[0038] Starting Node 'k3d-k3s-default-server-0'     
INFO[0048] All agents already running.                  
INFO[0048] Starting helpers...                          
INFO[0048] Starting Node 'k3d-k3s-default-serverlb'     
INFO[0057] Injecting records for hostAliases (incl. host.k3d.internal) and for 2 network members into CoreDNS configmap... 
INFO[0060] Cluster 'k3s-default' created successfully!  
INFO[0060] You can now use it like this:                
kubectl cluster-info
Waiting for cluster readiness
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found
  Error from server (NotFound): namespaces "ci" not found

Interested in adding registry support?

Maybe I'm using this wrong but I feel like a common CI case would be to

docker build
docker push <>
k3d/s deploy app based on docker image

For this scenario, I'm using a k3d managed local registry, which is difficult (maybe) to use with the current action here.

I think the action should take a new create_registry and port args (both optional) and if set
create the registry, then
create cluster referencing it
(makes it easier to deterministically set port for downstream docker push vs uber command that creates cluster + registry on random port)

or are people doing something else?

Add support for pre-releases

Currently, all pre-releases are filtered out. The one that is not marked as a pre-release (v1.18.2-rc3+k3s1) is sorted improperly — it goes as if it is newer that its public release (v1.18.2+k3s1).

A/C:

  • Version sorting is fixed so that RCs go after their public releases.
  • RCs can be used by mentioning their name explicitly without additional options.
  • RCs can be automatically detected by specifying with: prereleases: true and partial versions (e.g. v1.18).

Intermittent fail

When running the setup-k3d-k3s in our Github workflow we sometimes get an error.

Setup:

jobs:
  some-job:
    steps:
      - name: Set up k3d
         uses: nolar/setup-k3d-k3s@v1
         with:
           version: v1.20

Error:

Run nolar/setup-k3d-k3s@v1
  with:
    version: v1.20
    k3d-tag: latest
  env:
    MSYS: winsymlinks:nativestrict
Run /home/runner/work/_actions/nolar/setup-k3d-k3s/v1/action.sh
  /home/runner/work/_actions/nolar/setup-k3d-k3s/v1/action.sh
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    MSYS: winsymlinks:nativestrict
    VERSION: v1.20
    K3D_TAG: latest
    K3D_NAME: 
    K3D_ARGS: 
    GITHUB_TOKEN: 
    SKIP_CREATION: 
    SKIP_READINESS: 
Error: Process completed with exit code 22.

Based on the exit code it seems that the curl command in action.sh got 401 Unauthorized. This error occurs irregularly (when running the same setup).

k3d channels

I see mention of "channel" in the k3d v5.1.0 release notes. It looks like k3d is now able to resolve words like +latest and +v1.20 to calculate a full version of k3s.

Should this action allow or leverage those words?

Add pagination with version listing

Currently, only the first page is used. It can be min 100 versions of the 1st page (done with ?per_page=999) — which is enough for the nearest months-years.

But just for the sake of completeness and future compatibility, the releases should be paginated, and all pages should be listed.

Add support for not automatically creating a cluster

Thanks for this very useful action! I have a use case where I'd like to start the cluster in a very specific way, so I'd like to do that myself. It would be cool if this action supported not automatically starting a cluster.

Known issue (won't fix): broken with Kubernetes 1.16-1.17

TL;DR: Kubernetes 1.16 & 1.17 are broken and will not be fixed because they are EOL (as of June 2021), the effort to investigate the issue is too high and is not worth it. The lowest version that works is 1.18.

This issue is created to be pinned and visible.

Related: k3d-io/k3d#663

In case someone wants to investigate, here is the data 👇


Since recently (26.06.2021 – 30.06.2021), something has changed, and K3d versions 1.17 and 1.16 cannot start properly now. It was fine in GitHub Actions on 26.06.2021 with K3d 1.17 & 1.16. It remains fine with K3s 1.18-1.21. It is all fine on Macbook with all the recent and old versions of K3d. Versions of K3d seems to have no effect on the issue (in either way), but maybe I tried it wrong.

I.e., between Jun 26 and Jun 30, something has broken specifically in GitHub Actions and specifically with K3s 1.16-1.17.

The cluster is created with:

k3d cluster create --wait --image=rancher/k3s:v1.17.17-k3s1 (as here)

The failure is e.g. here:

k3d installed into /usr/local/bin/k3d
Run 'k3d --help' to see what you can do with it.
k3d version v4.4.3
k3s version v1.20.6-k3s1 (default)

INFO[0000] Prep: Network                                
INFO[0000] Created network 'k3d-k3s-default' (d7c8ddf7787d2ce7e4c64f1389b86352cc9bb447e33fc7b468ac2e70f4521930) 
INFO[0000] Created volume 'k3d-k3s-default-images'      
INFO[0001] Creating node 'k3d-k3s-default-server-0'     
INFO[0001] Pulling image 'rancher/k3s:v1.17.17-k3s1'    
INFO[0008] Creating LoadBalancer 'k3d-k3s-default-serverlb' 
INFO[0008] Pulling image 'docker.io/rancher/k3d-proxy:v4.4.3' 
INFO[0011] Starting cluster 'k3s-default'               
INFO[0011] Starting servers...                          
INFO[0011] Starting Node 'k3d-k3s-default-server-0'     
INFO[0018] Starting agents...                           
INFO[0018] Starting helpers...                          
INFO[0018] Starting Node 'k3d-k3s-default-serverlb'     
INFO[0019] (Optional) Trying to get IP of the docker host and inject it into the cluster as 'host.k3d.internal' for easy access 
WARN[0022] Failed to patch CoreDNS ConfigMap to include entry '172.18.0.1 host.k3d.internal': Exec process in node 'k3d-k3s-default-server-0' failed with exit code '1' 
INFO[0022] Successfully added host record to /etc/hosts in 2/2 nodes 
INFO[0022] Cluster 'k3s-default' created successfully!  
INFO[0022] --kubeconfig-update-default=false --> sets --kubeconfig-switch-context=false 
INFO[0022] You can now use it like this:                
kubectl config use-context k3d-k3s-default
kubectl cluster-info

Then, cluster polling begins with kubectl get serviceaccount default every 1 second:

  Error from server (NotFound): serviceaccounts "default" not found
  Error from server (ServiceUnavailable): the server is currently unable to handle the request (get serviceaccounts default)
  Error from server (ServiceUnavailable): the server is currently unable to handle the request (get serviceaccounts default)
  Error from server (ServiceUnavailable): the server is currently unable to handle the request (get serviceaccounts default)
  Error from server (ServiceUnavailable): the server is currently unable to handle the request (get serviceaccounts default)
  Error from server (NotFound): serviceaccounts "default" not found
…………

And so until the build times out.

The only essential difference I have found is this — though, most likely, unrelated:

In newly broken builds:

INFO[0017] Starting Node 'k3d-k3s-default-serverlb'     
INFO[0018] (Optional) Trying to get IP of the docker host and inject it into the cluster as 'host.k3d.internal' for easy access 

WARN[0021] Failed to patch CoreDNS ConfigMap to include entry '172.18.0.1 host.k3d.internal': Exec process in node 'k3d-k3s-default-server-0' failed with exit code '1' 

INFO[0021] Successfully added host record to /etc/hosts in 2/2 nodes 
INFO[0021] Cluster 'k3s-default' created successfully!  

In old & new successful builds:

INFO[0014] Starting Node 'k3d-k3s-default-serverlb'     
INFO[0015] (Optional) Trying to get IP of the docker host and inject it into the cluster as 'host.k3d.internal' for easy access 
INFO[0018] Successfully added host record to /etc/hosts in 2/2 nodes and to the CoreDNS ConfigMap 
INFO[0018] Cluster 'k3s-default' created successfully!  

GitHub Actions, Ubuntu 20.04.2.

K3d version 4.4.6, 4.4.4, 4.4.3.

Docker:

Client:
 Version:           20.10.6+azure
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        370c28948e3c12dce3d1df60b6f184990618553f
 Built:             Fri Apr  9 17:01:36 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.6+azure
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd246c3ab53105434eef8ffe997b6fd14dc6
  Built:            Fri Apr  9 22:06:18 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6+azure
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        

(e.g. here)

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.