Project: Slime (Orchestration & Management / Service Mesh)
File: slime-boot.md

- - - - - This article will introduce the use of `SlimeBoot` and give you a sample usage to guide you to install and use the `slime` component. `slime-boot` can be understood as a `Controller`, it will always listen to the `SlimeBoot CR`, when the user submits a `SlimeBoot CR`, the `slime-boot Controller` will render the `slime` related deployment material according to the `CR` content. Before installing the `slime` component, you need to install `SlimeBoot CRD` and `deployment/slime-boot` Note: In k8s v1.22 and later, only the `apiextensions.k8s.io/v1` version of `CRD` is supported, and the `apiextensions.k8s.io/v1beta1` version of `CRD` is no longer supported, see the kubernetes.io/docs/reference/using-api/deprecation-guide/#customresourcedefinition-v122), and k8s v1.16~v1.21 both versions can be used For k8s v1.22 and later, you need to manually install [v1] (... /... /install/init/crds-v1.yaml), while the previous version can be installed manually (... /... /... /install/init/crds-v1.yaml) or [v1beta1] (... /... /install/init/crds.yaml) manually install Or install `CRD` and `deployment/slime-boot` by executing the following commands, note that if the network is not accessible, you can find the relevant documentation in the following directory `slime/install/init/` k8s version >= v1.22 ```shell export tagorcommit=$(curl -s https://api.github.com/repos/slime-io/slime/tags | grep 'name' | cut -d\" -f4 | head -1) kubectl create ns mesh-operator kubectl apply -f "https://raw.githubusercontent.com/slime-io/slime/$tagorcommit/install/init/crds-v1.yaml" kubectl apply -f "https://raw.githubusercontent.com/slime-io/slime/$tagorcommit/install/init/deployment_slime-boot.yaml" ``` k8s v1.16 <= version < 1.22 ```shell export tagorcommit=$(curl -s https://api.github.com/repos/slime-io/slime/tags | grep 'name' | cut -d\" -f4 | head -1) kubectl create ns mesh-operator kubectl apply -f "https://raw.githubusercontent.com/slime-io/slime/$tagorcommit/install/init/crds.yaml" kubectl apply -f "https://raw.githubusercontent.com/slime-io/slime/$tagorcommit/install/init/deployment_slime-boot.yaml" ``` ```shell export tagorcommit=$(curl -s https://api.github.com/repos/slime-io/slime/tags | grep 'name' | cut -d\" -f4 | head -1) kubectl create ns mesh-operator kubectl apply -f "https://raw.githubusercontent.com/slime-io/slime/$tagorcommit/install/init/crds-v1.yaml" kubectl apply -f "https://raw.githubusercontent.com/slime-io/slime/$tagorcommit/install/init/deployment_slime-boot.yaml" ``` According to the previous section, we know that the user installs the `slime` component by distributing `SlimeBoot`. In normal use, the user uses the `SlimeBoot CR` which contains the following parameters image: defines the parameters related to the image resources: defines the container resources module: defines the module to be started, and the corresponding parameters name: the name of the module kind: the category of the module, currently only lazyload/plugin/limiter are supported enable: whether to enable the module or not global: some global parameters that the module depends on, see for more details general: some parameters needed to start the module Examples are as follows ```yaml apiVersion: config.netease.com/v1alpha1 kind: SlimeBoot metadata: name: xxx ## real name namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-xxx ## real image tag: xxx ## real image module: name: xxx kind: xxx enable: true global: log: logLevel: info ``` `SlimeBoot` supports two types of installation Module deployment: you need to deploy a copy of `deployment` for each submodule The following yaml is an incomplete example of a module deployment, the first object defined in the module is the functionality that `SlimeBoot` should have ```yaml apiVersion:

kind: SlimeBoot metadata: name: xxx ## real name namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-xxx ## real image tag: xxx ## real image module: name: xxx kind: xxx enable: true global: log: logLevel: info ``` bundle deployment: just deploy a `deployment`, the `deployment` contains multiple component functions The following yaml is an incomplete example of the bundle pattern, where the first object of the module defines that the service has limiter and plugin functions, and the last two objects in the mudule correspond to the specific parameters of the limiter and plugin submodules, respectively ```yaml apiVersion: config.netease.com/v1alpha1 kind: SlimeBoot metadata: name: bundle namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-bundle-all tag: xx module: name: bundle enable: true bundle: modules: name: limiter kind: limiter name: plugin kind: plugin name: limiter kind: limiter enable: true mode: BundleItem general: {} global: {} name: plugin kind: plugin enable: true mode: BundleItem ``` The following will install the `lazyload`, `limiter` and `plugin` modules in a modular way and the `bundle` module in `bundle` mode Deployment supports lazyload module at `cluster` level, after successful deployment `deployment` named `lazyload` and `global-sidecar` under `mesh-operator` namespace istioNamespace: the `ns` of the `istio` deployment in the user cluster module: specifies the parameters for `lazyload` deployment name: the name of the module kind: the category of the module, currently only lazyload/plugin/limiter is supported enable: whether to enable the module general: `lazyload` startup related parameters global: some global parameters that `lazyload` depends on, see metric: information about the metrics that `lazyload` depends on for the electrophoretic relationship between services component: the configuration of `globalSidecar` in the lazyload module, which is generally not changed except for mirroring ```yaml apiVersion: config.netease.com/v1alpha1 kind: SlimeBoot metadata: name: lazyload namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-lazyload tag: v0.9.0 namespace: mesh-operator istioNamespace: istio-system module: name: lazyload kind: lazyload enable: true general: autoPort: false autoFence: true defaultFence: false wormholePort: # replace to your application service ports, and extend the list in case of multi ports "9080" globalSidecarMode: cluster # the mode of global-sidecar metricSourceType: accesslog # indicate the metric source global: log: logLevel: info slimeNamespace: mesh-operator resources: requests: cpu: 300m memory: 300Mi limits: cpu: 600m memory: 600Mi component: globalSidecar: enable: true sidecarInject: enable: true # should be true mode: pod labels: # optional, used for sidecarInject.mode = pod sidecar.istio.io/inject: "true" resources: requests: cpu: 200m memory: 200Mi limits: cpu: 400m memory: 400Mi image: repository: docker.io/slimeio/slime-global-sidecar tag:

probePort: 20000 ``` Install a limiter module that supports single-computer limiting, and deploy a `deployment` named `limiter` under the `mesh-operator` namespace after success image: Specify the image of `limiter`, including policy, repository, tag module: Specifies the parameters for `limiter` deployment name: the name of the module kind: module category, currently only supports lazyload/plugin/limiter enable: whether to enable the module general: `limiter` startup related parameters disableGlobalRateLimit: disable global shared limiting disableAdaptive: Disable adaptive limiting disableInsertGlobalRateLimit: disables the module from inserting global flow-limiting related plugins global: Some global parameters that `limiter` depends on. global specific parameters can be found in ```yaml apiVersion: config.netease.com/v1alpha1 kind: SlimeBoot metadata: name: limiter namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-limiter tag: v0.9.0 module: name: limiter kind: limiter enable: true general: disableGlobalRateLimit: true disableAdaptive: true disableInsertGlobalRateLimit: true ``` Install the plugin module image: Specify the `limiter` image, including policy, repository, tag module: Specify the parameters for `limiter` deployment name: module name kind: module category, currently only supports lazyload/plugin/limiter enable: whether to enable the module global: some global parameters that `plugin` depends on, global specific parameters can be found in ```yaml apiVersion: config.netease.com/v1alpha1 kind: SlimeBoot metadata: name: limiter namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-plugin tag: v0.9.0 module: name: plugin kind: plugin enable: true ``` In the above example, we deployed `lazyload`, `limiter` and `plugin` modules, now we install the `bundle` module with the above three functions in `bundle` mode ```yaml apiVersion: config.netease.com/v1alpha1 kind: SlimeBoot metadata: name: bundle namespace: mesh-operator spec: image: pullPolicy: Always repository: docker.io/slimeio/slime-bundle-all tag: v0.9.0 module: name: bundle enable: true bundle: modules: name: lazyload kind: lazyload name: limiter kind: limiter name: plugin kind: plugin global: log: logLevel: info name: lazyload kind: lazyload enable: true mode: BundleItem general: autoPort: false autoFence: true defaultFence: false wormholePort: # replace to your application service ports, and extend the list in case of multi ports "9080" globalSidecarMode: cluster # the mode of global-sidecar metricSourceType: accesslog # indicate the metric source global: slimeNamespace: mesh-operator log: logLevel: info name: limiter kind: limiter enable: true mode: BundleItem general: disableGlobalRateLimit: true disableAdaptive: true disableInsertGlobalRateLimit: true name: plugin kind: plugin enable: true mode: BundleItem component: globalSidecar: replicas: 1 enable: true sidecarInject: enable: true # should be true mode: pod resources: limits: cpu: 2000m memory: 2048Mi requests: cpu: 1000m memory: 1024Mi image: repository: docker.io/slimeio/slime-global-sidecar tag: v0.9.0 probePort: 20000 # health probe port port: 80 # global-sidecar default svc port legacyFilterName: true ``` Regarding the Config.global involved above, the content is as follows. | Key | Default Value | Usages | Remark | |--|-|-|--| | service | app | servicefencelabel keysidecar | | | istioNamespace | istio-system | istionamespacesidecaristionamespace | | | slimeNamespace | mesh-operator | slimenamespacesidecarslimeboot crnamespace | | | log.logLevel | "" | slime | | | log.klogLevel | 0 | klog | | | log.logRotate | false | | | | log.logRotateConfig.filePath | "/tmp/log/slime.log" | | | | log.logRotateConfig.maxSizeMB | 100 | MB | | | log.logRotateConfig.maxBackups | 10 | | | | log.logRotateConfig.maxAgeDay | 10 | | | | log.logRotateConfig.compress | false | | | | misc | {"metrics-addr": ":8080", "aux-addr": ":8081"}, | 1."metrics-addr"slime module manager2."aux-addr" | | seLabelSelectorKeys | app | se | | | xdsSourceEnableIncPush | true | xds | | pathRedirect | "" | path |