I am trying to open dashboard for remote access. I can access from the GUI interface inside the machine.
>> minikube dashboard
command works in the machine and I access to the dashboard UI. However, I try to open dashboard for remote access I could not be able to do it. I tried 3 different ways to open.
1 st way https://www.bogotobogo.com/DevOps/Docker/Docker_Kubernetes_Nginx_Ingress_Controller_for_Dashboard_on_Minikube.php. In here
>> minikube addons enable ingress
is giving error that i could not be able to find in the forums etc. The error is like
following
Using image k8s.gcr.io/ingress-nginx/controller:v1.1.1
Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
Verifying ingress addon...
X Exiting due to MK_ADDON_ENABLE: run callbacks: running callbacks: [waiting for app.kubernetes.io/name=ingress-nginx pods: timed out waiting for the condition]
*
If the above advice does not help, please let us know:
https://github.com/kubernetes/minikube/issues/new/choose
Please run minikube logs --file=logs.txt and attach logs.txt to the GitHub issue.
Please also attach the following file to the GitHub issue:
/tmp/minikube_addons_63d5aaebbb272eea44b9208d7275913abf1afd99_0.log
The second way that I've tried -> https://minikube.sigs.k8s.io/docs/handbook/dashboard/
In here it does not give respond for
>> minikube dashboard --url
It is waiting until to keyboard interrupt (CTRL + C)
The last way I've tried -> https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/
In here
>> kubectl proxy
does not responding anything. I am cancelling by keyboard interrupt.
I solved the second way issue it is my foolish : ( I have to run commands in background : ).
Related
I have followed all the instructions on Minikube carefully (I thought). I installed it on Windows 10 (ver 1.7.2), started a Powershell console under Administrator, set the 3 PROXY variables (I am behind a proxy), enabled the Microsoft-Hyper-V, and ran the cmd: minikube start --vm-driver=hyperv
It downloads the VM boot images, then I get the following line output:
* Creating hyperv VM (CPUs=2,....etc) ....
AND THAT'S IT!
Nothing else!! If I start the Hyper-V Manager I don't see any VMs there. The .minikube directory is populated with several dirs and files. But for the rest I am completely blind!
I have left it to run for half an hour or more. Still nothing.
I have tried terminating the process, stopping, deleting (in this case I get the output 'Deleting Kubenetes cluster' but whether this means anything I don't know) and flushing the .minikube directory ... then running it all again off a clean base. NADA! NOTHING! same thing!
Could someone please tell me what I am doing wrong? I thought this was supposed to work out of the box! Why don't I see my VM in Microsoft-Hyper-V manager for a start? I don't even get as far as seeing starting Kubenets cluster, yet I get no errors!
Try to follow this guide. It has a step by step instructions bout how to setup Docker and Minikube on windows 10 with Chocolatey.
Also here you will find an analogical issue with possible solutions.
Before you start again, remember to delete the .minikube folder after executing minikube delete to avoid any leftover configuration to persist.
Please let me know if that helped.
For the record, I flushed everything .. and tried several things from the above page, the K8 site and elsewhere. In a nutshell Docker for Desktop works and Minikube doesn't (not 100% anyway)! I was just curious back in February as to whether I could set up a local Kubenetes environment quickly and easily and I am afraid for me the answer is No: Minikube is not quick and easy. Also, you can enable Kubenetes on Docker Desktop now of course and it works out of the box as software should, so no more need for Minikube.
The following are the instructions for setting up and installing Minikube and its dependencies for use on Windows Pro or Enterprise with Docker Desktop and HyperV.
Install Kubectl
Create a new directory that you will move your kubectl binaries into. A good place would be C:\bin
Download the latest kubectl executable from the link on the Kubernetes doc page:
https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
Move this downloaded .exe file into the bin directory you created.
Use Windows search to type “env” then select “Edit the system environment variables”
In the System Properties dialog box, click “Environment Variables”.
In System Variables click on the “Path” Variable and then click “Edit”
Click “New” and then type C:\bin
Drag the newly created path so that it is higher in order than Docker's binaries. This is very important and will ensure that you will not have an out of date kubectl client.
Click "OK"
Restart your terminal and test by typing kubectl into it. You should get the basic commands and help menu printed back to your screen. If this doesn't work try restarting your machine.
Run kubectl version to verify that you are using the newest version and not the out of date v1.10 version.
Install Minikube
Download the Windows installer here:
https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe
Double click the .exe file that was downloaded and run the installer. All default selections are appropriate.
Open up your terminal and test the installation by typing minikube. You should get the basic commands and help menu printed back to your screen. If this doesn't work try restarting your machine.
Configure HyperV
In Windows Search type "HyperV" and select "HyperV Manager"
In the right sidebar click "Virtual Switch Manager"
Leave selected "New Virtual network Switch" and "External" and click "Create Virtual Switch"
Name the switch "Minikube Switch" (or whatever you would like to name it)
Click Apply and acknowledge the "Pending changes" dialog box by clicking "yes"
Once the switch has been created, click "Ok"
Starting Up Minikube
Since by default Minikube expects VirtualBox to be used, you need to tell it to use the hyperv driver instead, as well as the Virtual Switch created earlier.
Start up a terminal as an Administrator. Then, in your terminal run:
minikube start --vm-driver hyperv --hyperv-virtual-switch "Minikube Switch"
NOTE: all minikube commands must be run in the context of an elevated Administrator.
I have very bad experience with using Kubernetes dashboard in Azure installed by this tutorial. It becomes unresponsive all the time. The reasons vary:
When you do not touch the dashboard for couple minutes, it becomes unresponsive.
When you open a live log feed from a pod, the parent dashboard browser tab becomes unresponsive.
When you open an exec terminal in a pod, it becomes unresponsive at the very momenty I close the web terminal window.
Sometimes it just stops working in a middle of browsing.
Definig "unresponsive": The dashboard seems alive but when you click anything, nothing happens. Browser reloads the page but there is still the same content even if you click on different menu item.
I'm running the dashboard with a command from MSFT wiki:
az aks browse -g <cluster RG> -n <cluster name>
In the effect you have to re-run az aks browse every wonderful minute. Yes, you still can use it. But its very frustrating and its really a pain in the *** when you have to restart the az aks browse process every time after you use it for one purpose.
When the frontend goes down, the console log is full of this messages, like:
E1106 00:08:08.555527 2927 portforward.go:400] an error occurred forwarding 8001 -> 9090: error forwarding port 9090 to pod XXXXXX, uid : exit status 1: 2019/11/05 23:08:08 socat[31975] E connect(6, AF=2 127.0.0.1:9090, 16): Connection refused
Do you have similar experince?
Is there something that I can do about it?
OSX 10.14.6
I am trying to follow tutorial of Kubernetes but I am kinda lost on first steps when trying to use Katacoda... When I just try to open minikube dashboard I encounter error:
failed to open browser: exec: "xdg-open": executable file not found in $PATH
and dashboard itself remains unavailable when I try to open it through host 1.
Later steps like running hello-world work fine and I am able to run it locally using my own minikube instance but I am a bit confused with this issue. Can I debug it somehow to access dashboard during course? This is particularly confusing because I am a bit afraid that I might encounter same or similar issue during potential exam that also runs online...
Founder of Katacoda here. When running locally, then xdg provides the wrapper for opening processes on your local machine and installing the package would resolve the issue. As Katacoda runs everything within a sandbox, we cannot launch processes directly on your machine.
We have added an override for xdg-open that displays a friendly error message to users. They'll now be prompted to use the Preview Port link provided. The output is now:
$ minikube dashboard
* Verifying dashboard health ...
* Launching proxy ...
* Verifying proxy health ...
* Opening %s in your default browser...
Minikube Dashboard is not supported via the interactive terminal experience.
Please click the 'Preview Port 30000' link above to access the dashboard.
This will now exit. Please continue with the rest of the tutorial.
X failed to open browser: exit status 1
Looks like this command works:
apt install xdg-utils
I have been following the same tutorial in Katacoda and had the same issue.In my case, using these commands helpt me to solve the problem :
apt-get update
apt install xdg-utils
I have setup the apache cloudstack on CentOS 6.8 machine following quick installation guide. The management server and KVM are setup on the same machine. The management server is running without problems. I was able to add zone, pod, cluster, primary and secondary storage from the web interface. But when I tried to add an instance it is not showing any templates in the second stage as you can see in the screenshot
However, I am able to see two templates under Templates link in web UI.
But when I select the template and navigate to Zone tab, I see Timeout waiting for response from storage host and Ready field shows no.
When I check the management server logs, it seems there is an error when cloudstack tries to mount secondary storage for use. The below segment from cloudstack-management.log file describes this error.
2017-03-09 23:26:43,207 DEBUG [c.c.a.t.Request] (AgentManager-Handler-
14:null) (logid:) Seq 2-7686800138991304712: Processing: { Ans: , MgmtId:
279278805450918, via: 2, Ver: v1, Flags: 10, [{"com.cloud.agent.api.Answer":
{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for nfs://172.16.10.2/export/secondary failed due to
com.cloud.utils.exception.CloudRuntimeException: Unable to mount
172.16.10.2:/export/secondary at /mnt/SecStorage/6e26529d-c659-3053-8acb-
817a77b6cfc6 due to mount.nfs: Connection timed out\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(Nf
sSecondaryStorageResource.java:2080)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSe
condaryStorageResource.java:1829)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeReques
t(NfsSecondaryStorageResource.java:265)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:833)\n\tat
com.cloud.utils.nio.Task.call(Task.java:83)\n\tat
com.cloud.utils.nio.Task.call(Task.java:29)\n\tat
java.util.concurrent.FutureTask.run(FutureTask.java:262)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\
n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\
n\tat java.lang.Thread.run(Thread.java:745)\n","wait":0}}] }
Can anyone please guide me how to resolve this issue? I have been trying to figure it out for some hours now and don't know how to proceed further.
Edit 1: Please note that my LAN address was 10.103.72.50 which I assume is not /24 address. I tried to give CentOs a static IP by making the following settings in ifcg-eth0 file
DEVICE=eth0
HWADDR=52:54:00:B9:A6:C0
NM_CONTROLLED=no
ONBOOT=yes
BOOTPROTO=none
IPADDR=172.16.10.2
NETMASK=255.255.255.0
GATEWAY=172.16.10.1
DNS1=8.8.8.8
DNS2=8.8.4.4
But doing this would stop my internet. As a workaround, I reverted these changes and installed all the packages first. Then I changed the IP to static by the same configuration settings as above and ran the cloudstack management. Everything worked fine untill I bumped into this template thing. Please help me figure out what might have went wrong
I know I'm late, but for people trying out in the future, here it goes:
I hope you have successfully added a host as mentioned in Quick Install Guide before you changed your IP to static as it autoconfigures VLANs for different traffic and creates two bridges - generally with names 'cloud' or 'cloudbr'. Cloudstack uses the Secondary Storage System VM for doing all the storage-related operations in each Zone and Cluster. What seems to be the problem is that secondary storage system vm (SSVM) is not able to communicate with the management server at port 8250. If not, try manually mounting the NFS server's mount points in the SSVM shell. You can ssh into the SSVM using the below command:
ssh -i /var/cloudstack/management/.ssh/id_rsa -p 3922 root#<Private or Link local Ip address of SSVM>
I suggest you run the /usr/local/cloud/systemvm/ssvm-check.sh after doing ssh into the secondary storage system VM (assuming it is running) and has it's private, public and link local IP address. If that doesn't help you much, take a look at the secondary storage troubleshooting docs at Cloudstack.
I would further recommend, if anyone in future runs into similar issues, check if the SSVM is running and is in "Up" state in the System VMs section of Infrastructure tab and that you are able to open up a console session of it from the browser. If that is working go on to run the ssvm-check.sh script mentioned above which systematically checks each and every point of operation that SSVM executes. Even if console session cannot be opened up, you can still ssh using the link local IP address of SSVM which can be accessed by opening up details of SSVM and than execute the script. If it says, it cannot communicate with Management Server at port 8250, I recommend you check the iptables rules of management server and make sure all traffic is allowed at port 8250. A custom command to check the same is nc -v <mngmnt-server-ip> 8250. You can do a simple search and learn how to add port 8250 in your iptables rules if that is not opened. Next, you mentioned you used CentOS 6.8, so it probably uses older versions of nfs, so execute exportfs -a in your NFS server to make sure all the NFS shares are properly exported and there are no errors. I would recommend that you wait for the downloading status of CentOS 5.5 no GUI kvm template to be complete and its Ready status shown as 'Yes' before you start importing your own templates and ISOs to execute on VMs. Finally, if your ssvm-check.sh script shows everything is good and the download still does not start, you can run the command: service cloud restart and actually check if the service has gotten a PID using service cloud status as the older versions of system vm templates sometimes need us to manually start the cloud service using service cloud start even after the restart command. Restarting the cloud service in SSVM triggers the restart of downloading of all remaining templates and ISOs. Side note: the system VMs uses a Debian kernel if you want to do some more troubleshooting. Hope this helps.
Last week I got to know node-red (what a potential!), and after installing it on a Raspberry Pi B+ and following the basic tutorials, I'm experiencing some issues.
When I follow the Inject + Debug node example, wire them, and deploy them, I get the message "Deploy sucessfull". So far so good. I'm running it locally on http:// localhost:1880.
Then when I click the Inject node or the Debug node, it says: "Error: Inject node not deployed" or "Error: Debug node not deployed".
Anyone know how to fix this error? Is it a server problem?
Was having the same issues and discovered the flow that I was working on was disabled.
You can tell the flow is disabled when the lettering on its tab is in italic and there is a circle with a diagonal line through it ahead of the lettering.
Double click the flow tab and change "status" to "enabled".
Just tried something and it worked:
When you run node --max-old-space-size=128 red.js, the command line shows you "cannot find flows_raspberrypi.json"
So I
1) created a flow (as in the examples) 2) Exported it as
"flows_raspberrypi.json" 3) Stopped node-red 4) Started it again
Bingo! It picked this flow up, which then "sucessfully injected".
Now just create your own flows...
I was also getting same problem of :- Node-red Error: inject node not deployed.
When I have install dashboard on Node-Red which was not working, and started giving error when I hit inject node.
So I manually deleted the files (flows-raspberrypi.json, package.json, settings.js) and also folders (lib, node_modules) from the path /home/pi/.node-red
I used vnc-viewer to delete manually files & folders. Just login to vnc-Viewer and open the file manager and paste the path "/home/pi/.node-red" & delete all the files. Reboot the Raspberry-Pi and start Node-Red, it will function normally, even after installing dashboard it is working.
NOTE:It will delete all your flows and install nodes from Node-Red. So keep backup of your flows.