I am following the Installation Instructions from https://argoproj.github.io/argo-cd/getting_started/#3-access-the-argo-cd-api-server
and even though the service type has been changes to LoadBalancer I cannot manage to login.
The information I have is:
$ oc describe svc argocd-server
Name: argocd-server
Namespace: argocd
Labels: app.kubernetes.io/component=server
app.kubernetes.io/name=argocd-server
app.kubernetes.io/part-of=argocd
Annotations: <none>
Selector: app.kubernetes.io/name=argocd-server
Type: LoadBalancer
IP: 172.30.70.178
LoadBalancer Ingress: a553569222264478ab2xx1f60d88848a-642416295.eu-west-1.elb.amazonaws.com
Port: http 80/TCP
TargetPort: 8080/TCP
NodePort: http 30942/TCP
Endpoints: 10.128.3.91:8080
Port: https 443/TCP
TargetPort: 8080/TCP
NodePort: https 30734/TCP
Endpoints: 10.128.3.91:8080
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
If I do:
$ oc login https://a553569222264478ab2xx1f60d88848a-642416295.eu-west-1.elb.amazonaws.com
The server is using a certificate that does not match its hostname: x509: certificate is valid for localhost, argocd-server, argocd-server.argocd, argocd-server.argocd.svc, argocd-server.argocd.svc.cluster.local, not a553569222264478ab2xx1f60d88848a-642416295.eu-west-1.elb.amazonaws.com
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
error: Seems you passed an HTML page (console?) instead of server URL.
Verify provided address and try again.
I managed to successfully login argocd-server by the following
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
argoPass=$(kubectl -n argocd get secret argocd-initial-admin-secret \
-o jsonpath="{.data.password}" | base64 -d)
argocd login --insecure --grpc-web k3s_master:32761 --username admin \
--password $argoPass
If you wish to expose an ArgoCD server via ingress, you can disable the TLS by patching the argocd-server deployment:
no-tls.yaml
spec:
template:
spec:
containers:
- name: argocd-server
command:
- argocd-server
- --insecure
kubectl patch deployment -n argocd argocd-server --patch-file no-tls.yaml
check your svc on argocd
kubectl get svc -n argocd
If the type is NodePort then that is fine, if not then here is the conversion method:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'
And then to access the ArgoCD server to browser, put the IP address of the VM plus the port that NodePort will provide as in the picture
Once run, your ArgoCD cluster will be available at https://<hosted-node-ip>:<NodePort>
By default, argocd server run with self signed tls enabled. Your are trying to access the argocd server with different url with tls enabled. The API server should be run with TLS disabled. Edit the argocd-server deployment to add the --insecure flag to the argocd-server command.
containers:
- command:
- argocd-server
- --staticassets
- /shared/app
- --insecure
I was able to login argocd-server by using below command
argocd login --insecure --grpc-web test-server.companydomain.com --grpc-web-root-path /argocd
Username: admin
Password:
'admin:login' logged in successfully
I am using traefik as ingress controller. My server can be accessed on browser https://test-server.companydomain.com/argocd
Related
I use this command to install and enable Kubernetes dashboard on a remote host:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml
kubectl proxy --address='192.168.1.132' --port=8001 --accept-hosts='^*$'
http://192.168.1.132:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login
But I get:
Insecure access detected. Sign in will not be available. Access Dashboard securely over HTTPS or using localhost. Read more here .
Is it possible to enable SSL connection on the Kubernetes host so that I can access it without this warning message and enable login?
From the service definition
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
ports:
- port: 443
targetPort: 8443
selector:
k8s-app: kubernetes-dashboard
Which exposes port 443 (aka https). So it's already preconfigured. First, use https instead of http in your URL.
Then, instead of doing a kubectl proxy, why not simply
kubectl port-forward -n kubernetes-dashboard services/kubernetes-dashboard 8001:443
Access endpoint via https://127.0.0.1:8001/#/login
Now it's going to give the typical "certificate not signed" since the certificate are self signed (arg --auto-generate-certificates in deployment definition). Just skip it with your browser. See an article like https://vmwire.com/2022/02/07/running-kubernetes-dashboard-with-signed-certificates/ if you need to configure a signed certificate.
Try this
First do a port forward to your computer, this will forward 8443 of your computer (first port) to the 8443 port in the pod (the one that is exposed acording to the manifest)
kubectl port-forward pod/kubernetes-dashboard 8443:8443 # Make sure you switched to the proper namespace
In your browser go to http://localhost:8443 based on the error message it should work.
if the kubernetes dashboard pod implements ssl in its web server then go to https://localhost:8443
I'm trying to accomplish the following:
Create a new service to access the web application using the service-definition-1.yaml file
Name: webapp-service
Type: NodePort
targetPort: 8080
port: 8080
nodePort: 30080
selector: simple-webapp
I ran the command
kubectl create service nodeport webapp-service --tcp=8080:8080 --node-port=30080
and got everything I wanted. However, I have to manually create & edit the yaml file to add the selector: simple-webapp.
I was curious if I could specify the selectors for a service through the command line?
Try:
kubectl create service nodeport webapp-service --tcp 8080:8080 --node-port 30080 \
--dry-run=client -o yaml | kubectl set selector --local -f - app=simple-webapp -o yaml
I think the concept you are looking for is "Labels and Selectors"
See: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
kubectl get pods -l environment=production,tier=frontend
I have created a service like this:
apiVersion: v1
kind: Service
metadata:
name: amen-sc
spec:
ports:
- name: http
port: 3030
targetPort: 8000
selector:
component: scc-worker
I am able to access this service, from within my pods of the same cluster (& Namespace), using the IP address I get from kubectl get svc, but I am not able to access using the service name like curl amen-sc:3030.
Please advise what could possibly be wrong.
I intend to expose certain pods, only within my cluster and access them using the service-name:port format.
Make sure you have DNS service configured and corresponding pods are running.
kubectl get svc -n kube-system -l k8s-app=kube-dns
and
kubectl get pods -n kube-system -l k8s-app=kube-dns
I am trying to create an application in Kubernetes (Minikube) and expose its service to other applications in same clusters, but i get connection refused if i try to access this service in Kubernetes node.
This application just listen on HTTP 127.0.0.1:9897 address and send response.
Below is my yaml file:
apiVersion: apps/v1
kind: Deployment
metadata:
name: exporter-test
namespace: datenlord-monitoring
labels:
app: exporter-test
spec:
replicas: 1
selector:
matchLabels:
app: exporter-test
template:
metadata:
labels:
app: exporter-test
spec:
containers:
- name: prometheus
image: 34342/hello_world
ports:
- containerPort: 9897
---
apiVersion: v1
kind: Service
metadata:
name: exporter-test-service
namespace: datenlord-monitoring
annotations:
prometheus.io/scrape: 'true'
prometheus.io/port: '9897'
spec:
selector:
app: exporter-test
type: NodePort
ports:
- port: 8080
targetPort: 9897
nodePort: 30001
After I apply this yaml file, the pod and the service deployed correctly, and I am sure this pod works correctly, since when I login the pod by
kubectl exec -it exporter-test-* -- sh, then just run curl 127.0.0.1:9897, I can get the correct response.
Also, if I run kubectl port-forward exporter-test-* -n datenlord-monitoring 8080:9897, I can get correct response from localhost:8080. So this application should work well.
However, when I trying to access this service from other application in same K8s cluster by exporter-test-service.datenlord-monitoring.svc:30001 or just run curl nodeIp:30001 in k8s node or run curl clusterIp:8080 in k8s node, I got Connection refused
Anyone had same issue before? Appreciate for any help! Thanks!
you are mixing two things here. NodePort is the port the application is available from outside your cluster. Inside your cluster you need to access your service via the service port, not the NodePort.
Try changing exporter-test-service.datenlord-monitoring.svc:30001 to exporter-test-service.datenlord-monitoring.svc:8080
Welcome to the community!
There are no issues with behaviour you observed.
In short words kubernetes cluster (which is minikube in this case) has its own isolated network with internal DNS.
One way to access your service on the node: you specified nodePort for your service and this made the service accessible on the localhost:30001. You can check it by running on your host:
$ kubectl get svc -n datenlord-monitoring
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
exporter-test-service NodePort 10.111.191.159 <none> 8080:30001/TCP 2m45s
# Test:
curl -I localhost:30001
HTTP/1.1 200 OK
Another way to expose service to the host network is to use minikube tunnel (run in the another console). You'll need to change service type from NodePort to LoadBalancer:
$ kubectl get svc -n datenlord-monitoring
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
exporter-test-service LoadBalancer 10.111.191.159 10.111.191.159 8080:30001/TCP 18m
# Test:
$ curl -I 10.111.191.159:8080
HTTP/1.1 200 OK
Why some of options doesn't work.
Connection to the service by its DNS + NodePort. NodePort is used to link host IP and NodePort to service port inside kubernetes cluster. Internal DNS is not accessible outside kubernetes cluster (unless you don't add IPs to /etc/hosts on your host machine)
Inside the cluster you should use internal DNS with internal service port which is 8080 in your case. You can check how this works with a separate container in the same namespace (e.g. image curlimages/curl) and get following:
$ kubectl exec -it curl -n datenlord-monitoring -- curl -I exporter-test-service:8080
HTTP/1.1 200 OK
Or from the pod in a different namespace:
$ kubectl exec -it curl-default-ns -- curl -I exporter-test-service.datenlord-monitoring.svc:8080
HTTP/1.1 200 OK
I've attached useful links which help you to understand this difference.
Edit: DNS inside deployed pod
$ kubectl exec -it exporter-test-xxxxxxxx-yyyyy -n datenlord-monitoring -- bash
root#exporter-test-74cf9f94ff-fmcqp:/# cat /etc/resolv.conf
nameserver 10.96.0.10
search datenlord-monitoring.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
Useful links:
DNS for pods and services
Service types
Accessing apps in Minikube
you need to change 127.0.0.1:9897 to 0.0.0.0:9897 so that application listens to all incoming requests
I am trying to access a clusterip service (running kubernetes on my laptop through docker-for-mac).
Following the instructions here, I was able to successfully ping the service like this:
kubectl run curl --image=radial/busyboxplus:curl -i --tty
curl -v http://10.106.1.204:8000/api/v0.1/predictions -d '{"foo": "bar"}' -H "Content-Type: application/json"
but I can't get it to work using the service name instead of it's ip. I then tried to use kubectl proxy as described here, but I can't get it to work:
kubectl proxy --port=8080 &
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000/api/v0.1/predictions
that gives me a 404 error as do all of the following:
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000/predictions
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000/api/v0.1/predictions
as well as all combinations of replacing 8000 with http in all of the above and/or the ip with the service name.
I can confirm that the proxy is working as http://127.0.0.1:8080/api/v1/namespaces/deploy-test/pods works.
This is the description of the service. Note that I am specifically trying to access it via the clusterip and not use Ambassador.
kubectl describe svc -n deploy-test template-product-app-seldon-prediction-service
Name: template-product-app-seldon-prediction-service
Namespace: deploy-test
Labels: seldon-app=template-product-app-seldon-prediction-service
seldon-deployment-id=template-product-app-seldon-prediction-service
Annotations: getambassador.io/config:
---
apiVersion: ambassador/v1
kind: Mapping
name: seldon_deploy-test_seldon-prediction-service_rest_mapping
prefix: /seldon/deploy-test/seldon-prediction-service/
service: template-product-app-seldon-prediction-service.deploy-test:8000
timeout_ms: 3000
---
apiVersion: ambassador/v1
kind: Mapping
name: seldon_deploy-test_seldon-prediction-service_grpc_mapping
grpc: true
prefix: /seldon.protos.Seldon/
rewrite: /seldon.protos.Seldon/
service: template-product-app-seldon-prediction-service.deploy-test:5001
timeout_ms: 3000
headers:
namespace: deploy-test
seldon: seldon-prediction-service
retry_policy:
retry_on: connect-failure
num_retries: 3
Selector: seldon-app=template-product-app-seldon-prediction-service
Type: ClusterIP
IP: 10.106.1.204
Port: http 8000/TCP
TargetPort: 8000/TCP
Endpoints: 10.1.1.4:8000
Port: grpc 5001/TCP
TargetPort: 5001/TCP
Endpoints: 10.1.1.4:5001
Session Affinity: None
Events: <none>
Any suggestions on how to do this via kubectl proxy instead of spinning up a pod with radial/busyboxplus:curl?
The general format to access http services through the kubectl proxy is the following:
http://api.host/api/v1/namespaces/NAMESPACE/services/SERVICE_NAME:SERVICE_PORT/proxy/
In your case you added the cluster ip which is not necessary.
Try:
http://127.0.0.1:8080/api/v1/namespaces/deploy-test/services/template-product-app-seldon-prediction-service:8000/proxy/api/v0.1/predictions
http://127.0.0.1:43029/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard
Note that this will probably not work with grpc, only for http. (Use a NodePort oder LoadBalancer instead in that case)