kubernetes-sigs / kind

Kubernetes IN Docker - local clusters for testing Kubernetes
https://kind.sigs.k8s.io/
Apache License 2.0
13.56k stars 1.57k forks source link

istio-ingressgateway LoadBalancer IP status pending #2374

Open akverma10 opened 3 years ago

akverma10 commented 3 years ago

I have installed Istio 1.10.2, but istio-ingressgateway LB external IP status is “pending”. Any suggestion to fix this issue. Logs are attached below. Can anyone help me to fix this issue?

istio-system istio-ingressgateway LoadBalancer 100.68.x.x 15021:32392/TCP,80:31069/TCP,443:32359/TCP,31400:30878/TCP,15443:31689/TCP 17h

capv@allot-ddos-master-control-plane-fh6p9 [ ~ ]$ istioctl admin log istio-ingressgateway-84f6ff6d8b-b6d7w 2021-07-16T19:13:01.860970Z error klog an error occurred forwarding 39745 -> 9876: error forwarding port 9876 to pod 64f88e029abe2c178674a6c24724d943058ebeefe1ed734944e23b2d88a23262, uid : failed to execute portforward in network namespace "/var/run/netns/cni-be71f31b-d8d5-4429-d0c2-bf3e8978da19": socat command returns error: exit status 1, stderr: "2021/07/16 19:13:01 socat[5318.140232482470784] E connect(5, AF=2 127.0.0.1:9876, 16): Connection refused\n" Error: could not get scopes information: Get "http://localhost:39745/scopej": EOF

howardjohn commented 3 years ago

See https://kind.sigs.k8s.io/docs/user/loadbalancer/ there are extra steps needed

akverma10 commented 3 years ago

Thanks John. Let me try these steps.

akverma10 commented 3 years ago

I tried the above link but I am facing the same issue: LB external IP status is pending

kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE foo-service LoadBalancer 100.70.21.56 5678:30016/TCP 15h kubernetes ClusterIP 100.64.0.1 443/TCP 16h

apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools:

rfatolahzade commented 3 years ago

same here

nnewc commented 3 years ago

I'm trying run istio on kind as well, but I changed the ingressgateway service type to NodePort to correspond with also changing the extraPortsMapping to 80 -> 32080 and 443 -> 32443.

Name:                     istio-ingressgateway
Namespace:                istio-system
Labels:                   app=istio-ingressgateway
                          app.kubernetes.io/managed-by=Helm
                          install.operator.istio.io/owning-resource=unknown
                          istio=ingressgateway
                          istio.io/rev=default
                          operator.istio.io/component=IngressGateways
                          release=istio-ingress
Annotations:              meta.helm.sh/release-name: istio-ingress
                          meta.helm.sh/release-namespace: istio-system
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.96.167.56
IPs:                      10.96.167.56
Port:                     status-port  15021/TCP
TargetPort:               15021/TCP
NodePort:                 status-port  30182/TCP
Endpoints:                10.244.0.9:15021
Port:                     http2  8080/TCP
TargetPort:               8080/TCP
NodePort:                 http2  32080/TCP
Endpoints:                10.244.0.9:8080
Port:                     https  8443/TCP
TargetPort:               8443/TCP
NodePort:                 https  32443/TCP
Endpoints:                10.244.0.9:8443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

But I still get connection refused when I try to hit the app.

joncfoo commented 3 years ago

I'm seeing the same thing with kind 0.11.1 and istio 1.11.3.

To reproduce the issue:

kind-config.yaml ```yaml apiVersion: kind.x-k8s.io/v1alpha4 kind: Cluster nodes: - role: control-plane extraPortMappings: - containerPort: 32000 hostPort: 80 ```
istio-patch.yaml ```yaml # change istio-ingressgateway from LoadBalancer to NodePort to allow incoming # traffic to work correctly with Kind. spec: type: NodePort ports: - name: http2 nodePort: 32000 port: 80 targetPort: 80 protocol: TCP ```
deployment.yaml ```yaml apiVersion: v1 kind: Service metadata: name: hello spec: selector: app: hello ports: - port: 8080 targetPort: 8080 name: http-hello --- apiVersion: apps/v1 kind: Deployment metadata: name: hello spec: selector: matchLabels: app: hello template: metadata: labels: app: hello spec: containers: - name: hello image: jmalloc/echo-server:latest ports: - containerPort: 8080 --- apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: namespace: istio-system name: hello spec: selector: istio: ingressgateway servers: - port: number: 8080 name: http protocol: HTTP hosts: - '*' --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: hello spec: hosts: - '*' gateways: - istio-system/hello http: - route: - destination: host: hello.default.svc.cluster.local port: number: 8080 ```

Steps to reproduce:

# create cluster with config
kind create cluster --name test --config kind-config.yaml

# switch to kind-test cluster
kubectx kind-test

# add label to namespace to allow istio to do its thing automatically
kubectl label namespace default istio-injection=enabled

# install istio (uses default profile)
istioctl install --skip-confirmation

# patch istio-ingressgateway and change the service from LoadBalancer to NodePort
kubectl -n istio-system patch service istio-ingressgateway --patch-file istio-patch.yaml

# create deployment
kubectl apply -f ./deployment.yaml

# the following should respond with something but does not
curl -s http://localhost/

# try again in verbose mode
curl -v http://localhost/
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.79.1
> Accept: */*
>
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

Working behavior with k3d v4.4.8

# create cluster
k3d cluster create test -p 80:80@loadbalancer --k3s-server-arg '--no-deploy=traefik'

# add label to namespace to allow istio to do its thing automatically
kubectl label namespace default istio-injection=enabled

# install istio (uses default profile)
istioctl install --skip-confirmation

# create deployment
kubectl apply -f ./deployment.yaml

# verify istio did its thing
curl -s http://localhost/
Request served by hello-6db69d46b8-zkc6n

HTTP/1.1 GET /

Host: localhost
X-Forwarded-Proto: http
X-Request-Id: 73b8d2d5-95ec-4173-aec0-f7c6c9208e74
X-Envoy-Attempt-Count: 1
X-Envoy-Internal: true
X-B3-Spanid: 8089200952aae195
X-B3-Parentspanid: a7e164d88e105251
User-Agent: curl/7.79.1
X-Forwarded-For: 10.42.0.1
X-Forwarded-Client-Cert: By=spiffe://cluster.local/ns/default/sa/default;Hash=7e180480e087a60e88adbc436a0991a073ab40a802830cf682808ebd2af63526;Subject="";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account
X-B3-Traceid: 145276f21aceb15fa7e164d88e105251
X-B3-Sampled: 0
Accept: */*
teatreeoilchocolate commented 2 years ago

If anyone ever gets around to this problem. Update to the latest version of istio (1.12+), I had similar problems until I upgraded. istio: 1.12.1 kind: 0.11.1

So anything prior 1.12. might not work smoothly.

As @howardjohn pointed out, there are additional steps. For a single-node "cluster" created with kind you will need no specific configuration or patching of any kind. My kind-config is only creating extra-mounts for the controle plane container. I also noticed, I strangely have no need to uncordon that node, which is nice.

So including the steps referred to by John, a kind setup using istio boils down to the following steps:

kind create cluster --config kind-config.yml

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/master/manifests/namespace.yaml && kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" &&
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/master/manifests/metallb.yaml && kubectl apply -f metallb_config.yml && docker network inspect -f '{{.IPAM.Config}}' kind

istioctl install --set meshConfig.accessLogFile=/dev/stdout --set hub=gcr.io/istio-release
kubectl label namespace default istio-injection=enabled --overwrite

Prior to installing istio you may check the working of metallb. Setup and Configuration is aptly described on the kind-homepage; I just copied those steps.

mark8s commented 2 years ago

@joncfoo Did you solve it?