Minimum resources for control plane

[olaf-meyer]

Hello,

During an installation of the Service Mesh Control Plane, we ran into an issue that was caused by too small default requests and default limits in the limit rate of the project. We didn't specify any resources (requests/limits) in the Service Mesh Control Plane. What would be the minimal resource setting to running the Service Mesh Control Plane for testing purposes? Is my assumption correct that, if I update the resources in the Service Mesh Control Plane, these changes will be reflected in the deployment? In the general section does the attribute Proxy refer to the sidecar container proxy or which proxy is meant?

Kind regards,

Olaf

[nicop311]

Hello, I think I have the same sort of problem than @olaf-meyer . For me the issue was with Jaeger and spec.resources.limits.

Sofware version

• OKD cluster version: 4.5.0-0.okd-2020-09-04-180756

  Kernel Version:                         5.6.19-300.fc32.x86_64
  OS Image:                               Fedora CoreOS 32.20200629.3.0
  Operating System:                       linux
  Architecture:                           amd64
  Container Runtime Version:              cri-o://1.18.2
  Kubelet Version:                        v1.18.3
  Kube-Proxy Version:                     v1.18.3

Operator name	Version	vendor
Elastic Cloud on Kubernetes	1.2.1	provided by Elastic
Grafana Operator	3.5.0	provided by Red Hat
Community Jaeger Operator	1.19.0	provided by CNCF
Kiali Operator	1.22.0	provided by Kiali
Maistra Service Mesh	1.1.1	provided by Red Hat, Inc.

How to reproduce the spec.resources.limits error

As of mid-September 2020, I was following this Maistra Documentation: Installing a control plane.

I try to install a ServiceMeshControlPlane using the following configuration:

# File maistra.yaml
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
metadata:
  name: minimal-install
spec:
  istio:
    global:
      proxy:
        # constrain resources for use in smaller environments
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 128Mi

    gateways:
      istio-egressgateway:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false
      istio-ingressgateway:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false
        # set to true to enable IOR
        ior_enabled: false
    mixer:
      policy:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false

      telemetry:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false
        # constrain resources for use in smaller environments
        resources:
          requests:
            cpu: 100m
            memory: 1G
          limits:
            cpu: 500m
            memory: 4G

    pilot:
      # disable autoscaling for use in smaller environments
      autoscaleEnabled: false
      # increase random sampling rate for development/testing
      traceSampling: 100.0

    kiali:
      # to disable kiali
      enabled: false

      # create a secret for accessing kiali dashboard with the following credentials
      # dashboard:
      #   user: admin
      #   passphrase: admin

    # disable grafana
    grafana:
      enabled: false

    # to disable tracing (i.e. jaeger)
    tracing:
      enabled: false
      jaeger:
        tag: 1.13.1
        # simple, all-in-one strategy
        template: all-in-one
        # production strategy, utilizing elasticsearch
        #template: production-elasticsearch
        # if required. only one instance may use agentStrategy=DaemonSet
        #agentStrategy: DaemonSet

I make a few changes to this maistra.yaml SMCP file: I enable kiali, grafana, and tracing by setting enabled: true.

Then I create the ServiceMeshControlPlane:

oc new-project istio-system
oc create -n istio-system -f maistra.yaml

However, instead of 12 pods, I do only get 2 pods: citadel and prometheus.

oc get pod -n istio-system
# result
NAME                             READY   STATUS    RESTARTS   AGE
istio-citadel-56c7d5bfc9-5pkq9   1/1     Running   0          12m
prometheus-765b8d747d-kczzs      2/2     Running   0          12m

In fact, I have the following error:

Error processing component tracing: error: Jaeger.jaegertracing.io "jaeger" is 
invalid: spec.resources.limits: Invalid value: "null": spec.resources.limits 
in body must be of type object: "null"

How do I troobleshoot / workarround

I force the value of spec.resources.limits in the ServiceMeshControlPlane configuration file.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
metadata:
  name: minimal-install
  namespace: istio-system
spec:
  istio:
    global:
      mtls:
        # Enable mutual TLS
        enabled: true
      proxy:
        # constrain resources for use in smaller environments
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 128Mi

    gateways:
      istio-egressgateway:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false
      istio-ingressgateway:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false
        # set to true to enable IOR
        ior_enabled: false
    mixer:
      policy:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false

      telemetry:
        # disable autoscaling for use in smaller environments
        autoscaleEnabled: false
        # constrain resources for use in smaller environments
        resources:
          requests:
            cpu: 100m
            memory: 1G
          limits:
            cpu: 500m
            memory: 4G

    pilot:
      # disable autoscaling for use in smaller environments
      autoscaleEnabled: false
      # increase random sampling rate for development/testing
      traceSampling: 100.0

    kiali:
      # to disable kiali
      enabled: true

      # create a secret for accessing kiali dashboard with the following credentials
      dashboard:
        user: admin
        passphrase: admin

    # disable grafana
    grafana:
      enabled: true

    # to disable tracing (i.e. jaeger)
    tracing:
      enabled: true
      jaeger:
        # simple, all-in-one strategy
        template: all-in-one
        # production strategy, utilizing elasticsearch
        #template: production-elasticsearch
        # if required. only one instance may use agentStrategy=DaemonSet
        #agentStrategy: DaemonSet
        resources:
          requests:
            cpu: 100m
            memory: 1G
          limits:
            cpu: 500m
            memory: 4G

---
apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:
  - bookinfo

The following vimdiff picture shows the difference between the file suggested in the doc (left) vs the file that I use in my workaround (right).

With this ServiceMeshControlPlane configuration I was able to proceed with the bookinfo example from Maistra.

Note 1: I think it is not necessary to give Kiali kiali.dashboard.user and kiali.dashboard.passphrase because you can log into Kiali's dashboard with your OKD user.

Note 2: My aim was to try the bookinfo example with mutualTLS. therefore I also force mTLS.

A few suggestion

Consider changing the documentation about the default values for ServiceMeshControlPlane components like Jaeger.