I'm trying to connect to Hyperkit to check containers running on this VM.
All I'm getting now is [screen is terminating]
Here is what I do:
MacBook-Pro-Karol: ~
→ minikube start --driver=hyperkit
😄 minikube v1.12.3 na Darwin 10.15.6
✨ Using the hyperkit driver based on user configuration
👍 Starting control plane node minikube in cluster minikube
🔥 Creating hyperkit VM (CPUs=2, Memory=4000MB, Disk=20000MB) ...
🐳 preparing Kubernetes v1.18.3 on Docker 19.03.12...
🔎 Verifying Kubernetes components...
🌟 Enabled addons: default-storageclass, storage-provisioner
🏄 Ready! kubectl is configured to be used with "minikube".
MacBook-Pro-Karol: ~
→ sudo screen /Users/karol/.minikube/machines/minikube/tty
Password:
[screen is terminating]
MacBook-Pro-Karol: ~
→ screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
[screen is terminating]
Cannot exec '/Users/karol/Library/Containers/com.docker.docker/Data/vms/0/tty': Permission denied
→ sudo screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
Password:
[screen is terminating]
Cannot exec '/Users/karol/Library/Containers/com.docker.docker/Data/vms/0/tty': Operation not permitted
Any help would be appreciated.
You can use minikube ssh to login in to VM that minikube runs in:
Log into or run a command on a machine with SSH; similar to
‘docker-machine ssh’.
minikube ssh [flags]
and then use docker ps to check the running containers inside this VM:
$ docker ps | grep kube-api
f53aebd26287 7e28efa976bd "kube-apiserver --ad…" 16 minutes ago k8s_kube-apiserver_kube-apiserver-minikube_kube-system_8009646ba816631d0677c2668886baad_1
12188a523d12 k8s.gcr.io/pause:3.2 "/pause" 16 minutes ago k8s_POD_kube-apiserver-minikube_kube-system_8009646ba816631d0677c2668886baad_1
Related
Is anyone else having this problem when running podman?
I used normally and now when running
podman machine start
this error appears:
Print
I tried to change the podman configuration and increase the resources but I didn't authorize it;
I'm not sure what's going on but here's what I did:
➜ ~ podman system connection list
Name URI Identity Default
podman-machine-default ssh://core#localhost:51014/run/user/501/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default true
podman-machine-default-root ssh://root#localhost:51014/run/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default false
➜ ~ podman machine rm podman-machine-default
The following files will be deleted:
/Users/xxxxx/.ssh/podman-machine-default
/Users/xxxxx/.ssh/podman-machine-default.pub
/Users/xxxxx/.config/containers/podman/machine/qemu/podman-machine-default.ign
/Users/xxxxx/.local/share/containers/podman/machine/qemu/podman-machine-default_fedora-coreos-36.20220918.2.2-qemu.x86_64.qcow2
/Users/xxxxx/.local/share/containers/podman/machine/podman-machine-default/podman.sock
/Users/xxxxx/.config/containers/podman/machine/qemu/podman-machine-default.json
Are you sure you want to continue? [y/N] y
➜ ~ podman system connection list
Name URI Identity Default
At this point I switched to the Activity Monitor and killed the qemu service. Then I ran the following:
➜ ~ podman machine init
Downloading VM image: fedora-coreos-37.20230122.2.0-qemu.x86_64.qcow2.xz: done
Extracting compressed file
Image resized.
Machine init complete
To start your machine run:
podman machine start
➜ ~ podman system connection list
Name URI Identity Default
podman-machine-default ssh://core#localhost:51014/run/user/501/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default true
podman-machine-default-root ssh://root#localhost:51014/run/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default false
➜ ~ docker machine start
Starting machine "podman-machine-default"
Waiting for VM ...
Mounting volume... /Users/xxxxx:/Users/xxxxx
This machine is currently configured in rootless mode. If your containers
require root permissions (e.g. ports < 1024), or if you run into compatibility
issues with non-podman clients, you can switch using the following command:
podman machine set --rootful
API forwarding listening on: /var/run/docker.sock
Docker API clients default to this address. You do not need to set DOCKER_HOST.
Machine "podman-machine-default" started successfully
Hope this helps.
I'm following a Kubernetes tutorial, and cannot run first command (minikube start --vm-driver=hyperkit). I'm using a MacBook Pro Intel on macOs Monterey. I cannot make it work because of TLS error.
$ minikube start --vm-driver=hyperkit
😄 minikube v1.25.2 on Darwin 12.2.1
🆕 Kubernetes 1.23.3 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.23.3
✨ Using the hyperkit driver based on existing profile
👍 Starting control plane node minikube in cluster minikube
🔄 Restarting existing hyperkit VM for "minikube" ...
🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.3 ...
❌ Problems detected in etcd [592b8a58065e]:
2022-03-19 22:12:03.193985 I | embed: rejected connection from "127.0.0.1:38132" (error "remote error: tls: bad certificate", ServerName "")
I tried :
Restarted the computer : https://github.com/kubernetes/minikube/issues/4329
Used --embed-certs argument
$ minikube start --vm-driver=hyperkit --embed-certs
😄 minikube v1.25.2 on Darwin 12.2.1
🆕 Kubernetes 1.23.3 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.23.3
✨ Using the hyperkit driver based on existing profile
👍 Starting control plane node minikube in cluster minikube
🔄 Restarting existing hyperkit VM for "minikube" ...
🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.3 ...
❌ Problems detected in etcd [78d1e36569b8]:
2022-03-19 22:20:53.503532 I | embed: rejected connection from "127.0.0.1:34926" (error "remote error: tls: bad certificate", ServerName "")
I'm new to K8s, what could cause such behaviour ?
I installed minikube and hyperkit with homebrew. When I display the kubectl version I get another connection error :
kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.5", GitCommit:"5c99e2ac2ff9a3c549d9ca665e7bc05a3e18f07e", GitTreeState:"clean", BuildDate:"2021-12-16T08:38:33Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"darwin/amd64"}
Unable to connect to the server: dial tcp 192.168.64.2:8443: i/o timeout
The kubectl version error helped :
Unable to connect to the server: dial tcp i/o time out
It seems I had already played with k8s :
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority: /Users/xxx/.minikube/ca.crt
extensions:
- extension:
last-update: Sat, 13 Mar 2021 13:40:06 CET
provider: minikube.sigs.k8s.io
version: v1.18.1
name: cluster_info
server: https://192.168.64.2:8443
name: minikube
contexts:
- context:
cluster: minikube
extensions:
- extension:
last-update: Sat, 13 Mar 2021 13:40:06 CET
provider: minikube.sigs.k8s.io
version: v1.18.1
name: context_info
namespace: default
user: minikube
name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
user:
client-certificate: /Users/xxx/.minikube/profiles/minikube/client.crt
client-key: /Users/xxx/.minikube/profiles/minikube/client.key
First I deleted the existing cluster :
$ kubectl config delete-cluster minikube
deleted cluster minikube from /Users/xxx/.kube/config
Then run
$ minikube delete
🔥 Deleting "minikube" in hyperkit ...
💀 Removed all traces of the "minikube" cluster.
Finally :
$ minikube start --vm-driver=hyperkit
😄 minikube v1.25.2 on Darwin 12.2.1
✨ Using the hyperkit driver based on user configuration
👍 Starting control plane node minikube in cluster minikube
💾 Downloading Kubernetes v1.23.3 preload ...
> preloaded-images-k8s-v17-v1...: 505.68 MiB / 505.68 MiB 100.00% 923.34 K
🔥 Creating hyperkit VM (CPUs=2, Memory=4000MB, Disk=20000MB) ...
🐳 Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
▪ kubelet.housekeeping-interval=5m
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: default-storageclass, storage-provisioner
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
I want to have a container that can access and run kubectl command on my host machine. Here is what I have:
I have installed Kubernetes and Minikube on my host machine.
I used this docker container: helm-kubectl link
This is the command I run my docker:
docker run -it -v ~/.kube:/root/.kube -v ~/.minikube:/Users/xxxx/.minikube dtzar/helm-kubectl
Inside the container, when I checked the cluster, I can see the context has loaded my minikube, However, I can't run another kubectl command due to the reason "The connection to the server 127.0.0.1:32768 was refused - did you specify the right host or port?".
bash-5.0# kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
docker-desktop docker-desktop docker-desktop
docker-for-desktop docker-desktop docker-desktop
* minikube minikube minikube
bash-5.0# kubectl get all
The connection to the server 127.0.0.1:32768 was refused - did you specify the right host or port?
I have checked my Kubenetes config at ~/.kube and the port is 32768.
- cluster:
certificate-authority: /Users/xxx/.minikube/ca.crt
server: https://127.0.0.1:32768
name: minikube
I have tried port -p 32768 or --expose 32768 but no luck. So anyone can help this?
Thanks zerkms! It works with --network host
I'm starting out using Docker on macOS, and get stuck when trying to complete part 4 of the Get Started guide. I have created two extra virtual machines (myvm1 and myvm2), set myvm1 as swarm manager, and myvm2 as a worker.
I have then deployed a stack with 5 Flask web servers using the docker-compose.yml from part 3 of the tutorial. The processes seem to start fine, and are distributed between the two machines, but I am not able to reach them from the host using a browser.
How should I configure the port forwarding/network to be able to reach the web servers in the swarm from the host of the virtual machines running the docker container?
The following is a list of commands that I have run, some with resulting output.
$ docker-machine create --driver virtualbox myvm1
$ docker-machine create --driver virtualbox myvm2
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
myvm1 - virtualbox Running tcp://192.168.99.100:2376 v18.09.0
myvm2 - virtualbox Running tcp://192.168.99.101:2376 v18.09.0
$ docker-machine ssh myvm1 "docker swarm init --advertise-addr 192.168.99.100"
$ docker-machine ssh myvm2 "docker swarm join --token <my-token-inserted-here> 192.168.99.100:2377"
$ eval $(docker-machine env myvm1)
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
myvm1 * virtualbox Running tcp://192.168.99.100:2376 v18.09.0
myvm2 - virtualbox Running tcp://192.168.99.101:2376 v18.09.0
$ docker stack deploy -c docker-compose.yml getstartedlab
$ docker stack ps getstartedlab
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
it9asz4zpdmi getstartedlab_web.1 mochr/test_repo:friendly_hello myvm2 Running Preparing 18 seconds ago
645gvtnde7zz getstartedlab_web.2 mochr/test_repo:friendly_hello myvm1 Running Preparing 18 seconds ago
fpq6cvcf3e0e getstartedlab_web.3 mochr/test_repo:friendly_hello myvm2 Running Preparing 18 seconds ago
plkpximnpobf getstartedlab_web.4 mochr/test_repo:friendly_hello myvm1 Running Preparing 18 seconds ago
gr2p8a0asatb getstartedlab_web.5 mochr/test_repo:friendly_hello myvm2 Running Preparing 18 seconds ago
The docker-compose.yml:
version: "3"
services:
web:
image: mochr/test_repo:friendly_hello
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
ports:
- "4000:80"
networks:
- webnet
networks:
webnet:
It looks like this is a known problem with the current version of boot2docker: https://github.com/docker/machine/issues/4608
The workaround is either to use a swarm based on machines that do not require boot2docker (e.g. AWS, DigitalOcean, etc.), wait until a newer version of boot2docker is released, or use an earlier version of boot2docker, as described in that link. To use an earlier version:
export VIRTUALBOX_BOOT2DOCKER_URL=https://github.com/boot2docker/boot2docker/releases/download/v18.06.1-ce/boot2docker.iso
before creating your virtual machines with docker-machine. (Remove your existing virtual machines first, then use that export, then docker-machine create myvm1)
Then, you should be able to bring up your stack and access your containers at either 192.168.99.100:4000 or 192.168.99.101:4000 (or whatever IP addresses are revealed by docker-machine ls)
I installed minikube as instructed here https://github.com/kubernetes/minikube/releases
and started with with a simple minikube start command.
But the next step, which is as simple as kubectl get pods --all-namespaces fails with
Unable to connect to the server: dial tcp 192.168.99.100:8443: i/o timeout
What did I miss?
I ran into the same issue using my Mac and basically I uninstalled both minikube and Kubectl and installed it as follows:
Installed Minikube.
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.8.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
Installed Kubectl.
curl -Lo kubectl http://storage.googleapis.com/kubernetes-release/release/v1.3.0/bin/darwin/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/
Start a cluster, run the command:
minikube start
Minikube will also create a “minikube” context, and set it to default in kubectl. To switch back to this context later, run this command:
kubectl config use-context minikube
Now to get the list of all pods run the command:
kubectl get pods --all-namespaces
Now you should be able to get the list of pods. Also make sure that you don't have a firewall within your network that blocks the connections.
I faced a similar issue on win7 when changed work environment, as you said it is working fine at home but not working at office, high chance it caused by firewall policy, cannot pass TLS verification.
Instead of waste time on troubleshoot(sometimes nothing to do if you cannot turn off firewall), if you just want to test local minikube cluster, would suggest to disable TLS verification.
This is what I have done:
# How to disable minikube TLS verification
## disable TLS verification
$ VBoxManage controlvm minikube natpf1 k8s-apiserver,tcp,127.0.0.1,8443,,8443
$ VBoxManage controlvm minikube natpf1 k8s-dashboard,tcp,127.0.0.1,30000,,30000
$ kubectl config set-cluster minikube-vpn --server=https://127.0.0.1:8443 --insecure-skip-tls-verify
$ kubectl config set-context minikube-vpn --cluster=minikube-vpn --user=minikube
$ kubectl config use-context minikube-vpn
## test kubectl
$ kubectl get pods
## enable local docker client
$ VBoxManage controlvm minikube natpf1 k8s-docker,tcp,127.0.0.1,2374,,2376
$ eval $(minikube docker-env)
$ unset DOCKER_TLS_VERIFY
$ export DOCKER_HOST="tcp://127.0.0.1:2374"
$ alias docker='docker --tls'
## test local docker client
$ docker ps
## test minikube dashboard
curl http://127.0.0.1:30000
Also I make a small script for this for your reference.
Hope it is helpful for you.
You need to just restart minikube. Sometimes I have this problem when my computer has been off for a while. I don't think you need to reinstall anything.
First verify you are in the correct context
$ kubectl config current-context
minikube
Check Minikube status (status should show "Running", mine below showed "Saved")
$ minikube status
minikube: Saved
cluster:
kubectl:
Restart minikube
$ minikube start
Starting local Kubernetes v1.8.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Verify it is running (This is what you should see)
$ minikube status
minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at 192.168.99.100
I had this issue when connected to Cisco AnyConnect VPN. Once I disconnected, minikube ran fine. Discussion on github here: https://github.com/kubernetes/minikube/issues/4540