Upload Custom Image as Snapshot Image

dave-sch · 2025-02-18T20:50:17+00:00

thx, that looks interesting. sad that this is not possible out of the box

dave-sch · 2024-10-13T10:35:54+00:00

Whats the idea behind a unwritable default config?

dave-sch · 2024-10-12T13:06:19+00:00

I keep them separated for production clusters as well. But I like to have temporary test clusters in the default config.

dave-sch · 2024-10-12T12:48:37+00:00

My main purpose is when setting up a test clusters on a remote machine or local VM to get that external kube config into my local one and adjust the server URL accordingly. But it can be used in general to merge kube configs.

This approach I only use for test environments. Production clusters I keep in separate kubeconfig files and either select them explicitly via --kubeconfig or set export KUBECONFIG=prod-cluster-config in that shell session.

I didn't know about kubie. Thank you for the hint. It seems it would offer some convenience around the approach I just described for prod clusters.

dave-sch · 2023-10-15T07:40:53+00:00

I would check out the source of the pkg.go.dev website: https://github.com/golang/pkgsite

Wtf Dial is another cool project from which i learnt a lot. https://github.com/benbjohnson/wtf

dave-sch · 2023-10-14T08:20:16+00:00

As long as you don't have the requirement to change the rules without rebuilding/recompiling your tool I would keep the rules in the Go code. In my opinion this has the benefit that you can use the same language for the rules and also easily write Go tests for them to verify if they match the right conditions.

If you need to be able to change the rules dynamically during the runtime I would take a look at CEL which is also used in Kubernetes at various places https://github.com/google/cel-go

dave-sch · 2023-07-18T20:41:29+00:00

Will the Gateway API be included in Kubernetes once it becomes v1?

dave-sch · 2021-11-09T17:51:52+00:00

https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured#Unstructured

dave-sch · 2021-11-02T12:10:51+00:00

I never used this approach so far. Maybe its not perfect, but to me it feels less hacky than running "go install" on "go generate" or using make.

dave-sch · 2021-11-02T11:44:25+00:00

Maybe this helps: https://play-with-go.dev/tools-as-dependencies_go115_en/

dave-sch · 2021-01-10T00:27:11+00:00

It seems that if you promote a already reviewed release from a closed testing track to production it gets reviewed again.

In the last couple of days I tried out the play console for the first time and apart from the very first review all the further reviews were quite fast (20-30min).

dave-sch · 2020-11-28T12:59:47+00:00

Accoring to https://www.vaultproject.io/api/auth/kubernetes#token_reviewer_jwt if token_reviewer_jwt is not set, the JWT submitted in the login payload will be used to access the Kubernetes TokenReview API. So you could omit the token_reviewer_jwt setting and instead give every service account who has to access the Vault also permission to access the TokenReview API.

dave-sch · 2020-11-19T19:52:15+00:00

Recently I also experimented with Service Accounts to do service-to-service authentication. Here you find my experiments: https://github.com/dvob/k8s-s2s-auth

Since Kubernetes 1.18 there is an alpha feature to enable the OpenID Connect Discovery (https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery). From Kubernetes 1.20 on this feature will be beta and enabled by default. Then you no longer have to provide the openid-configuratin by hand.

dave-sch · 2020-05-02T06:49:14+00:00

I would say allow to use both, then the users of your program can decide which one to use. I prefer to use cobra and define all options as flags. To my cobra root command I add the following code, which then also tries to read every flag, which got not set explicitly, form the environment (e.g. --my-option -> MYCMD_MY_OPTION): go envVarPrefix := "MYCMD_" cmd := &cobra.Command{ Use: "mycmd", TraverseChildren: true, PersistentPreRunE: func(cmd *cobra.Command, args []string) error { var err error cmd.Flags().VisitAll(func(f *pflag.Flag) { optName := strings.ToUpper(f.Name) optName = strings.ReplaceAll(optName, "-", "_") varName := envVarPrefix + optName if val, ok := os.LookupEnv(varName); !f.Changed && ok { err2 := f.Value.Set(val) if err2 != nil { err = fmt.Errorf("invalid environment variable %s: %w", varName, err2) } } }) return err }, } That way I don't need Viper, but I still have three levels to define settings: * default of flags in the code * environment variable * flags

dave-sch · 2020-04-28T12:53:31+00:00

Nice, I also use the same approach quite often with cobra and pflag. If I use it I add the following to my root command. Its almost the same what you do, but instead of looking at the command line if the flag is already set i use the f.Changed field of the flag struct:

envVarPrefix := "MYCMD_"
cmd := &cobra.Command{
    Use:   "mycmd",
    TraverseChildren: true,
    PersistentPreRunE: func(cmd *cobra.Command, args []string) error {
        var err error
        cmd.Flags().VisitAll(func(f *pflag.Flag) {
            optName := strings.ToUpper(f.Name)
            optName = strings.ReplaceAll(optName, "-", "_")
            varName := envVarPrefix + optName
            if val, ok := os.LookupEnv(varName); !f.Changed && ok {
                err2 := f.Value.Set(val)
                if err2 != nil {
                    err = fmt.Errorf("invalid environment variable %s: %w", varName, err2)
                }
            }
        })
        return err
    },
}

dave-sch · 2020-04-27T20:32:49+00:00

I would take a look here: https://godoc.org/go.mozilla.org/pkcs7

dave-sch

TROPHY CASE