{{- end }}
      {{- if .Values.global.logAsJson }}
        - --log_as_json
      {{- end }}
      {{- if .Values.global.proxy.lifecycle }}
        lifecycle:
          {{- toYaml .Values.global.proxy.lifecycle | nindent 10 }}
      {{- end }}
        env:
        - name: PILOT_CERT_PROVIDER
          value: {{ .Values.global.pilotCertProvider }}
        - name: CA_ADDR

  {{- end }}
  {{- if .Values.global.logAsJson }}
    - --log_as_json
  {{- end }}
  {{- if .Values.global.proxy.lifecycle }}
    lifecycle:
      {{ toYaml .Values.global.proxy.lifecycle | indent 6 }}
  {{- else if $holdProxy }}
    lifecycle:
      postStart:
        exec:
          command:
          - pilot-agent
          - wait
  {{- else if $nativeSidecar }}

  {{- end }}
  {{- if .Values.global.logAsJson }}
    - --log_as_json
  {{- end }}
  {{- if .Values.global.proxy.lifecycle }}
    lifecycle:
      {{ toYaml .Values.global.proxy.lifecycle | indent 6 }}
  {{- else if $holdProxy }}
    lifecycle:
      postStart:
        exec:
          command:
          - pilot-agent
          - wait
  {{- else if $nativeSidecar }}

  {{- if .Values.global.sts.servicePort }}
    - --stsPort={{ .Values.global.sts.servicePort }}
  {{- end }}
  {{- if .Values.global.logAsJson }}
    - --log_as_json
  {{- end }}
    lifecycle:
      postStart:
        exec:
          command:
          - pilot-agent
          - wait
          - --url=http://localhost:15020/healthz/ready
    env:
    - name: ISTIO_META_GENERATOR
      value: grpc

  //
  // The other mode is "Ephemeral". In this mode, volumes are defined inline inside the pod spec
  // with CSIVolumeSource and their lifecycle is tied to the lifecycle of that pod.
  // A driver has to be aware of this because it is only going to get a NodePublishVolume call for such a volume.
  //
  // For more information about implementing this mode, see

This component accomplishes that in the following ways:

1. By installing a separate, very basic "CNI plugin" binary onto the node to forward low-level pod lifecycle events (CmdAdd/CmdDel/etc) from whatever node-level CNI subsystem is in use to this node agent for processing via socket.
1. By running as a node-level daemonset that:

  //
  // The other mode is "Ephemeral". In this mode, volumes are defined inline inside the pod spec
  // with CSIVolumeSource and their lifecycle is tied to the lifecycle of that pod.
  // A driver has to be aware of this because it is only going to get a NodePublishVolume call for such a volume.
  //
  // For more information about implementing this mode, see

  // execution (either Complete or Failed). If this field is set,
  // ttlSecondsAfterFinished after the Job finishes, it is eligible to be
  // automatically deleted. When the Job is being deleted, its lifecycle
  // guarantees (e.g. finalizers) will be honored. If this field is unset,
  // the Job won't be automatically deleted. If this field is set to zero,
  // the Job becomes eligible to be deleted immediately after it finishes.

  // +optional
  optional int32 minReadySeconds = 9;

  // persistentVolumeClaimRetentionPolicy describes the lifecycle of persistent
  // volume claims created from volumeClaimTemplates. By default, all persistent
  // volume claims are created as needed and retained until manually deleted. This
  // policy allows the lifecycle to be altered, for example by deleting persistent

controller - the inputs to the controller are XDS connections. In response to each XDS connection, a `WorkloadEntry` is created to register the XDS client (which is generally `istio-proxy` running on a VM) to the mesh. This `WorkloadEntry` is tied to the lifecycle of the connection, with some logic to ensure that temporary downtime (reconnecting, etc) does not remove the `WorkloadEntry`.

The Health Check controller additionally controls the health status of the `WorkloadEntry`. The health is reported...