optional int32 periodSeconds = 3;
}

// HPAScalingRules configures the scaling behavior for one direction.
// These Rules are applied after calculating DesiredReplicas from metrics for the HPA.
// They can limit the scaling velocity by specifying scaling policies.
// They can prevent flapping by specifying the stabilization window, so that the

  optional string container = 4;
}

// ContainerResourceMetricStatus indicates the current value of a resource metric known to
// Kubernetes, as specified in requests and limits, describing a single container in each pod in the
// current scale target (e.g. CPU or memory).  Such metrics are built in to
// Kubernetes, and have special scaling options on top of those available to

  // podManagementPolicy controls how pods are created during initial scale up,
  // when replacing pods on nodes, or when scaling down. The default policy is
  // `OrderedReady`, where pods are created in increasing order (pod-0, then
  // pod-1, etc) and the controller will wait until each pod is ready before
  // continuing. When scaling down, the pods are removed in the opposite order.
  // The alternative policy is `Parallel` which will create pods in parallel

  optional int32 periodSeconds = 3;
}

// HPAScalingRules configures the scaling behavior for one direction.
// These Rules are applied after calculating DesiredReplicas from metrics for the HPA.
// They can limit the scaling velocity by specifying scaling policies.
// They can prevent flapping by specifying the stabilization window, so that the

  optional string container = 5;
}

// ContainerResourceMetricStatus indicates the current value of a resource metric known to
// Kubernetes, as specified in requests and limits, describing a single container in each pod in the
// current scale target (e.g. CPU or memory).  Such metrics are built in to
// Kubernetes, and have special scaling options on top of those available to

  // podManagementPolicy controls how pods are created during initial scale up,
  // when replacing pods on nodes, or when scaling down. The default policy is
  // `OrderedReady`, where pods are created in increasing order (pod-0, then
  // pod-1, etc) and the controller will wait until each pod is ready before
  // continuing. When scaling down, the pods are removed in the opposite order.
  // The alternative policy is `Parallel` which will create pods in parallel

  // podManagementPolicy controls how pods are created during initial scale up,
  // when replacing pods on nodes, or when scaling down. The default policy is
  // `OrderedReady`, where pods are created in increasing order (pod-0, then
  // pod-1, etc) and the controller will wait until each pod is ready before
  // continuing. When scaling down, the pods are removed in the opposite order.
  // The alternative policy is `Parallel` which will create pods in parallel

  // Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods
  // immediately when the rolling update starts. Once new pods are ready, old RC
  // can be scaled down further, followed by scaling up the new RC, ensuring
  // that the total number of pods available at all times during the update is at
  // least 70% of desired pods.
  // +optional

      excludeInboundPorts: ""
      includeInboundPorts: "*"

      # istio egress capture allowlist
      # https://istio.io/docs/tasks/traffic-management/egress.html#calling-external-services-directly
      # example: includeIPRanges: "172.30.0.0/16,172.20.0.0/16"
      # would only capture egress traffic on those two IP Ranges, all other outbound traffic would
      # be allowed by the sidecar

	// this can happen if the pod was dynamically added to the mesh after it was created.
	// in that case, try finding the netns using procfs.
	if err := s.rescanPod(pod); err != nil {
		log.Errorf("error scanning proc: error was %s", err)
		return nil, err
	}
	// try again. we can still get here if the pod is in the process of being created.
	// in this case the CNI will be invoked soon and provide us with the netns.