istio: Installing via Helm over Installing via Operator - can't see logs, outboundTrafficPolicy is ALLOW_ANY

Bug Description

Due to the Istiio mainteners policy over deprecation of installing istio via operator which I am not happy with I have to migrate to helm for my brand new k8s deployment. OK. But, I can’t get the same effect I have got with an operator.

There is an info that helm chart is almost the same as the operator. If yes, why this does not work (It’s a terraform code but it’s so easy to grasp that I do not even put here values.yaml):

resource "helm_release" "istiod" {
  name       = "istiod"
  repository = "https://istio-release.storage.googleapis.com/charts"
  chart      = "istiod"
  version    = null #the latest
  namespace  = "istio-system"

  set {
    name  = "meshConfig.accessLogFile"
    value = "/dev/stdout"
  }

  set {
    name  = "meshConfig.outboundTrafficPolicy.mode"
    value = "REGISTRY_ONLY"
  }

  //more settings not related to the issue, e.g. global.hub, global.imagePullSecrets... are commented
  //...
}

My istio sidecars do not log traffic and outbout policy is not restrictive. In the doc that is pointed out that this is enough to configure the log, but I do not think so.

What is missing in that config? Any help is appreciated.

P.S. I treat it as a bug, because there is no good doc on that and now there is no stable method of installation in DevOps processes (operator is deprecated, and helm is still in aplpha).

Version

client version: 1.13.2
control plane version: 1.13.3
data plane version: 1.13.3 (9 proxies)

Additional Information

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (6 by maintainers)

Most upvoted comments

2022-05-08T03:24:28.663558Z	info	mesh configuration: {
    "proxyListenPort": 15001,
    "connectTimeout": "10s",
    "protocolDetectionTimeout": "0s",
    "ingressClass": "istio",
    "ingressService": "istio-ingressgateway",
    "ingressControllerMode": "STRICT",
    "enableTracing": true,
    "defaultConfig": {
        "configPath": "./etc/istio/proxy",
        "binaryPath": "/usr/local/bin/envoy",
        "serviceCluster": "istio-proxy",
        "drainDuration": "45s",
        "parentShutdownDuration": "60s",
        "discoveryAddress": "istiod.istio-system.svc:15012",
        "proxyAdminPort": 15000,
        "controlPlaneAuthPolicy": "MUTUAL_TLS",
        "statNameLength": 189,
        "concurrency": 2,
        "tracing": {
            "zipkin": {
                "address": "zipkin.istio-system:9411"
            }
        },
        "statusPort": 15020,
        "terminationDrainDuration": "5s"
    },
    "outboundTrafficPolicy": {
        "mode": "ALLOW_ANY"
    },
    "enableAutoMtls": true,
    "trustDomain": "cluster.local",
    "trustDomainAliases": [
    ],
    "defaultServiceExportTo": [
        "*"
    ],
    "defaultVirtualServiceExportTo": [
        "*"
    ],
    "defaultDestinationRuleExportTo": [
        "*"
    ],
    "rootNamespace": "istio-system",
    "localityLbSetting": {
        "enabled": true
    },
    "dnsRefreshRate": "5s",
    "certificates": [
    ],
    "thriftConfig": {

    },
    "serviceSettings": [
    ],
    "extensionProviders": [
        {
            "name": "prometheus",
            "prometheus": {

            }
        },
        {
            "name": "stackdriver",
            "stackdriver": {

            }
        },
        {
            "name": "envoy",
            "envoyFileAccessLog": {
                "path": "/dev/stdout"
            }
        }
    ],
    "defaultProviders": {

    }
}

the MeshConfig seems not changes, looks like some issue with tf.

zirain on May 15, 2022

can you run istioctl bug-report and share the output? that would help us to debug.

zirain on May 12, 2022