I have a Linux build machine that I have installed minikube too. Within the minikube instance I have installed artifactory which I will be using for storing various build artifacts
I now want to be able to do some work on my dev machine (which is an unrelated laptop on the same network as the Linux build machine) and push some built artifacts into artifactory.
However I can't figure out how to get to artifactory. When I ssh to the Linux server and check the minikube service I can see that the artifactory instance is running on a 192.168 address.
Is there any way to expose artifactory ie access it on the windows machine? Or is this not possible and I should just install artifactory on the Linux machine rather than in minikube?
Expose you artifactory Service
$ minikube service <artifactory-service> -n <namespace>
Or get the URL
$ minikube service <artifactory-service> -n <namespace> --url
If you want to access from remote, you need to do something else.
Suppose, when you run minikube service <artifactory-service> -n <namespace> --url, you get following
http://192.168.99.100:30654
You can access artifactory in minikube using this URL. But can't access from remote.
Now do this, expose port 30654
ssh -i ~/.minikube/machines/minikube/id_rsa docker#$(minikube ip) -L \*:30654:0.0.0.0:30654
You will be able to access from other network.
Yes, we need an ingress controller (like nginx) to expose a kubernetes service for external access.
There are three ways to create the nginx ingress service using kubernetes per https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types and expose it for external access:
LoadBalancer service type which sets the ExternalIP automatically. This is used when there is an external non-k8s, cloud-provider's load-balancer like CGE, AWS or Azure, and this external load-balancer would provide the ExternalIP for the nginx ingress service.
ExternalIPs per https://kubernetes.io/docs/concepts/services-networking/service/#external-ips.
NodePort. In this approach, the service can be accessed from outside the cluster using NodeIP:NodePort/url/of/the/service.
Along with the nginx ingress controller, you'll need an ingress resource too. Refer https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example for examples.
Keep in mind that Minikube is a small VM with a small docker registry by default. So, it may not be possible to store a lot of build artifacts in Minikube.
To get this to work in the end I setup ingress on minikube and then through entries in hosts file and nginx as a reverse proxy managed to get things working.
Related
What I'm trying to do
I have deployed an aps.net core gRpc service on Docker for Desktop (Kubernetes enabled). To do client-side load balancing, I want to expose the same via a headless service. The deployment and service definition YAML files are as provided by the link viz. Deployment.yaml , service.yaml, and PV and PVC .yaml. When the deployment is run two replicas will be created. Now I want to expose them via a headless service and do a DNS lookup of the pods' IP addresses and do a client-side load balancing. For this, I installed the bitnami external-dns using the HELM charts. I did not make any modifications to the default chart values. Now when I try to do a nslookup of my service this is not working.
My expectation
Deploy the bitnami external-dns on Docker for Desktop with Kubernetes enabled and configured service to expose as DNS on the load balancer. I was expecting the nslookup to succeed in getting the pod IPs as a result
Can someone help me to get the same working?
I'm trying to deploy WSO2 APIM on Kubernetes using the pattern-1 described on the github page https://github.com/wso2/kubernetes-apim. I have added my minikube ip to my etc/hosts file as follows:
[minikube ip] am.wso2.com gateway.am.wso2.com
I'm unable to access the Publisher and Devportal using this url:https://am.wso2.com/publisher
Is there any other configuration that needs to be done? Any help would be great:). Thanks in advance..
First, make sure all your WSO2 pods are running and they're in the ready state.
kubectl get po -n <your_namespace>
This should output.
Then make sure you have enabled Ingress addon.
minikube addons list
Then make sure Ingress pods are running.
kubectl get po -n ingress-nginx
Next, get the Ingress external IP.
kubectl get ing -A
Get the external IP and the Host from the above and add a entry to the /etc/hosts as shown below.
If everything is in place you should be able to access the Publisher by going to https://am.wso2.com/
Try to run the below command in the command line.
minikube tunnel
I have a deployment with services running inside minikube on a remote linux vps, these services have Cluster IP with no external IP, I would want to access these services from a web browser
Either you change the service type LoadBalancer which will create the External for you and you can access the specific service using that.
OR
Setup the ingress and ingress controller which can be also useful to expose the service directly.
OR for just Development use not for Prod
kubectl port-forward svc/<service name> 5555:<service port here>
This creates the proxy tunnel between your K8s cluster and local. You can access your service now at localhost:5555
I've been learning Kubernetes recently and just came across this small issue. For some sanity checks, here is the functionality of my grpc app running locally:
> docker run -p 8080:8080 -it olamai/simulation:0.0.1
< omitted logs >
> curl localhost:8080/v1/todo/all
{"api":"v1","toDos":[{}]}
So it works! All I want to do now is deploy it in Minikube and expose the port so I can make calls to it. My end goal is to deploy it to a GKE or Azure cluster and make calls to it from there (again, just to learn and get the hang of everything.)
Here is the yaml I'm using to deploy to minikube
And this is what I run to deploy it on minikube
> kubectl create -f deployment.yaml
I then run this to get the url
> minikube service sim-service --url
http://192.168.99.100:30588
But this is what happens when I make a call to it
> curl http://192.168.99.100:30588/v1/todo/all
curl: (7) Failed to connect to 192.168.99.100 port 30588: Connection refused
What am I doing wrong here?
EDIT: I figured it out, and you should be able to see the update in the linked file. I had pull policy set to Never so it was out of date 🤦
I have a new question now... I'm now able to just create the deployment in minikube (no NodePort) and still make calls to the api... shouldn't the deployment need a NodePort service to expose ports?
I checked your yaml file and it works just fine. But only I realized that you put 2 types for your services, LoadBalancer and also NodePort which is not needed.
As if you check from this documentation definition of LoadBalancer, you will see
LoadBalancer: Exposes the service externally using a cloud provider’s
load balancer. NodePort and ClusterIP services, to which the external
load balancer will route, are automatically created.
As an answer for your next question, you probably put type: LoadBalancer to your deployment yaml file, that's why you are able to see NodePort anyway.
If you put type: ClusterIP to your yaml, then service will be exposed only within cluster, and you won't able to reach to your service outside of cluster.
From same documentation:
ClusterIP: Exposes the service on a cluster-internal IP. Choosing this
value makes the service only reachable from within the cluster. This
is the default ServiceType
I couldn't find any information on wherever a connection creation between cluster's pod and locahost is encrypted when running "kubectl port-forward" command.
It seems like it uses "socat" library which supports encryption, but I'm not sure if kubernetes actually uses it.
As far as I know when you port-forward the port of choice to your machine kubectl connects to one of the masters of your cluster so yes, normally communication is encrypted. How your master communicate to the pod though is dependent on how you set up internal comms.
kubectl port-forward uses socat to make an encrypted TLS tunnel with port forwarding capabilities.
The tunnel goes from you to the kube api-server to the pod so it may actually be 2 tunnels with the kube api-server acting as a pseudo router.
An example of where I've found it useful was that I was doing a quick PoC of a Jenkins Pipeline hosted on Azure Kubernetes Service and earlier in my Kubernetes studies I didn't know how to setup an Ingress, but I could reach the Server via port 80 unencrypted, but I knew my traffic could be snooped on. So I just did kubectl port-forward to temporarily login and securely to debug my POC. Also really helpful with RabbitMQ Cluster hosted on Kubernetes, you can go into the management webpage with kubectl port-forward and make sure that it's clustering the way you wanted it to.