# Istio Installer
Note: If making any changes to the charts or values.yaml in this dir, first read [UPDATING-CHARTS.md](UPDATING-CHARTS.md)
Istio installer is a modular, 'a-la-carte' installer for Istio. It is based on a
fork of the Istio helm templates, refactored to increase modularity and isolation.
Goals:
- Improve upgrade experience: users should be able to gradually roll upgrades, with proper
canary deployments for Istio components. It should be possible to deploy a new version while keeping the
stable version in place and gradually migrate apps to the new version.
- More flexibility: the new installer allows multiple 'environments', allowing applications to select
a set of control plane settings and components. While the entire mesh respects the same APIs and config,
apps may target different 'environments' which contain different instances and variants of Istio.
- Better security: separate Istio components reside in different namespaces, allowing different teams or
roles to manage different parts of Istio. For example, a security team would maintain the
root CA and policy, a telemetry team may only have access to Prometheus,
and a different team may maintain the control plane components (which are highly security sensitive).
The install is organized in 'environments' - each environment consists of a set of components
in different namespaces that are configured to work together. Regardless of 'environment',
workloads can talk with each other and obey the Istio configuration resources, but each environment
can use different Istio versions and different configuration defaults.
`istioctl kube-inject` or the automatic sidecar injector are used to select the environment.
In the case of the sidecar injector, the namespace label `istio-env: <NAME_OF_ENV>` is used instead
of the conventional `istio-injected: true`. The name of the environment is defined as the namespace
where the corresponding control plane components (config, discovery, auto-injection) are running.
In the examples below, by default this is the `istio-control` namespace. Pod annotations can also
be used to select a different 'environment'.
## Installing
The new installer is intended to be modular and very explicit about what is installed. It has
far more steps than the Istio installer - but each step is smaller and focused on a specific
feature, and can be performed by different people/teams at different times.
It is strongly recommended that different namespaces are used, with different service accounts.
In particular access to the security-critical production components (root CA, policy, control)
should be locked down and restricted. The new installer allows multiple instances of
policy/control/telemetry - so testing/staging of new settings and versions can be performed
by a different role than the prod version.
The intended users of this repo are users running Istio in production who want to select, tune
and understand each binary that gets deployed, and select which combination to use.
Note: each component can be installed in parallel with an existing Istio 1.0 or 1.1 install in
`istio-system`. The new components will not interfere with existing apps, but can interoperate
and it is possible to gradually move apps from Istio 1.0/1.1 to the new environments and
across environments ( for example canary -> prod )
Note: there are still some cluster roles that may need to be fixed, most likely cluster permissions
will need to move to the security component.
## Everything is Optional
Each component in the new installer is optional. Users can install the component defined in the new installer,
use the equivalent component in `istio-system`, configured with the official installer, or use a different
version or implementation.
For example you may use your own Prometheus and Grafana installs, or you may use a specialized/custom
certificate provisioning tool, or use components that are centrally managed and running in a different cluster.
This is a work in progress - building on top of the multi-cluster installer.
As an extreme, the goal is to be possible to run Istio workloads in a cluster without installing any Istio component
in that cluster. Currently the minimum we require is the security provider (node agent or citadel).
### Install Istio CRDs
This is the first step of the install. Please do not remove or edit any CRD - config currently requires
all CRDs to be present. On each upgrade it is recommended to reapply the file, to make sure
you get all CRDs. CRDs are separated by release and by component type in the CRD directory.
Istio has strong integration with certmanager. Some operators may want to keep their current certmanager
CRDs in place and not have Istio modify them. In this case, it is necessary to apply CRD files individually.
```bash
kubectl apply -k github.com/istio/installer/base
```
or
```bash
kubectl apply -f base/files
```
### Install Istio-CNI
This is an optional step - CNI must run in a dedicated namespace, it is a 'singleton' and extremely
security sensitive. Access to the CNI namespace must be highly restricted.
**NOTE:** The environment variable `ISTIO_CLUSTER_ISGKE` is assumed to be set to `true` if the cluster
is a GKE cluster.
```bash
ISTIO_CNI_ARGS=
# TODO: What k8s data can we use for this check for whether GKE?
if [[ "${ISTIO_CLUSTER_ISGKE}" == "true" ]]; then
ISTIO_CNI_ARGS="--set cni.cniBinDir=/home/kubernetes/bin"
fi
iop kube-system istio-cni $IBASE/istio-cni/ ${ISTIO_CNI_ARGS}
```
TODO. It is possible to add Istio-CNI later, and gradually migrate.
### Install Control plane
This can run in any cluster. A mesh should have at least one cluster should run Pilot or equivalent XDS server,
and it is recommended to have Pilot running in each region and in multiple availability zones for multi cluster.
```bash
iop istio-control istio-discovery $IBASE/istio-control/istio-discovery \
--set global.istioNamespace=istio-system
# Second istio-discovery, using master version of istio
TAG=latest HUB=gcr.io/istio-testing iop istio-master istio-discovery-master $IBASE/istio-control/istio-discovery \
--set policy.enable=false \
--set global.istioNamespace=istio-master
```
### Gateways
A cluster may use multiple Gateways, each with a different load balancer IP, domains and certificates.
Since the domain certificates are stored in the gateway namespace, it is recommended to keep each
gateway in a dedicated namespace and restrict access.
For large-scale gateways it is optionally possible to use a dedicated pilot in the gateway namespace.
### Additional test templates
A number of helm test setups are general-purpose and should be installable in any cluster, to confirm
Istio works properly and allow testing the specific install.
没有合适的资源?快使用搜索试试~ 我知道了~
istio-1.11.5
共257个文件
yaml:195个
md:20个
pem:12个
需积分: 0 0 下载量 121 浏览量
2024-03-15
16:30:39
上传
评论
收藏 22.87MB ZIP 举报
温馨提示
服务治理istio安装包 istio-1.11.5-linux-amd64 版本: 1.11.5 使用方法 进入bin目录 参考官网:https://istio.io/latest/zh/docs/setup/install/istioctl/ $ istioctl install 此命令在 Kubernetes 集群上安装 default 配置档。 default 配置档是建立生产环境的一个良好起点, 这和较大的 demo 配置档不同,后者常用于评估一组广泛的 Istio 特性。 可以配置各种设置来修改安装。比如,要启动访问日志: $ istioctl install --set meshConfig.accessLogFile=/dev/stdout
资源推荐
资源详情
资源评论
收起资源包目录
istio-1.11.5 (257个子文件)
_istioctl 6KB
istioctl.bash 9KB
istioctl 87.84MB
package.json 158B
ratings_data.json 24B
LICENSE 11KB
Makefile 735B
Makefile 717B
README.md 7KB
README.md 6KB
README.md 5KB
README.md 4KB
README.md 3KB
README.md 3KB
README-helm3.md 3KB
UPDATING-CHARTS.md 3KB
install-OpenShift.md 2KB
README.md 2KB
README.md 2KB
README.md 2KB
README.md 2KB
README.md 2KB
README.md 1KB
README.md 1KB
README.md 1KB
README.md 1KB
README.md 137B
README.md 98B
common.mk 4KB
Makefile.k8s.mk 4KB
Makefile.selfsigned.mk 3KB
cert-chain-alt.pem 4KB
ca-key-alt.pem 3KB
workload-foo-cert.pem 2KB
workload-bar-cert.pem 2KB
ca-cert-alt.pem 2KB
root-cert-alt.pem 2KB
ca-key.pem 2KB
workload-foo-key.pem 2KB
workload-bar-key.pem 2KB
root-cert.pem 1KB
ca-cert.pem 1KB
cert-chain.pem 1KB
build_push_update_images.sh 4KB
build-services.sh 4KB
gen-eastwest-gateway.sh 3KB
generate-workload.sh 3KB
gen-helloworld.sh 2KB
cleanup.sh 2KB
build_service.sh 864B
script.sh 692B
loadgen.sh 675B
_affinity.tpl 3KB
_affinity.tpl 3KB
NOTES.txt 2KB
NOTES.txt 2KB
requirements.txt 521B
NOTES.txt 355B
NOTES.txt 267B
NOTES.txt 90B
requirements.txt 70B
test-requirements.txt 21B
gen-istio-cluster.yaml 257KB
crd-all.gen.yaml 247KB
crd-all.gen.yaml 247KB
grafana.yaml 240KB
gen-istio.yaml 109KB
telemetryv2_1.9.yaml 30KB
telemetryv2_1.10.yaml 29KB
telemetryv2_1.11.yaml 29KB
injection-template.yaml 21KB
injection-template.yaml 21KB
values.yaml 21KB
values.yaml 20KB
prometheus_vm_tls.yaml 15KB
prometheus_vm.yaml 14KB
prometheus.yaml 13KB
values.yaml 13KB
values.yaml 12KB
deployment.yaml 11KB
deployment.yaml 11KB
kiali.yaml 11KB
grpc-agent.yaml 9KB
bookinfo.yaml 8KB
gateway-injection-template.yaml 7KB
gateway-injection-template.yaml 7KB
deployment.yaml 7KB
daemonset.yaml 6KB
swagger.yaml 6KB
clusterrole.yaml 6KB
injected-deployment.yaml 5KB
injected-deployment.yaml 5KB
default.yaml 5KB
grpc-echo.yaml 5KB
configmap.yaml 5KB
configmap.yaml 5KB
mutatingwebhook.yaml 5KB
mutatingwebhook.yaml 5KB
gen-operator.yaml 4KB
clusterrole.yaml 4KB
共 257 条
- 1
- 2
- 3
资源评论
程序员是只喵
- 粉丝: 99
- 资源: 5
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 计算机毕业设计:python+爬虫+cnki网站爬
- nyakumi-lewd-snack-3-4k_720p.7z.002
- 现在微信小程序能用的mqtt.min.js
- 基于MPC的非线性摆锤系统轨迹跟踪控制matlab仿真,包括程序中文注释,仿真操作步骤
- shell脚本入门-变量、字符串, Shell脚本中变量与字符串的基础操作教程
- 基于MATLAB的ITS信道模型数值模拟仿真,包括程序中文注释,仿真操作步骤
- 基于Java、JavaScript、CSS的电子产品商城设计与实现源码
- 基于Vue 2的zjc项目设计源码,适用于赶项目需求
- 基于跨语言统一的C++头文件设计源码开发方案
- 基于MindSpore 1.3的T-GCNTemporal Graph Convolutional Network设计源码
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功