This list has moved to a GitHub repo for easier tracking: https://github.com/coreos/awesome-kubernetes-extensions
Please comment below if you are using Kubernetes Third-Party Resources and I will add you to the list.
Known Users:
This playbook has been removed as it is now very outdated. |
#!/bin/bash | |
BGreen='\e[1;32m' # Green | |
BRed='\e[1;31m' # Red | |
Color_Off='\e[0m' # Text Reset | |
function setStatusMessage { | |
printf "${IRed} --> ${BGreen}$1${Color_Off}\n" 1>&2 | |
} | |
function triggerError { |
This list has moved to a GitHub repo for easier tracking: https://github.com/coreos/awesome-kubernetes-extensions
Please comment below if you are using Kubernetes Third-Party Resources and I will add you to the list.
Known Users:
<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0"> | |
<dict> | |
<!-- Launch Daemon do not always have access to all the path variables | |
As a results, scripts will sometimes fail if the you are using path variables inside them | |
To enable the script to have access to all path variables, open up a terminal and type in --> | |
<!-- echo $PATH --> | |
<!-- You can opt to filter out some of the path variables which are not required by script--> | |
<key>EnvironmentVariables</key> |
Update: This gist has graduated to a full blog post over on my site -> https://blog.alexellis.io/get-private-kubectl-access-anywhere/
This tutorial shows you how to punch your private Kubernetes API server out to the Internet, so that you can manage your cluster from anywhere, just like you would with a cloud offering.
These steps have been tested with kubeadm, k3s and OpenShift.
You'll need:
I run several K8S cluster on EKS and by default do not setup inbound SSH to the nodes. Sometimes I need to get into each node to check things or run a one-off tool.
Rather than update my terraform, rebuild the launch templates and redeploy brand new nodes, I decided to use kubernetes to access each node directly.
I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:
package cache | |
import ( | |
"sync" | |
"time" | |
) | |
// Cache is a basic in-memory key-value cache implementation. | |
type Cache[K comparable, V any] struct { | |
items map[K]V // The map storing key-value pairs. |