After I have run helm list I got following error:
Error: incompatible versions client[v2.9.0] server[v2.8.2]
I did a helm init to install the compatible tiller version
"Warning: Tiller is already installed in the cluster.
(Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)".
Any pointers?
Like the OP, I had this error:
$ helm list
Error: incompatible versions client[v2.10.0] server[v2.9.1]
Updating the server wasn't an option for me so I needed to brew install a previous version of the client. I hadn't previously installed client[v2.9.1] (or any previous client version) and thus couldn't just brew switch kubernetes-helm 2.9.1. I ended up having to follow the steps in this SO answer: https://stackoverflow.com/a/17757092/2356383
Which basically says
Look on Github for the correct kubernetes-helm.rb file for the version you want (2.9.1 in my case): https://github.com/Homebrew/homebrew-core/search?q=kubernetes-helm&type=Commits
Click the commit hash (78d6425 in my case)
Click the "View" button to see the whole file
Click the "Raw" button
And copy the url: https://raw.githubusercontent.com/Homebrew/homebrew-core/78d64252f30a12b6f4b3ce29686ab5e262eea812/Formula/kubernetes-helm.rb
Now that I had the url for the correct kubernetes-helm.rb file, I ran the following:
$ brew unlink kubernetes-helm
$ brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/78d64252f30a12b6f4b3ce29686ab5e262eea812/Formula/kubernetes-helm.rb
$ brew switch kubernetes-helm 2.9.1
Hope this helps someone.
To upgrade your tiller version to the same version of the client, just run helm init --upgrade
NOTE: If you're trying to downgrade the server version to match your local client version, run the following instead:
helm init --upgrade --force-upgrade
Another alternative, if changing the server version is not an option, is to use the
helm installer script
The script lets you chose a specific version like so
./get_helm.sh -v v2.13.1
Another approach to using different versions through Docker.
https://hub.docker.com/r/alpine/helm
Example: list helm packages installed
docker run -it --rm \
-v ~/.kube/config:/root/.kube/config \
-v ~/.helm:/root/.helm alpine/helm:2.9.1 \
list
This is a long command; but it can be shortened with an alias
alias helm_2_9_1="docker run -ti --rm \
-v $(pwd):/apps -v ~/.kube/config:/root/.kube/config \
-v ~/.helm:/root/.helm alpine/helm:2.9.1"
And then the command is
helm_2_9_1 list
This answer is for who want to choose(downgrade) helm client version, and the brew install is not work.You can just manually install the binary file from here.
example:
you can unlink the current helm
brew unlink kubernetes-helm
choose and download the helm version you want in github helm------v2.8.2
unzip the file and put the helm unix executable binary file into /usr/local/bin directory
go to the directory you just downloaded
cd /Users/your_name/Downloads
unzip the file
gunzip -c helm-v2.8.2-darwin-amd64.tar.gz | tar xopf -
copy to the bin directory
cp darwin-amd64/helm /usr/local/bin
now you will see the right version of helm you want
helm version
For those having installed their helm client with snap, to downgrade/upgrade it to a specific version you can simply:
Uninstall it: snap remove helm
Check the available versions: snap info helm
Install the one you want: snap install helm --channel=X.X/stable --classic
This probably isn't the most advanced answer... but my team runs kubernetes clusters that already have tiller installed. While setting up a new laptop, I wanted my helm to match the tiller version, so I found it like this:
TILLER_POD=`kubectl get pods -n kube-system | grep tiller | awk '{print $1}'`
kubectl exec -n kube-system $TILLER_POD -- /tiller -version
Then I just used the normal helm install instructions from that release number (being on Linux, its basically just curl and unzip to /usr/local/bin).
If you are windows user and installed helm through choco, firstly go its folder (mine is C:\ProgramData\chocolatey) and delete helm.exe from bin folder.
Then, corresponding heml.exe file should be downloaded. By using the above comments, decide the location where you will download exe from. For instance, I used that path: https://get.helm.sh/helm-v2.14.3-windows-amd64.tar.gz
Finally extract the helm.exe from tar and move into choco bin folder. Of course, you can directly add this exe into the path.
I experienced same issue, but in my case I wanna only to upgrade Tiller to specific version (because helm client is running remotely).
So, error was:
Error: UPGRADE FAILED: incompatible versions client[v2.11.0] server[v2.9.1]
Accordingly to documentation I've run:
$ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:v2.11.0
deployment.extensions/tiller-deploy image updated
Documentation reference:
https://helm.sh/docs/install/#upgrading-tiller
Related
I am trying to install kustomize v3.2.1 in Mac, but I am getting the following error when I do these steps.
wget "https://github.com/kubernetes-sigs/kustomize/archive/refs/tags/kustomize/v3.2.1.tar.gz" Untar the source
tar xzf xxxxx.tar.gz cd xxxxxx make install
Output:
go install /cmd/kustomize
make: go: No such file or directory
make: *** [install] Error 1
How can I install this version without any issues? Thanks!
I need to recreate this question as I wasnt able to answer my previous question. So the command below is not working with specific version of kustomize
# install a particular version
brew install kustomize#v3.2.1
In brew, there is only the latest version available
I downloaded the version from release into my temp folder. No need to install anything
Optionally you can rename kustomize_kustomize.v3.2.1_darwin_amd64 to kustomize.
luuk#mini temp % ./kustomize_kustomize.v3.2.1_darwin_amd64 version
Version: {Version:kustomize/v3.2.1 GitCommit:d89b448c745937f0cf1936162f26a5aac688f840 BuildDate:2019-09-27T00:10:52Z GoOs:darwin GoArch:amd64}
luuk#mini temp % ./kustomize_kustomize.v3.2.1_darwin_amd64 help
Manages declarative configuration of Kubernetes.
See https://sigs.k8s.io/kustomize
Usage:
kustomize [command]
Available Commands:
build Print configuration per contents of kustomization.yaml
config Config Kustomize transformers
create Create a new kustomization in the current directory
edit Edits a kustomization file
help Help about any command
version Prints the kustomize version
Flags:
-h, --help help for kustomize
Use "kustomize [command] --help" for more information about a command.
luuk#mini temp %
I recently installed microk8s, and enabled helm3 and dns addons on microk8s.
Deployment from stable/chart works fine but any deployment from bitnami/chart fails.
OS: Ubuntu 20.04.1 LTS -- microk8s: 1.19/stable
microk8s.helm3 install my-release bitnami/jenkins
=> Error: parse error at (jenkins/charts/common/templates/_secrets.tpl:84): function "lookup" not defined
microk8s.helm3 install my-release bitnami/magento
=> Error: parse error at (magento/charts/elasticsearch/charts/common/templates/_secrets.tpl:84): function "lookup" not defined
There was a bug reported here and here which was caused by the conditional inclusion of lookup into the function map.
A fix for it was merged here and is now available from Helm version 3.2.0.
So, in order to fix this issue you should update your Helm to version 3.2.0 or newer.
Faced with the same issue while installing Kafka. The solution is to install a newer version of Helm 3 and use its commands with --kubeconfig specified:
microk8s config > kubeconfig.yaml
sudo snap install helm --classic
/snap/bin/helm repo add bitnami https://charts.bitnami.com/bitnami
/snap/bin/helm install --wait kafka bitnami/kafka --set metrics.jmx.enabled=true --kubeconfig kubeconfig.yaml
Try to install helm3 with snap and then link it to microk8s:
sudo snap install helm --classic
sudo mkdir /var/snap/microk8s/current/bin
sudo ln -s /snap/bin/helm /var/snap/microk8s/current/bin/helm
There seems to be some issues using helm3.0 instead of helm 3.1
thanks for all of the information
I fixed this by using the snap helm (version 3.6.3) on ubuntu
microk8s config > ~/.kube/config
chmod go-r ~/.kube/config
sudo snap install helm --classic
then doing the helm repo add, update, and install charts without errors
So recently (5th September) the Alpine Linux package repo was updated to postgresql-client 12.4
I'm referencing version 12.3 in my Dockerfile (apk add postgresql-client=~12.3). Is it not possible to install that version now?
I'd like to update on my time and terms, why should I be forced to update now? Is there another repository I can add to use the older version?
Thanks
Unfortunately, Alpine packages are always updated in place to the latest version, and older versions are discarded. This could be painful, indeed...
Usually, when a package is updated, it's updated with all Alpine distro versions that it's compatible to. For example, postgresql-client was bumped to 12.4-r0 on edge, v3.12 and v3.11, but on Alpine v3.10 repos you'll still find 11.9-r0. In case this was enough, the old version could be installed from the desired repository, as long as it lasts, using:
apk add postgresql-client=11.9-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/v3.10/main
However, since 12.3 doesn't live in the official Alpine repositories anymore, you could rely on an external Docker image, instead.
Luckily, the postgres official images has version tags, and you can find the desired Alpine image for 12.3:
$ wget -q https://registry.hub.docker.com/v1/repositories/postgres/tags -O - | jq -r '.[].name' | grep 12.3
12.3
12.3-alpine
Therefore, you can use FROM:postgres:12.3-alpine to get the desired version from.
In tougher cases, where the Alpine package version is updated, and couldn't be found in other images, the only resort may be building from source.
for example; the latest dnsmasq version ins 2.84-r0 at now, if you install 2.83-r0, will:
$ docker run --rm -ti alpine:3.13
$ apk add 'dnsmasq-dnssec==2.83-r0'
fetch https://mirrors.aliyun.com/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
fetch https://mirrors.aliyun.com/alpine/v3.13/community/x86_64/APKINDEX.tar.gz
ERROR: unable to select packages:
dnsmasq-dnssec-2.84-r0:
breaks: world[dnsmasq-dnssec=2.83-r0]
The best thing you can achieve is using repositories of the earlier releases, at the websiete https://pkgs.alpinelinux.org/packages to search the old version, will find 2.83-r0 in https://pkgs.alpinelinux.org/packages?name=dnsmasq&branch=v3.12.
so add the old repo
$ echo 'http://dl-cdn.alpinelinux.org/alpine/v3.12/main' >> /etc/apk/repositories
$ apk add 'dnsmasq-dnssec==2.83-r0'
fetch http://mirrors.aliyun.com/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.aliyun.com/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/3) Installing gmp (6.2.0-r0)
(2/3) Installing nettle (3.5.1-r1)
(3/3) Installing dnsmasq-dnssec (2.83-r0)
Executing dnsmasq-dnssec-2.83-r0.pre-install
Executing busybox-1.31.1-r16.trigger
OK: 7 MiB in 17 packages
Another solution based on the answer of #valiano.
For upgrading postgresql to a newer version, it is recommended to use the higher version pg_dump binaries. But how to get these into your image?
This works for me:
Dockerfile:
ARG VERSION=10
ARG UPGRADE_VERSION=11
ARG TYPE
###############################################################
# Normal server
###############################################################
FROM postgres:${VERSION}-alpine AS server
RUN apk update \
&& apk add --upgrade apk-tools \
&& apk upgrade --available
COPY /rootfs/ /
###############################################################
# Upgrade version with upgrade executables
###############################################################
FROM postgres:${UPGRADE_VERSION}-alpine AS upgrade_version
RUN apk update \
&& apk add --upgrade apk-tools \
&& apk upgrade --available
###############################################################
# Add postgresql upgrade client executables to upgrade_server_layer
###############################################################
FROM server AS upgrade_server
RUN mkdir -p /usr/local/postgresql/upgrade
COPY --from=upgrade_version /usr/local/bin/pg* /usr/local/postgresql/upgrade/
###############################################################
# Final version
###############################################################
FROM ${TYPE}server AS final
Then build your normal server as:
docker build --build-arg TYPE= --build-arg VERSION=11 --build-arg UPGRADE_VERSION=12 -t my_normal_server:11 .
And a server with upgrade binaries, to make the dumpfile:
docker build --build-arg TYPE=upgrade_ --build-arg VERSION=10 --build-arg UPGRADE_VERSION=11 -t my_upgrade_server:10 .
Upgrade scenario if current version is postgresql 10 and you want to upgrade to 11:
Build an upgrade version and a normal version.
Stop the postgresql 10 container and replace it with the my_upgrade_version:10
Create a dumpfile with the /usr/local/postgresql/upgrade/pg_dump.
Create a new postgresql 11 container with my_normal_version:11 with access to the dumpfile and use pg_restore to restore the created dumpfile.
About making a dry single-point-of-entry for fixed package versions:
I use the following method, where I have an .env file where I store the PG major and minor version. I only need to update the .env-file entry with preferred version numbers and rebuild my images to upgrade the Postgres.
As long as the package is present with the corresponding version in the dockerhub and the PG version itself isn't deprecated by the alpine repositories or sth:
Step 1: Specify the PG version in .env file as single point of entry:
PG_MAJOR_VERSION=14
PG_MINOR_VERSION=5
Step 2: Reference the db-package inside the docker-compose:
services:
db:
image: postgres:${PG_MAJOR_VERSION}.${PG_MINOR_VERSION}-alpine
Step 3: Use the variables inside the Dockerfile itself if needed:
ARG RUBY_VERSION
ARG DISTRO_NAME
FROM ruby:${RUBY_VERSION}-${DISTRO_NAME}
# Need to define the args again:
ARG DISTRO_NAME
ARG PG_MAJOR_VERSION
RUN apk add --update build-base bash bash-completion libffi-dev tzdata postgresql$PG_MAJOR_VERSION-client postgresql$PG_MAJOR_VERSION-dev nodejs npm yarn
NB! The FROM clause loses the ARG-variables defined before it. Therefore if you need them later then you need to define them again after the FROM-clause. This issue is described in more detail in this Github issue
Depending on the packages you wish to install you can specify the minor version or other suffixes as needed (for ex for postgresql15-client-15.1-r0 and postgresql15-dev-15.1-r0: package etc)
Where from should I download virtualenv to use locally from source using wget?
I'm having troubles downloading virtualenv from the command line.
Info: if you search for virtualenv you will find the site for the stable version and its installation guide which is just equals to the latest version installation guide.
To install locally it describe this :
To install version X.X globally from source:
$ curl -O https://pypi.python.org/packages/source/v/virtualenv/virtualenv-X.X.tar.gz
$ tar xvfz virtualenv-X.X.tar.gz
$ cd virtualenv-X.X
$ [sudo] python setup.py install
To use locally from source:
$ curl -O https://pypi.python.org/packages/source/v/virtualenv/virtualenv-X.X.tar.gz
$ tar xvfz virtualenv-X.X.tar.gz
$ cd virtualenv-X.X
$ python virtualenv.py myVE
I'm using wget instead curl but should not be problem at all with this. Am I wrong?
The only place where I can download it (and not from the command line) is from here.
I'm typing the url correctly.
Different virtualenv versions at the url return the same not found:
HTTP request sent, awaiting response... 404 Not Found
2017-07-21 17:53:09 ERROR 404: Not Found.
Please note that I have already downloaded the tar.gz so I don't need it right now but I'm not sure if this is a broken link issue or I'm forgotten something else at the download command. I will not associate an issue to virtualenv just because a broken link but I need to know why this is not working.
EDIT: I can't download it using wget from ..python..packages/source/v/virtualenv etc.
TARGET="https://pypi.python.org/simple/virtualenv/"
PATTERN="virtualenv-15.1.0.tar.gz"
wget --recursive --no-directories --accept=$PATTERN $TARGET
Yes, curl and wget are equivalent for what you're trying.
No, you can download from anywhere. From PyPI, e.g.
There is no functional difference between pip install virtualenv and what you're trying to do but the former is simpler and less error-prone so why bother with manual labour?
I tried to install the latest release tarball of Mesos on CentOS 6.4 with no luck. It ended up in all sorts of failures in trying to find jvm & jni bindings. Is there any instructions on how to install Mesos on RHEL or CentOS ?
I couldn't find any instructions around so I thought I would troubleshoot all through my way and thought of documenting it here so it can save your time.
First things first, load your CentOS box with essential build tools to get started
$ sudo yum groupinstall "Development tools"
Get Java and python dependencies installed
$ sudo yum install java-1.6.0-openjdk.x86_64 java-1.6.0-openjdk-devel.x86_64 python python-devel libcurl libcurl-devel
Get the latest Mesos tarball
$ wget http://mirror.nus.edu.sg/apache/mesos/0.13.0/mesos-0.13.0.tar.gz
$ tar -xzvf mesos-0.13.0.tar.gz
$ cd mesos-0.13.0
Before you can build Mesos, you need to set correct JAVA binding paths
$ export JAVA_HOME=/usr
$ export JAVA_LDFLAGS="-L/usr/lib/jvm/java-1.6.0/jre/lib/amd64/server -R/usr/lib/jvm/java-1.6.0/jre/lib/amd64/server -ljvm"
$ export JAVA_CPPFLAGS="-I/usr/lib/jvm/java-1.6.0/include -I/usr/lib/jvm/java-1.6.0/include/linux"
$ export LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0/jre/lib/amd64/server:$LD_LIBRARY_PATH
Configure and build it
$ ./configure
$ make
After you have built Mesos, it is advisable that you build and run the tests, this will make sure that what you have installed meets all the requirements
$ make check
If the checks are successful, You are just one step away from installing it in your system installation paths
$ make install
To learn how to use Mesos , go here http://mesos.apache.org/gettingstarted/
For those who prefer installing from RPM's, here is a link to a number of different releases for different Linux flavors: http://mesosphere.io/downloads/ For example, for Centos64:
wget http://downloads.mesosphere.io/master/centos/6/mesos_0.14.2_x86_64.rpm
sudo rpm -Uvh mesos_0.14.2_x86_64.rpm
I also had to set my LD_LIBRARY_PATH, though to a slightly different value. Check yours.
Python bindings can also be downloaded from the first link above:
wget http://downloads.mesosphere.io/master/centos/6/mesos_0.14.2_x86_64.egg
sudo easy_install mesos_0.14.2_x86_64.egg