{"id":13683791,"url":"https://github.com/istio/operator","last_synced_at":"2025-04-30T20:31:32.570Z","repository":{"id":57487376,"uuid":"180454522","full_name":"istio/operator","owner":"istio","description":"Istio operator provides user friendly options to operate the Istio service mesh","archived":true,"fork":false,"pushed_at":"2020-09-02T19:42:48.000Z","size":45369,"stargazers_count":173,"open_issues_count":10,"forks_count":81,"subscribers_count":101,"default_branch":"master","last_synced_at":"2024-10-02T17:45:45.365Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/istio.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null}},"created_at":"2019-04-09T21:49:13.000Z","updated_at":"2024-09-03T04:25:21.000Z","dependencies_parsed_at":"2022-09-01T23:02:25.160Z","dependency_job_id":null,"html_url":"https://github.com/istio/operator","commit_stats":null,"previous_names":[],"tags_count":27,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/istio%2Foperator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/istio%2Foperator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/istio%2Foperator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/istio%2Foperator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/istio","download_url":"https://codeload.github.com/istio/operator/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":224224667,"owners_count":17276428,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-02T14:00:16.697Z","updated_at":"2024-11-12T05:30:20.689Z","avatar_url":"https://github.com/istio.png","language":"Go","readme":"[![Go Report Card](https://goreportcard.com/badge/github.com/istio/operator)](https://goreportcard.com/report/github.com/istio/operator)\n[![GolangCI](https://golangci.com/badges/github.com/istio/operator.svg)](https://golangci.com/r/github.com/istio/operator)\n\nNote: This repo has been merged to [istio.io/istio/operator](https://github.com/istio/istio/blob/master/operator/).\nPlease go to that repo to make any changes to operator or installer charts. The only exception is bug backports to the\n1.4 branch, which should be submitted here. \nThe text below is preserved for reference but is no longer maintained at this location.\n\n# Istio Operator\n\nThe Istio operator CLI is beta and the controller is alpha for 1.4. You can\n[contribute](CONTRIBUTING.md) by picking an\n[unassigned open issue](https://github.com/istio/istio/issues?q=is%3Aissue+is%3Aopen+label%3Aarea%2Fenvironments%2Foperator+no%3Aassignee),\ncreating a [bug or feature request](BUGS-AND-FEATURE-REQUESTS.md),\nor just coming to the weekly [Environments Working Group](https://github.com/istio/community/blob/master/WORKING-GROUPS.md)\nmeeting to share your ideas.\n\nThis document is an overview of how the operator works from a user perspective. For more details about the design and\narchitecture and a code overview, see [ARCHITECTURE.md](./ARCHITECTURE.md).\n\nThe operator CLI is distributed to users as part of istioctl. The `mesh` command\nin this repo is simply a wrapper to speed up development - the subcommands are the same code that is incorporated into\nistioctl. Making changes to any `mesh` subcommand will be reflected in istioctl after one of the regular syncs to\nistio/operator.\n\n## Introduction\n\nThis repo reorganizes the current [Helm installation parameters](https://istio.io/docs/reference/config/installation-options/) into two groups:\n\n- The new [platform level installation API](https://github.com/istio/api/mesh/v1alpha1/operator.proto), for managing\nK8s settings like resources, auto scaling, pod disruption budgets and others defined in the\n[KubernetesResourceSpec](https://github.com/istio/api/blob/7791470ecc4c5e123589ff2b781f47b1bcae6ddd/operator/v1alpha1/component.proto)\n- The configuration API that currently uses the\n[Helm installation parameters](https://istio.io/docs/reference/config/installation-options/) for backwards\ncompatibility. This API is for managing the Istio control plane configuration settings.\n\nSome parameters will temporarily exist in both APIs - for example, setting K8s resources currently can be done through\neither API above. However, the Istio community recommends using the first API as it is more consistent, is validated,\nand will naturally follow the graduation process for APIs while the same parameters in the configuration API are planned\nfor deprecation.\n\nThis repo currently provides pre-configured Helm values sets for different scenarios as configuration\n[profiles](https://istio.io/docs/setup/kubernetes/additional-setup/config-profiles/), which act as a starting point for\nan Istio install and can be customized by creating customization overlay files or passing parameters when\ncalling Helm. Similarly, the operator API uses the same profiles (expressed internally through the new API), which can be selected\nas a starting point for the installation. For comparison, the following example shows the command needed to install\nIstio using the SDS configuration profile using Helm:\n\n```bash\nhelm template install/kubernetes/helm/istio --name istio --namespace istio-system \\\n    --values install/kubernetes/helm/istio/values-istio-sds-auth.yaml | kubectl apply -f -\n```\n\nIn the new API, the same profile would be selected through a CustomResource (CR):\n\n```yaml\n# sds.yaml\n\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  profile: sds\n```\n\nSee [Select a specific configuration_profile](#select-a-specific-configuration-profile) for more information.\n\nIf you don't specify a configuration profile, Istio is installed using the `default` configuration profile. All\nprofiles listed in istio.io are available by default, or `profile:` can point to a local file path to reference a custom\nprofile base to use as a starting point for customization. See the [API reference](https://github.com/istio/api/operator/v1alpha1/operator.proto)\nfor details.\n\n## Developer quick start\n\nThe quick start describes how to install and use the operator `mesh` CLI command and/or controller.\n\n### Building\n\nIf you're trying to do a local build that bypasses the build container, you'll need to\nto execute the following step one time.\n\n```\nGO111MODULE=on go get github.com/jteeuwen/go-bindata/go-bindata@6025e8de665b\n```\n\n#### Clone the repo\n\n```bash\ngit clone https://github.com/istio/operator.git\ncd operator\n```\n\n#### CLI\n\nTo build the operator CLI, simply:\n\n```bash\nmake mesh\n```\n\nThis will create a binary called `mesh` either in ${GOPATH}/bin or ${GOPATH}/go/src/istio.io/operator/out/\u003carchitecture\u003e,\ndepending on your platform. Ensure this is in your PATH to run the examples below.\n\n#### Controller (in cluster)\n\nBuilding a custom controller requires a Dockerhub (or similar) account. To build using the container based build:\n\n```bash\nHUB=docker.io/\u003cyour-account\u003e TAG=latest make docker.all\n```\n\nThis builds the controller binary and docker file, and pushes the image to the specified hub with the `latest` tag.\nOnce the images are pushed, configure kubectl to point to your cluster and install the controller. You should edit\nthe file deploy/operator.yaml to point to your docker hub:\n\n```yaml\n          image: docker.io/\u003cyour-account\u003e/operator\n```\n\nInstall the controller manifest and example IstioOperator CR:\n\n```bash\nkubectl apply -k deploy/\nkubectl apply -f deploy/crds/istio_v1alpha1_istiooperator_cr.yaml \n```\n\nThis installs the controller into the cluster in the istio-operator namespace. The controller in turns installs\nthe Istio control plane into the istio-system namespace by default.\n\n#### Controller (running locally)\n\n1. Set env $WATCH_NAMESPACE and $LEADER_ELECTION_NAMESPACE (default value is \"istio-operator\")\n\n1. From the operator repo root directory, run `go run ./cmd/manager/*.go server `\n\nTo use Remote debugging with IntelliJ, replace above step 2 with following:\n\n1. From ./cmd/manager path run\n`\ndlv debug --headless --listen=:2345 --api-version=2 -- server\n`.\n\n1. In IntelliJ, create a new Go Remote debug configuration with default settings.\n\n1. Start debugging process and verify it is working. For example, try adding a breakpoint at Reconcile logic and apply a new CR.\n\n### Relationship between the CLI and controller\n\nThe CLI and controller share the same API and codebase for generating manifests from the API. You can think of the\ncontroller as the CLI command `mesh manifest apply` running in a loop in a pod in the cluster and using the config\nfrom the in-cluster IstioOperator CustomResource (CR). \nThere are two major differences:\n1. The controller does not accept any dynamic user config through flags. All user interaction is through the\nIstioOperator CR.\n1. The controller has additional logic that mirrors istioctl commands like upgrade, but is driven from the declarative\nAPI rather than command line.\n\n### Quick tour of CLI commands\n\n#### Flags\n\nThe `mesh` command supports the following flags:\n\n- `logtostderr`: log to console (by default logs go to ./mesh-cli.log).\n- `dry-run`: console output only, nothing applied to cluster or written to files.\n- `verbose`: display entire manifest contents and other debug info (default is false).\n\n#### Basic default manifest\n\nThe following command generates a manifest with the compiled-in `default` profile and charts:\n\n```bash\nmesh manifest generate\n```\n\nYou can see these sources for the compiled-in profiles and charts in the repo under `data/`. These profiles and charts are also included in the Istio release tar. \n\n#### Output to dirs\n\nThe output of the manifest is concatenated into a single file. To generate a directory hierarchy with subdirectory\nlevels representing a child dependency, use the following command:\n\n```bash\nmesh manifest generate -o istio_manifests\n```\n\nUse depth first search to traverse the created directory hierarchy when applying your YAML files. This is needed for\ncorrect sequencing of dependencies. Child manifest directories must wait for their parent directory to be fully applied,\nbut not their sibling manifest directories.\n\n#### Just apply it for me\n\nThe following command generates the manifests and applies them in the correct dependency order, waiting for the\ndependencies to have the needed CRDs available:\n\n```bash\nmesh manifest apply\n```\n\n#### Review the values of a configuration profile\n\nThe following commands show the values of a configuration profile:\n\n```bash\n# show available profiles\nmesh profile list\n\n# show the values in demo profile\nmesh profile dump demo\n\n# show the values after a customization file is applied\nmesh profile dump -f samples/policy-off.yaml\n\n# show differences between the default and demo profiles\nmesh profile dump default \u003e 1.yaml\nmesh profile dump demo \u003e 2.yaml\nmesh profile diff 1.yaml 2.yaml\n\n# show the differences in the generated manifests between the default profile and a customized install\nmesh manifest generate \u003e 1.yaml\nmesh manifest generate -f samples/pilot-k8s.yaml \u003e 2.yaml\nmesh manifest diff 1.yam1 2.yaml\n\n```\n\nThe profile dump sub-command supports a couple of useful flags:\n\n- `config-path`: select the root for the configuration subtree you want to see e.g. just show Pilot:\n\n```bash\nmesh profile dump --config-path components.pilot\n```\n\n- `set`: set a value in the configuration before dumping the resulting profile e.g. show the minimal profile:\n\n```bash\nmesh profile dump --set profile=minimal\n```\n\n\n#### Select a specific configuration profile\n\nThe simplest customization is to select a profile different to `default` e.g. `sds`. See [samples/sds.yaml](samples/sds.yaml):\n\n```yaml\n# sds-install.yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  profile: sds\n```\n\nUse the Istio operator `mesh` binary to generate the manifests for the new configuration profile:\n\n```bash\nmesh manifest generate -f samples/sds.yaml\n```\n\nAfter running the command, the Helm charts are rendered using `data/profiles/sds.yaml`.\n\n#### Install from file path\n\nThe compiled in charts and profiles are used by default, but you can specify a file path, for example:\n\n```yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  profile: /usr/home/bob/go/src/github.com/ostromart/istio-installer/data/profiles/default.yaml\n  installPackagePath: /usr/home/bob/go/src/github.com/ostromart/istio-installer/data/charts/\n```\n\nYou can mix and match these approaches. For example, you can use a compiled-in configuration profile with charts in your\nlocal file system.\n\n#### Migration from values.yaml\nThe following command takes helm values.yaml files and output the new IstioOperatorSpec:\n```bash\nmesh manifest migrate /usr/home/bob/go/src/istio.io/installer/istio-control/istio-discovery/values.yaml\n```\n\nIf a directory is specified, all files called \"values.yaml\" under the directory will be converted into a single combined IstioOperatorSpec:\n```bash\nmesh manifest migrate /usr/home/bob/go/src/istio.io/installer/istio-control\n```\n\nIf no file is specified, the IstioOperator CR in the kube config cluster is used as an input:\n```bash\nmesh manifest migrate\n```\n\n#### Check diffs of manifests\nThe following command takes two manifests and output the differences in a readable way. It can be used to compare between the manifests generated by operator API and helm directly:\n```bash\nmesh manifest diff ./out/helm-template/manifest.yaml ./out/mesh-manifest/manifest.yaml\n```\n\n### New API customization\n\nThe [new platform level installation API](https://github.com/istio/api/operator/v1alpha1/operator.proto)\ndefines install time parameters like feature and component enablement and namespace, and K8s settings like resources, HPA spec etc. in a structured way.\nThe simplest customization is to turn features and components on and off. For example, to turn off all policy ([samples/sds-policy-off.yaml](samples/sds-policy-off.yaml)):\n\n```yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  profile: sds\n  components:\n    policy:\n      enabled: false\n```\n\nThe operator validates the configuration and automatically detects syntax errors. Helm lacks this capability. If you are\nusing Helm values that are incompatible, the schema validation used in the operator may reject input that is valid for\nHelm. \nEach Istio component has K8s settings, and these can be overridden from the defaults using official K8s APIs rather than\nIstio defined schemas ([samples/pilot-k8s.yaml](samples/pilot-k8s.yaml)):\n\n```yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  components:\n    pilot:\n      k8s:\n        resources:\n          requests:\n            cpu: 1000m # override from default 500m\n            memory: 4096Mi # ... default 2048Mi\n          hpaSpec:\n            maxReplicas: 10 # ... default 5\n            minReplicas: 2  # ... default 1\n          nodeSelector: # ... default empty\n            master: \"true\"\n          tolerations: # ... default empty\n          - key: dedicated\n            operator: Exists\n            effect: NoSchedule\n          - key: CriticalAddonsOnly\n            operator: Exists\n```\n\nThe K8s settings are defined in detail in the\n[operator API](https://github.com/istio/api/operator/v1alpha1/operator.proto).\nThe settings are the same for all components, so a user can configure pilot K8s settings in exactly the same, consistent\nway as galley settings. Supported K8s settings currently include:\n\n- [resources](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)\n- [readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)\n- [replica count](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- [HorizontalPodAutoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)\n- [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#how-disruption-budgets-work)\n- [pod annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)\n- [container environment variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/)\n- [ImagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/)\n- [priority calss name](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass)\n- [node selector](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector)\n- [toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)\n- [affinity and anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)\n- [deployment strategy](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n\nAll of these K8s settings use the K8s API definitions, so [K8s documentation](https://kubernetes.io/docs/concepts/) can\nbe used for reference. All K8s overlay values are also validated in the operator.\n\n### Customizing the old values.yaml API\n\nThe new platform install API above deals with K8s level settings. The remaining values.yaml parameters deal with Istio\ncontrol plane operation rather than installation. For the time being, the operator just passes these through to the Helm\ncharts unmodified (but validated through a\n[schema](pkg/apis/istio/v1alpha1/values_types.proto)). Values.yaml settings\nare overridden the same way as the new API, though a customized CR overlaid over default values for the selected\nprofile. Here's an example of overriding some global level default values ([samples/values-global.yaml](samples/values-global.yaml)):\n\n```yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  profile: sds\n  values:\n    global:\n      logging:\n        level: \"default:warning\" # override from info\n```\n\nValues overrides can also be specified for a particular component\n ([samples/values-pilot.yaml](samples/values-pilot.yaml)):\n\n```yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  values:\n    mixer:\n      telemetry:\n        loadshedding:\n          latencyThreshold: 200ms  \n```\n\n### Advanced K8s resource overlays\n\nAdvanced users may occasionally have the need to customize parameters (like container command line flags) which are not\nexposed through either of the installation or configuration APIs described in this document. For such cases, it's\npossible to overlay the generated K8s resources before they are applied with user-defined overlays. For example, to\noverride some container level values in the Pilot container  ([samples/pilot-advanced-override.yaml](samples/pilot-advanced-override.yaml)):\n\n```yaml\napiVersion: operator.istio.io/v1alpha1\nkind: IstioOperator\nspec:\n  components:\n    pilot:\n      k8s:\n        overlays:\n        - kind: Deployment\n          name: istio-pilot\n          patches:\n          - path: spec.template.spec.containers.[name:discovery].args.[30m]\n            value: \"60m\" # OVERRIDDEN\n          - path: spec.template.spec.containers.[name:discovery].ports.[containerPort:8080].containerPort\n            value: 8090 # OVERRIDDEN\n        - kind: Service\n          name: istio-pilot\n          patches:\n          - path: spec.ports.[name:grpc-xds].port\n            value: 15099 # OVERRIDDEN\n```\n\nThe user-defined overlay uses a path spec that includes the ability to select list items by key. In the example above,\nthe container with the key-value \"name: discovery\" is selected from the list of containers, and the command line\nparameter with value \"30m\" is selected to be modified. The advanced overlay capability is described in more detail in\nthe spec.\n\n## Interaction with controller\n\nThe controller shares the same API as the operator CLI, so it's possible to install any of the above examples as a CR\nin the cluster in the istio-operator namespace and the controller will react to it with the same outcome as running\n`mesh manifest apply -f \u003cpath-to-custom-resource-file\u003e`.\n\n## Architecture\n\nSee [ARCHITECTURE.md](ARCHITECTURE.md)\n","funding_links":[],"categories":["operator候选列表","Resources"],"sub_categories":["部署类型","Official Resources"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fistio%2Foperator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fistio%2Foperator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fistio%2Foperator/lists"}