I installed gcloud SDK with brew cask install google-cloud-sdk
$ gcloud container clusters get-credentials my-gke-cluster --region europe-west4-c
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials)
Unable to write file [/Users/xxxxx/my-repo]: [Errno 21] Is a directory: '/Users/xxxxx/my-repo'
Now all permissions of the folder and recursive files are restricted to 600 (drw-------). Tried to reinstall gcloud but with no effect on its behavior.
I assume you're using macOS and I'm unfamiliar with it.
The gcloud container clusters get-credentials command should write to a file called ${HOME}/.kube/config.
The error suggests that it's trying to write the credentials to /Users/xxxxx/my-repo and this is determined by the value of ${KUBECONFIG}. Have you changed either ${KUBECONFIG} or your ${HOME} environment variable? You should be able to printf "HOME=${HOME}\nKUBECONFIG=${KUBECONFIG}" to inspect these.
You may be able to choose a different destination by adjust the value of KUBECONFIG. Perhaps set this to /Users/xxxxx and try the command again.
Ultimately, this is some sugar to update the local configuration file. It should be possible to create this manually if needs be. If the above don't work, I can update this answer with more details.
Related
I have a specific request of running Helm template command in environment with filesystem access read-only on the regular location where Helm cache is stored (I'm executing this command inside AWS Lambda).
An error that I get is:
Error: mkdir .cache: read-only file system
Now, to overcome this problem, my idea is to:
either disable cache when running specific command
point HELM_CACHE_HOME to location which is not read-only (mounted location from EFS file system)
Unfortunately, I was unable to find a way to disable a cache and following command doesn't work (even when running it locally, without any lambda environment):
mkdir -p /tmp/helm/.cache/helm
HELM_CACHE_HOME=/tmp/helm/.cache/helm helm template elasticsearch elastic/elasticsearch --dry-run
ls -la /tmp/helm/.cache/helm
total 0
Any way to do this?
Thanks
Eventually, I've figured out that I've used incorrect environment variable.
For Helm 3, correct variable is:
XDG_CACHE_HOME
Reference: https://helm.sh/docs/faq/#xdg-base-directory-support
However, even if this works, docs say that HELM_CACHE_HOME should also work (which is not the case).
I'm just fished connect to my kubernete.
But affter that I need to change the gcloud location from /Download to /usr folder.
Next, I run install.sh file for update the new location in .bash_profile.
Then I check gcloud command. It working well
But when I run kubectl get pod. The error showing.
Unable to connect to the server: error executing access token command "/Users/panda/Downloads/google-cloud-sdk/bin/gcloud config config-helper --format=json": err=fork/exec /Users/panda/Downloads/google-cloud-sdk/bin/gcloud: no such file or directory output= stderr=
Hmm, how to update the location of gcloud sdk for solve this problem.
Thanks for your help.
In your Kubeconfig file (probably in ~/.kube/config) you’ll see it has the old path to your gcloud CLI. Update that file with the new path.
I am trying to debug a java app on GKE cluster through stack driver.
I have created a GKE cluster with Allow full access to all Cloud APIs
I am following documentation: https://cloud.google.com/debugger/docs/setup/java
Here is my DockerFile:
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} alnt-watchlist-microservice.jar
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/alnt-watchlist-microservice.jar"]
In documentation, it was written to add following lines in DockeFile:
RUN mkdir /opt/cdbg && \
wget -qO- https://storage.googleapis.com/cloud-debugger/compute-java/debian-wheezy/cdbg_java_agent_gce.tar.gz | \
tar xvz -C /opt/cdbg
RUN java -agentpath:/opt/cdbg/cdbg_java_agent.so
-Dcom.google.cdbg.module=tpm-watchlist
-Dcom.google.cdbg.version=v1
-jar /alnt-watchlist-microservice.jar
When I build DockerFile, It fails saying tar: invalid magic , tar: short read.
In stackdriver debug console, It always show 'No deployed application found'. Which application it will show? I have already 2 services deployed on my kubernetes cluster.
I have already executed
gcloud debug source gen-repo-info-file --output-directory="WEB-INF/classes/
in my project's directory.
It generated source-context.json. After its creation, I tried building docker image and its failing.
The debugger will be ready for use when you deploy your containerized app. You are getting No deployed application found error because your debugger agent is failing to download or unzip in dockerfile.
Please check this discussion to resolve the tar: invalid magic , tar: short read. error.
Unfortunately it looks like Alpine isn't regularly tested with Debugger. There's a sample setup here that might help you: https://github.com/GoogleCloudPlatform/cloud-debug-java#alpine-linux
I resolved the issue.
Firstly, you will have to use java image "gcr.io/google-appengine/openjdk" instead of Alpine one.
Secondly,
I was putting entry points without comma separated (Basically in wrong format)
ENTRYPOINT ["java","-agentpath:/opt/cdbg/cdbg_java_agent.so", "-Djava.security.egd=file:/dev/./urandom" ,"-Dcom.google.cdbg.module=watchlist"]
I'm performing usual operation of fetching kubernetes cluster credentials from GCP. The gcloud command doesn't fetch the credentials and surprisingly updates the ownership of the local directory:
~/tmp/1> ls
~/tmp/1> gcloud container clusters get-credentials production-ng
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials) Unable to write file [/home/vladimir/tmp/1]: [Errno 21] Is a directory: '/home/vladimir/tmp/1'
~/tmp/1> ls
ls: cannot open directory '.': Permission denied
Other commands, like gcloud container clusters list work fine. I've tried to reinstall the gcloud.
This happens if your KUBECONFIG has an empty entry, like :/Users/acme/.kube/config
gcloud resolves the empty value as the current directory, changes permissions and tries to write to it
Reported at https://issuetracker.google.com/issues/143911217
It happened to be a problem with kubectl. Reinstalling it solved this strange issue.
If you, like me, have stuck with strange gcloud behavior, following points could help to track an issue:
Checking alias command and if it's really pointing to the intended binary;
Launch separate docker container with gsutil and feed it your config files. If the gcloud container clusters get-credentials ... runs smoothly there, than it's the problem with binaries (not configuration):
docker run -it \
-v $HOME/.config:/root/.config \
-v $HOME/.kube:/root/.kube google/cloud-sdk:217.0.0-alpine sh
Problem with binary can be solved just by reinstalling/updating;
If it's a problem with configs, then you could back them up and reinstall kubectl / gsutil from scratch using not just apt-get remove ..., but apt-get purge .... Be aware: purge removes config files!
Hope this would help somebody else.
How can I update the gcloud components programmatically within a shell script?
Calling gcloud components update requires an user entry, e.g.:
$ gcloud components update
The following components will be installed:
--------------------------------------------
| kubectl (Linux, x86_64) | 1.0.1 | 4.5 MB |
--------------------------------------------
For the latest release notes, please visit:
https://dl.google.com/dl/cloudsdk/release/RELEASE_NOTES
Do you want to continue (Y/n)?
I can't find an argument for gcloud to enforce the update.
You're looking for the --quiet flag.
From gcloud --help:
--quiet, -q
Disable all interactive prompts when running gcloud commands. If input
is required, defaults will be used, or an error will be raised.
This is generally a flag you'll want for non-interactive contexts.
You may also set the CLOUDSDK_CORE_DISABLE_PROMPTS environment variable to a non-empty value:
export CLOUDSDK_CORE_DISABLE_PROMPTS=1
gcloud components update # This works for all gcloud commands
If you encounter this problem while running a gcloud command on a Continuous Integration (CI) server, one thing you can try is run with a Docker image that already contains the components you need. Thus you can avoid having to update gcloud components.
For example, if you're trying to run gcloud beta firebase test android run, you could use the image: google/cloud-sdk:latest because at https://github.com/GoogleCloudPlatform/cloud-sdk-docker it shows :latest contains gcloud Beta Commands.
I tested this on Gitlab hosted CI (.gitlab-ci.yml) and it worked.