istio: sidecar pilot doesn't initialize

Describe the bug Something is borked in 1.1 daily releases (or my install is borked).

Applier sidecar spins with this log (for 50+ minutes before I gave up):

* failed checking application ports. listeners="0.0.0.0:15090","10.3.0.25:443","10.3.0.223:15030","10.3.0.99:53","10.3.0.30:42422","10.3.0.1:443","10.3.0.223:443","10.3.0.223:15031","10.3.0.223:15443","10.3.0.172:443","10.3.0.223:31400","10.3.0.223:15029","10.3.0.223:15032","10.3.0.216:15011","0.0.0.0:10000","0.0.0.0:80","0.0.0.0:8080","0.0.0.0:15004","0.0.0.0:9091","0.0.0.0:15014","0.0.0.0:9901","0.0.0.0:9090","0.0.0.0:8060","0.0.0.0:15010","10.2.2.40:15020","0.0.0.0:15001"
* envoy missing listener for inbound application port: 0
* envoy missing listener for inbound application port: 10000

Expected behavior application sidecar initializes properly.

Steps to reproduce the bug

  1. Install Istio with following values.yaml
global:
  podDNSSearchNamespaces:
  - global
  - "[[ valueOrDefault .DeploymentMeta.Namespace \"default\" ]].global"

  multiCluster:
    enabled: true

  controlPlaneSecurityEnabled: true

  hub: gcr.io/istio-release

  tag: release-1.1-latest-daily

security:
  selfSigned: false

istiocoredns:
  enabled: true

gateways:
  istio-egressgateway:
    env:
      ISTIO_META_REQUESTED_NETWORK_VIEW: "external"
  1. label the default namespace

  2. Install this manifest:

kind: Deployment
metadata:
  name: applier
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: details
        version: v1
    spec:
      containers:
      - name: applier
        image: gcr.io/stackpoint-public/applier:sdake
        imagePullPolicy: Always
        ports:
        - containerPort: 10000
---
apiVersion: v1
kind: Service
metadata:
  name: applier
  labels:
    app: applier
spec:
  ports:
  - port: 10000
    name: grpc
  selector:
    app: applier

Version daily release screen shot 2019-02-22 at 6 01 15 am

Installation See values.yaml above

Environment Azure cloud environment deployed with kubeadm.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 17 (15 by maintainers)

Most upvoted comments

@costinm found the root cause. My manifest was incorrect.

The labels for the manifest of the service and deployment didn’t match. This caused weird errror results in the sidecar pilot-proxy. Perhaps other folks are suffering with this same false symptom of the readiness check failing.