一.模块概览

在安装 Istio 模块中,我们将介绍在 Kubernetes 集群上安装 Istio1.14 的不同方法。我们将通过详细的步骤,了解如何在 Kubernetes 集群上安装 Istio。

关于istio简介可以查看博客《Istio(一):服务网格和 Istio 概述》https://www.cnblogs.com/renshengdezheli/p/16836205.html

二.系统环境

服务器版本 docker软件版本 Kubernetes(k8s)集群版本 Istio软件版本 CPU架构
CentOS Linux release 7.4.1708 (Core) Docker version 20.10.12 v1.21.9 Istio1.14 x86_64

Kubernetes集群架构:k8scloude1作为master节点,k8scloude2,k8scloude3作为worker节点

服务器 操作系统版本 CPU架构 进程 功能描述
k8scloude1/192.168.110.130 CentOS Linux release 7.4.1708 (Core) x86_64 docker,kube-apiserver,etcd,kube-scheduler,kube-controller-manager,kubelet,kube-proxy,coredns,calico k8s master节点
k8scloude2/192.168.110.129 CentOS Linux release 7.4.1708 (Core) x86_64 docker,kubelet,kube-proxy,calico k8s worker节点
k8scloude3/192.168.110.128 CentOS Linux release 7.4.1708 (Core) x86_64 docker,kubelet,kube-proxy,calico k8s worker节点

三.安装istio

我们有两种方法可以在单个 Kubernetes 集群上安装 Istio:使用 Istioctl(istioctl)或使用 Istio Operator。在本模块中,我们将使用 Istio Operator 在一个 Kubernetes 集群上安装 Istio。

3.1 使用 Istioctl 安装

Istioctl 是一个命令行工具,我们可以用它来安装和定制 Istio 的安装。使用该命令行工具,我们生成一个包含所有 Istio 资源的 YAML 文件,然后将其部署到 Kubernetes 集群上。

3.2 使用 Istio Operator 安装

与 istioctl 相比,Istio Operator 安装的优势在于,我们不需要手动升级 Istio。相反,我们可以部署 Istio Operator,为你管理安装。我们通过更新一个自定义资源来控制 Operator,而 Operator 则为你应用配置变化。

3.3 生产部署情况如何?

在决定 Istio 的生产部署模式时,还有一些额外的考虑因素需要牢记。我们可以配置 Istio 在不同的部署模型中运行 —— 可能跨越多个集群和网络,并使用多个控制平面。我们将在高级功能模块中了解其他部署模式、多集群安装以及在虚拟机上运行工作负载。

3.4 平台安装指南

Istio 可以安装在不同的 Kubernetes 平台上。关于特定云供应商的最新安装指南,请参考平台安装文档

https://istio.io/latest/docs/setup/platform-setup/

四.GetMesh

Istio 是最受欢迎和发展最快的开源项目之一。它的发布时间表对企业的生命周期和变更管理实践来说可能非常激进。GetMesh 通过针对不同的 Kubernetes 分发版测试所有 Istio 版本以确保功能的完整性来解决这一问题。GetMesh 的 Istio 版本在安全补丁和其他错误更新方面得到积极的支持,并拥有比上游 Istio 提供的更长的支持期。

一些服务网格客户需要支持更高的安全要求。GetMesh 通过提供两种 Istio 发行版来解决合规性问题。

  • tetrate 发行版,跟踪上游 Istio 并可能应用额外的补丁。
  • tetratefips 发行版,是符合 FIPS 标准的 tetrate 版本。

4.1 如何开始使用?

第一步是下载 GetMesh CLI。你可以在 macOS 和 Linux 平台上安装 GetMesh。我们可以使用以下命令来下载最新版本的 GetMesh 和认证的 Istio。

4.2 如何开始?

第一步是下载 GetMesh CLI。你可以在 macOS 和 Linux 平台上安装 GetMesh。我们可以使用以下命令下载最新版本的 GetMesh 并认证 Istio。

#安装getmesh
[root@k8scloude1 ~]# curl -sL https://istio.tetratelabs.io/getmesh/install.sh | bash
tetratelabs/getmesh info checking GitHub for latest tag
tetratelabs/getmesh info found version: 1.1.4 for v1.1.4/linux/amd64
tetratelabs/getmesh info installed /root/.getmesh/bin/getmesh
tetratelabs/getmesh info updating user profile (/root/.bash_profile)...
tetratelabs/getmesh info the following two lines are added into your profile (/root/.bash_profile): export GETMESH_HOME="$HOME/.getmesh"
export PATH="$GETMESH_HOME/bin:$PATH" Finished installation. Open a new terminal to start using getmesh!

修改配置文件使所有人都可以使用getmesh命令

[root@k8scloude1 ~]# cd .getmesh/

[root@k8scloude1 .getmesh]# pwd
/root/.getmesh [root@k8scloude1 .getmesh]# vim /etc/profile.d/getmesh.sh [root@k8scloude1 .getmesh]# cat /etc/profile.d/getmesh.sh
export GETMESH_HOME="/root/.getmesh"
export PATH="$GETMESH_HOME/bin:$PATH" #使配置文件生效
[root@k8scloude1 .getmesh]# source /etc/profile.d/getmesh.sh

我们可以运行 version 命令以确保 GetMesh 被成功安装。例如:

[root@k8scloude1 .getmesh]# getmesh version
getmesh version: 1.1.4
active istioctl: 1.14.4-tetrate-v0
client version: 1.14.4-tetrate-v0
control plane version: 1.14.3
data plane version: 1.14.3 (2 proxies)

版本命令输出 GetMesh 的版本、活跃的 Istio CLI 的版本以及 Kubernetes 集群上安装的 Istio 的版本。

4.3 使用 GetMesh 安装 Istio

GetMesh 通过 Kubernetes 配置文件与活跃的 Kubernetes 集群进行通信。

要在当前活跃的 Kubernetes 集群上安装 Istio 的演示配置文件,我们可以像这样使用 getmesh istioctl 命令:

[root@k8scloude1 .getmesh]# getmesh istioctl install --set profile=demo

该命令将检查集群,以确保它准备好安装 Istio,一旦你确认,安装程序将继续使用选定的配置文件安装 Istio。

如果我们现在检查版本,你会注意到输出显示控制平面和数据平面的版本。

4.4 验证配置

config-validate 命令允许你对当前配置和任何尚未应用的 YAML 清单进行验证。

该命令使用外部资源调用一系列验证,如上游 Istio 验证、Kiali 库和 GetMesh 自定义配置检查。

下面是一个命令输出的例子,default命名空间没有标记为 Istio 注入。

The namespace is not enabled for Istio injection. Run 'kubectl label namespace default istio-injection=enabled' to enable it, or 'kubectl label namespace default istio-injection=disabled' to explicitly mark it as not needing injection.这段信息告诉我们:命名空间没有启用Istio注入,可以运行”kubectl label namespace default istio-injection=enabled“命令启用Istio injection,或者运行'kubectl label namespace default istio-injection=disabled'命令显式地将其标记为不需要注入。

[root@k8scloude1 ~]# getmesh config-validate
Running the config validator. This may take some time... 2021-08-02T19:20:33.873244Z info klog Throttling request took 1.196458809s, request: GET:https://35.185.226.9/api/v1/namespaces/istio-system/configmaps/istio[]
NAMESPACE NAME RESOURCE TYPE ERROR CODE SEVERITY MESSAGE
default default Namespace IST0102 Info The namespace is not enabled for Istio injection. Run 'kubectl label namespace default istio-injection=enabled' to enable it, or 'kubectl label namespace default istio-injection=disabled' to explicitly mark it as not needing injection. The error codes of the found issues are prefixed by 'IST' or 'KIA'. For the detailed explanation, please refer to
- https://istio.io/latest/docs/reference/config/analysis/ for 'IST' error codes
- https://kiali.io/documentation/latest/validations/ for 'KIA' error codes

同样,你也可以传入一个 YAML 文件来验证它,然后再将它部署到集群。例如:

[root@k8scloude1 ~]# getmesh config-validate my-resources.yaml

4.5 管理多个 Istio CLI

我们可以使用 show 命令来列出当前下载的 Istio 版本:

[root@k8scloude1 ~]# getmesh show
1.14.4-tetrate-v0 (Active)

如果电脑上没有我们想使用的版本,可以使用 getmesh list 命令来列出所有可信的 Istio 版本:

[root@k8scloude1 ~]# getmesh list
ISTIO VERSION FLAVOR FLAVOR VERSION K8S VERSIONS
*1.9.5 tetrate 0 1.17,1.18,1.19,1.20
1.9.5 istio 0 1.17,1.18,1.19,1.20
1.9.4 tetrate 0 1.17,1.18,1.19,1.20
1.9.4 istio 0 1.17,1.18,1.19,1.20
1.9.0 tetrate 0 1.17,1.18,1.19,1.20
1.9.0 tetratefips 1 1.17,1.18,1.19,1.20
1.9.0 istio 0 1.17,1.18,1.19,1.20
1.8.6 tetrate 0 1.16,1.17,1.18,1.19
1.8.6 istio 0 1.16,1.17,1.18,1.19
1.8.5 tetrate 0 1.16,1.17,1.18,1.19
1.8.5 istio 0 1.16,1.17,1.18,1.19
1.8.3 tetrate 0 1.16,1.17,1.18,1.19
1.8.3 tetratefips 1 1.16,1.17,1.18,1.19
1.8.3 istio 0 1.16,1.17,1.18,1.19
1.7.8 tetrate 0 1.16,1.17,1.18
1.7.8 istio 0 1.16,1.17,1.18

要获取一个特定的版本(比方说1.9.0 tetratefips),我们可以使用 fetch 命令:

[root@k8scloude1 ~]# getmesh fetch --version 1.9.0 --flavor tetratefips  --flavor-version 1

当上述命令完成后,GetMesh 将获取的 Istio CLI 版本设置为活跃版本。例如,运行 show 命令现在显示 tetratefips 1.9.0 版本是活跃的:

[root@k8scloude1 ~]# getmesh show
1.9.0-tetratefips-v1 (Active)
1.9.5-tetrate-v0

同样,如果我们运行 getmesh istioctl version ,我们会发现正在使用的 Istio CLI 的版本:

[root@k8scloude1 ~]# getmesh istioctl version
client version: 1.9.0-tetratefips-v1
control plane version: 1.9.5-tetrate-v0
data plane version: 1.9.5-tetrate-v0 (2 proxies)

要切换到不同版本的 Istio CLI,我们可以运行 getmesh switch 命令:

[root@k8scloude1 ~]# getmesh  switch --version 1.9.5 --flavor tetrate --flavor-version 0

4.6 CA 集成

我们没有使用自签的根证书,而是从 GCP CAS(证书授权服务)获得一个中间的 Istio 证书授权(CA)来签署工作负载证书。

假设你已经配置了自己的 CAS 实例, 可以用 CA 的参数创建一个 YAML 配置。下面是 YAML 配置的一个例子:

 providerName: "gcp"
providerConfig:
gcp:
# 你在 GCP 上创建的证书授权的完整 CA 名称
casCAName: "projects/tetrate-io-istio/locations/us-west1/certificateAuthorities/tetrate-example-io" certificateParameters:
secretOptions:
istioCANamespace: "istio-system" # cacerts secret 所在的命名空间
overrideExistingCACertsSecret: true # 重写已存在的 cacerts secret,使用新的替换
caOptions:
validityDays: 365 # CA 到期前的有效天数
keyLength: 2048 # 创建的 key 的比特数
certSigningRequestParams: # x509.CertificateRequest;大部分字段省略
subject:
commonname: "tetrate.example.io"
country:
- "US"
locality:
- "Sunnyvale"
organization:
- "Istio"
organizationunit:
- "engineering"
emailaddresses:
- "youremail@example.io"

配置完成后,你可以使用 gen-ca 命令来创建 cacert

[root@k8scloude1 ~]# getmesh gen-ca --config-file gcp-cas-config.yaml

该命令在 istio-system 中创建 cacerts Kubernetes Secret。为了让 istiod 接受新的 cert,你必须重新启动 istiod。

如果你创建一个 sample 工作负载,并检查所使用的证书,你会发现是 CA 为工作负载发布的证书。

Istio CA certs 集成可用于 GCP CA 服务AWS Private CA 服务

五.发现选择器(Discovery Selectors)

发现选择器是 Istio 1.10 中引入的新功能之一。发现选择器允许我们控制 Istio 控制平面观察和发送配置更新的命名空间

默认情况下,Istio 控制平面会观察和处理集群中所有 Kubernetes 资源的更新。服务网格中的所有 Envoy代理的配置方式是,它们可以到达服务网格中的每个工作负载,并接受与工作负载相关的所有端口的流量。

例如,我们在不同的命名空间部署了两个工作负载——foo 和 bar。尽管我们知道 foo 永远不会与 bar 通信,反之亦然,但一个服务的端点将被包含在另一个服务的已发现端点列表中。

如果我们运行 istioctl proxy-config 命令,列出 foo 命名空间的 foo 工作负载可以看到的所有端点,你会注意到一个名为 bar 的服务条目:

[root@k8scloude1 ~]# istioctl proxy-config endpoints deploy/foo.foo
ENDPOINT STATUS OUTLIER CHECK CLUSTER

10.4.1.4:31400 HEALTHY OK outbound|31400||istio-ingressgateway.istio-system.svc.cluster.local
10.4.1.5:80 HEALTHY OK outbound|80||foo.foo.svc.cluster.local
10.4.2.2:53 HEALTHY OK outbound|53||kube-dns.kube-system.svc.cluster.local
10.4.4.2:8383 HEALTHY OK outbound|8383||istio-operator.istio-operator.svc.cluster.local
10.4.4.3:8080 HEALTHY OK outbound|80||istio-egressgateway.istio-system.svc.cluster.local
10.4.4.3:8443 HEALTHY OK outbound|443||istio-egressgateway.istio-system.svc.cluster.local
10.4.4.4:80 HEALTHY OK outbound|80||bar.bar.svc.cluster.local
...

如果 Istio 不断用集群中每个服务的信息来更新代理,即使这些服务是不相关的,我们可以想象这将如何拖累事情。

如果这听起来很熟悉,你可能知道已经有一个解决方案了——Sidecar 资源。

我们将在后面的模块中讨论 Sidecar 资源。

5.1 配置发现选择器

发现选择器可以在 MeshConfig 中的 Mesh 层面上进行配置。它们是一个 Kubernetes 选择器的列表,指定了 Istio 在向 sidecar 推送配置时观察和更新的命名空间的集合。

就像 Sidecar 资源一样,discoverySelectors 可以用来限制被 Istio 观察和处理的项目数量

我们可以更新 IstioOperator 以包括 discoverySelectors 字段,如下所示:

 apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istio-demo
spec:
meshConfig:
discoverySelectors:
- matchLabels:
env: test

上面的例子将 env=test 设置为一个匹配标签。这意味着标有 env=test 标签的命名空间中的工作负载将被包含在 Istio 监控和更新的命名空间列表中。

如果我们给 foo 命名空间贴上 env=test 标签,然后列出端点,我们会发现现在配置中列出的端点没有那么多。这是因为我们标注的唯一命名空间是 foo 命名空间,这也是 Istio 控制平面观察和发送更新的唯一命名空间。

[root@k8scloude1 ~]# istioctl proxy-config endpoints deploy/foo.foo
ENDPOINT STATUS OUTLIER CHECK CLUSTER
10.4.1.5:80 HEALTHY OK outbound|80||foo.foo.svc.cluster.local
127.0.0.1:15000 HEALTHY OK prometheus_stats
127.0.0.1:15020 HEALTHY OK agent
unix://./etc/istio/proxy/SDS HEALTHY OK sds-grpc
unix://./etc/istio/proxy/XDS HEALTHY OK xds-grpc

如果我们把命名空间 bar 也贴上标签,然后重新运行 istioctl proxy-config 命令,我们会发现 bar 端点显示为 foo 服务配置的一部分。

[root@k8scloude1 ~]# istioctl proxy-config endpoints deploy/foo.foo
ENDPOINT STATUS OUTLIER CHECK CLUSTER
10.4.1.5:80 HEALTHY OK outbound|80||foo.foo.svc.cluster.local
10.4.4.4:80 HEALTHY OK outbound|80||bar.bar.svc.cluster.local
127.0.0.1:15000 HEALTHY OK prometheus_stats
127.0.0.1:15020 HEALTHY OK agent
unix://./etc/istio/proxy/SDS HEALTHY OK sds-grpc
unix://./etc/istio/proxy/XDS HEALTHY OK xds-grpc

六.实战(k8s集群安装Istio 1.14版本)

要安装 Istio,我们需要一个运行中的 Kubernetes 集群实例。所有的云供应商都提供托管的 Kubernetes 集群,我们可以用它来安装 Istio 服务网格。

我们也可以在自己的电脑上使用以下任意平台在本地运行 Kubernetes集群:

当使用本地 Kubernetes 集群时,确保你的电脑满足 Istio 安装的最低要求(如 16384MB 内存和 4 个 CPU)。另外,确保 Kubernetes 集群的版本大于等于 v1.19.0。

6.1 Kubernetes 集群(1.21.9版本)

安装istio的前提是已经有一套可以正常运行的Kubernetes集群,关于Kubernetes(k8s)集群的安装部署,可以查看博客《Centos7 安装部署Kubernetes(k8s)集群》https://www.cnblogs.com/renshengdezheli/p/16686769.html

Kubernetes集群版本为1.21.9

[root@k8scloude1 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8scloude1 Ready control-plane,master 255d v1.21.9
k8scloude2 Ready <none> 255d v1.21.9
k8scloude3 Ready <none> 255d v1.21.9

Kubernetes CLI是kubectl工具,我们可以运行 kubectl version 来查看kubectl的版本

[root@k8scloude1 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:51:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:45:53Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}

6.2 Istio 版本支持状态

Istio最新版本为1.15,因为我们Kubernetes集群版本为1.21.9,所以我们选择安装Istio 1.14版本。

版本 目前支持 发行日期 停止维护 支持的 Kubernetes 版本 未测试,可能支持的 Kubernetes 版本
master 否,仅限开发 - - - -
1.15 2022 年 8 月 31 日 ~ 2023 年 3 月(预期) 1.22, 1.23, 1.24, 1.25 1.16, 1.17, 1.18, 1.19, 1.20, 1.21
1.14 2022 年 5 月 24 日 ~ 2023 年 1 月(预期) 1.21, 1.22, 1.23, 1.24 1.16, 1.17, 1.18, 1.19, 1.20
1.13 2022 年 2 月 11 日 ~ 2022 年 10 月(预期) 1.20, 1.21, 1.22, 1.23 1.16, 1.17, 1.18, 1.19
1.12 2021 年 11 月 18 日 2022 年 7 月 12 日 1.19, 1.20, 1.21, 1.22 1.16, 1.17, 1.18
1.11 2021 年 8 月 12 日 2022 年 3 月 25 日 1.18, 1.19, 1.20, 1.21, 1.22 1.16, 1.17
1.10 2021 年 5 月 18 日 2022 年 1 月 7 日 1.18, 1.19, 1.20, 1.21 1.16, 1.17, 1.22
1.9 2021 年 2 月 9 日 2021 年 10 月 8 日 1.17, 1.18, 1.19, 1.20 1.15, 1.16
1.8 2020 年 11 月 10 日 2021 年 5 月 12 日 1.16, 1.17, 1.18, 1.19 1.15
1.7 2020 年 8 月 21 日 2021 年 2 月 25 日 1.16, 1.17, 1.18 1.15
1.6 及更早 - - - -

Kubernetes 1.22 删除了一些已弃用的 API,因此 1.10.0 之前的 Istio 版本将不再工作。如果您正在升级 Kubernetes 版本,请确保 Istio 的版本仍然受到支持。

istio各个版本的归档可以查看:https://istio.io/archive/

6.3 下载 Istio

在本实验中,我们将使用 Istio 1.14版本。安装 Istio 的第一步是下载 Istio CLI(istioctl)、安装清单、示例和工具。

安装最新版本的最简单方法是使用 downloadIstio 脚本。打开一个终端窗口,打开你要下载 Istio 的文件夹,然后运行下载脚本。

下载istio最新版本命令为:

[root@k8scloude1 ~]# curl -L https://istio.io/downloadIstio | sh -

您可以在命令行上传递变量以下载特定版本或覆盖处理器架构。例如,要下载 x86_64 架构的 Istio 1.14.3,请运行:

[root@k8scloude1 ~]# curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.14.3 TARGET_ARCH=x86_64 sh -

或者直接去https://github.com/istio/istio/releases/download/1.14.3/istio-1.14.3-linux-amd64.tar.gz下载安装包,下载安装包之后解压,istio-1.14.3/bin目录下可以看到istioctl,istio-1.14.3/samples目录下是示例应用程序。

[root@k8scloude1 ~]# ll -h istio-1.14.3-linux-amd64.tar.gz
-rw-r--r-- 1 root root 23M 9月 22 11:34 istio-1.14.3-linux-amd64.tar.gz [root@k8scloude1 ~]# tar xf istio-1.14.3-linux-amd64.tar.gz [root@k8scloude1 ~]# ls
istio-1.14.3-linux-amd64.tar.gz istio-1.14.3 [root@k8scloude1 ~]# cd istio-1.14.3/ [root@k8scloude1 istio-1.14.3]# ls
bin LICENSE manifests manifest.yaml README.md samples tools [root@k8scloude1 istio-1.14.3]# ls bin/
istioctl

为了访问 istioctl,我们应该把它添加到 path 中。

[root@k8scloude1 bin]# pwd
/root/istio-1.14.3/bin [root@k8scloude1 bin]# ls
istioctl #临时生效
[root@k8scloude1 bin]# export PATH=/root/istio-1.14.3/bin:$PATH #永久生效
[root@k8scloude1 bin]# vim /etc/profile.d/istioctl.sh [root@k8scloude1 bin]# cat /etc/profile.d/istioctl.sh
export ISTIOCTL_HOME="/root/istio-1.14.3"
export PATH="$ISTIOCTL_HOME/bin:$PATH" [root@k8scloude1 bin]# source /etc/profile.d/istioctl.sh

要检查 istioctl 是否在 path 里,运行 istioctl version。你应该看到这样的输出。

[root@k8scloude1 bin]# istioctl version
no running Istio pods in "istio-system"
1.14.3

6.4 安装 Istio

Istio 支持多个配置文件(profile)。配置文件之间的区别在于所安装的组件。

[root@k8scloude1 bin]# istioctl profile list
Istio configuration profiles:
default
demo
empty
external
minimal
openshift
preview
remote

这些配置文件提供了对 Istio 控制平面和 Istio 数据平面 Sidecar 的定制内容。

您可以从 Istio 内置配置文件的其中一个开始入手,然后根据您的特定需求进一步自定义配置文件。当前提供以下几种内置配置文件:

  1. default:根据 IstioOperator API 的默认设置启动组件。 建议用于生产部署和 Multicluster Mesh 中的 Primary Cluster。

    您可以运行 istioctl profile dump 命令来查看默认设置。

  2. demo:这一配置具有适度的资源需求,旨在展示 Istio 的功能。 它适合运行 Bookinfo 应用程序和相关任务。 这是通过快速开始指导安装的配置。此配置文件启用了高级别的追踪和访问日志,因此不适合进行性能测试。

  3. minimal:与默认配置文件相同,但只安装了控制平面组件。 它允许您使用 Separate Profile 配置控制平面和数据平面组件(例如 Gateway)。

  4. remote:配置 Multicluster Mesh 的 Remote Cluster。

  5. empty:不部署任何东西。可以作为自定义配置的基本配置文件。

  6. preview:预览文件包含的功能都是实验性。这是为了探索 Istio 的新功能。不确保稳定性、安全性和性能(使用风险需自负)。

标注 的组件安装在每个配置文件中:

default demo minimal remote empty preview
核心组件
istio-egressgateway
istio-ingressgateway
istiod

推荐用于生产部署的配置文件是 default 配置文件

我们将安装 demo 配置文件,因为它包含所有的核心组件,启用了跟踪和日志记录,便于学习不同的 Istio 功能。

我们也可以从 minimal 的组件开始,以后单独安装其他功能,如 ingress 和 egress 网关。

因为我们将使用 Istio Operator 进行安装,所以我们必须先部署 Operator。关于Istio Operator 简介可以查看https://istio.io/v1.14/zh/blog/2019/introducing-istio-operator/

要部署 Istio Operator,请运行:

[root@k8scloude1 bin]# istioctl operator init
Installing operator controller in namespace: istio-operator using image: docker.io/istio/operator:1.14.3
Operator controller will watch namespaces: istio-system
Istio operator installed
Installation complete

init 命令创建了 istio-operator 命名空间,并部署了 CRD、Operator Deployment 以及 operator 工作所需的其他资源。安装完成后,Operator 就可以使用了。

要安装 Istio,我们必须创建 IstioOperator 资源,并指定我们要使用的配置文件。

创建一个名为 istio-demo-profile.yaml的文件,内容如下:

#创建目录istioyaml,用来专门存放yaml文件
[root@k8scloude1 ~]# mkdir istioyaml [root@k8scloude1 ~]# cd istioyaml/ [root@k8scloude1 istioyaml]# vim istio-demo-profile.yaml #profile: demo表示使用demo配置文件安装istio
[root@k8scloude1 istioyaml]# cat istio-demo-profile.yaml
apiVersion: v1
kind: Namespace
metadata:
name: istio-system
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: demo-istio-install
spec:
profile: demo

我们还在文件中添加了命名空间资源,以创建 istio-system 命名空间。

我们需要做的最后一件事是创建资源:

[root@k8scloude1 istioyaml]# kubectl apply -f istio-demo-profile.yaml
Warning: resource namespaces/istio-system is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
namespace/istio-system configured
istiooperator.install.istio.io/demo-istio-install created #可以查看istio-system命名空间下的所有资源
[root@k8scloude1 istioyaml]# kubectl get all -o wide -n istio-system
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/istio-egressgateway-58949b7c84-k7v6f 1/1 Running 0 3m38s 10.244.112.173 k8scloude2 <none> <none>
pod/istio-ingressgateway-75bc568988-9j4wv 1/1 Running 0 3m38s 10.244.251.238 k8scloude3 <none> <none>
pod/istiod-84d979766b-kz5sd 1/1 Running 0 4m20s 10.244.112.130 k8scloude2 <none> <none> NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/istio-egressgateway ClusterIP 10.102.56.241 <none> 80/TCP,443/TCP 3m35s app=istio-egressgateway,istio=egressgateway
service/istio-ingressgateway LoadBalancer 10.107.131.65 192.168.110.190 15021:30093/TCP,80:32126/TCP,443:30293/TCP,31400:30628/TCP,15443:30966/TCP 3m35s app=istio-ingressgateway,istio=ingressgateway
service/istiod ClusterIP 10.103.37.59 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 4m21s app=istiod,istio=pilot NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/istio-egressgateway 1/1 1 1 3m39s istio-proxy docker.io/istio/proxyv2:1.14.3 app=istio-egressgateway,istio=egressgateway
deployment.apps/istio-ingressgateway 1/1 1 1 3m39s istio-proxy docker.io/istio/proxyv2:1.14.3 app=istio-ingressgateway,istio=ingressgateway
deployment.apps/istiod 1/1 1 1 4m21s discovery docker.io/istio/pilot:1.14.3 istio=pilot NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
replicaset.apps/istio-egressgateway-58949b7c84 1 1 1 3m39s istio-proxy docker.io/istio/proxyv2:1.14.3 app=istio-egressgateway,istio=egressgateway,pod-template-hash=58949b7c84
replicaset.apps/istio-ingressgateway-75bc568988 1 1 1 3m39s istio-proxy docker.io/istio/proxyv2:1.14.3 app=istio-ingressgateway,istio=ingressgateway,pod-template-hash=75bc568988
replicaset.apps/istiod-84d979766b 1 1 1 4m21s discovery docker.io/istio/pilot:1.14.3 istio=pilot,pod-template-hash=84d979766b

一旦 Operator 检测到 IstioOperator 资源,它将开始安装 Istio。整个过程可能需要5分钟左右。

为了检查安装的状态,我们可以看看 istio-system 命名空间中的 Pod 的状态。

[root@k8scloude1 istioyaml]# kubectl get pod -o wide -n istio-system
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
istio-egressgateway-58949b7c84-k7v6f 1/1 Running 0 9m20s 10.244.112.173 k8scloude2 <none> <none>
istio-ingressgateway-75bc568988-9j4wv 1/1 Running 0 9m20s 10.244.251.238 k8scloude3 <none> <none>
istiod-84d979766b-kz5sd 1/1 Running 0 10m 10.244.112.130 k8scloude2 <none> <none>

当所有的 Pod 都在运行时,Operator 已经完成了 Istio 的安装。

6.5 启用 sidecar 注入

服务网格需要让每个应用程序同时运行 sidecar 代理。

要将 sidecar 代理注入到现有的 Kubernetes 部署中,我们可以使用 istioctl 命令中的 kube-inject 动作。

然而,我们也可以在任意 Kubernetes 命名空间上启用 sidecar 自动注入。如果我们用 istio-injection=enabled 标记命名空间,Istio 会自动为我们在该命名空间中创建的所有 Kubernetes Pod 注入 sidecar。

让我们通过添加标签来启用 microservice 命名空间的 sidecar 自动注入。

#创建命名空间
[root@k8scloude1 istioyaml]# kubectl create ns microservice
namespace/microservice created [root@k8scloude1 istioyaml]# kubectl label namespace microservice istio-injection=enabled
namespace/microservice labeled

要检查命名空间是否被标记,请运行下面的命令。microservice 命名空间应该是唯一一个启用了该值的命名空间。

[root@k8scloude1 istioyaml]# kubectl get namespace -L istio-injection
NAME STATUS AGE ISTIO-INJECTION
app-team1 Active 163d
microservice Active 3m39s enabled
my-app Active 162d
network Active 219d
ns1 Active 256d #或者这样查询
[root@k8scloude1 istioyaml]# kubectl get namespace -l istio-injection=enabled
NAME STATUS AGE
microservice Active 6m56s

现在我们可以尝试在 microservice 命名空间创建一个 Deployment,并观察注入的代理。我们将创建一个名为 mynginx 的 Deployment,使用hub.c.163.com/library/nginx:latest镜像的单一容器。

 [root@k8scloude1 istioyaml]# kubectl create deployment mynginx --image=hub.c.163.com/library/nginx:latest -n microservice
deployment.apps/mynginx created

如果我们看一下 Pod,你会发现 Pod 里有两个容器。

[root@k8scloude1 istioyaml]# kubectl get deployment -n microservice
NAME READY UP-TO-DATE AVAILABLE AGE
mynginx 1/1 1 1 27s [root@k8scloude1 istioyaml]# kubectl get pod -n microservice
NAME READY STATUS RESTARTS AGE
mynginx-5cb948ffc5-wv29l 2/2 Running 0 35s

同样地,描述 Pod 时会显示 Kubernetes 同时创建了一个 nginx 容器和一个 istio-proxy 容器:

[root@k8scloude1 istioyaml]# kubectl describe pod mynginx-5cb948ffc5-wv29l -n microservice
Name: mynginx-5cb948ffc5-wv29l
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 12m default-scheduler Successfully assigned microservice/mynginx-5cb948ffc5-wv29l to k8scloude2
Normal Pulled 12m kubelet Container image "docker.io/istio/proxyv2:1.14.3" already present on machine
Normal Created 12m kubelet Created container istio-init
Normal Started 12m kubelet Started container istio-init
Normal Pulling 12m kubelet Pulling image "hub.c.163.com/library/nginx:latest"
Normal Pulled 12m kubelet Successfully pulled image "hub.c.163.com/library/nginx:latest" in 2.24360029s
Normal Created 12m kubelet Created container nginx
Normal Started 12m kubelet Started container nginx
Normal Pulled 12m kubelet Container image "docker.io/istio/proxyv2:1.14.3" already present on machine
Normal Created 12m kubelet Created container istio-proxy
Normal Started 12m kubelet Started container istio-proxy

运行下面的命令,删除deployment:

[root@k8scloude1 istioyaml]# kubectl delete deployment mynginx -n microservice
deployment.apps "mynginx" deleted [root@k8scloude1 istioyaml]# kubectl get deployment -n microservice
No resources found in microservice namespace. [root@k8scloude1 istioyaml]# kubectl get pod -n microservice
No resources found in microservice namespace.

6.6 更新和卸载 Istio

如果我们想更新当前的安装或改变配置文件,那么需要更新先前部署的 IstioOperator 资源。

要删除安装,我们必须删除 IstioOperator,例如:

[root@k8scloude1 istioyaml]# kubectl get istiooperator -n istio-system
NAME REVISION STATUS AGE
demo-istio-install HEALTHY 45m [root@k8scloude1 istioyaml]# kubectl delete istiooperator demo-istio-install -n istio-system

在 Operator 删除了Istio 后,运行下面的命令来删除 Operator:

[root@k8scloude1 istioyaml]# istioctl operator remove

请确保在删除 Operator 之前先删除 IstioOperator 资源。否则,可能会有剩余的 Istio 资源。

Istio(二):在Kubernetes(k8s)集群上安装部署istio1.14的更多相关文章

  1. 超详细实操教程!在现有K8S集群上安装JenkinsX,极速提升CI/CD体验!

    在2018年年初,Jenkins X首次发布,它由Apache Groovy语言的创建者Jame Strachan创建.Jenkins X 是一个高度集成化的 CI/CD 平台,基于 Jenkins ...

  2. 使用kubectl管理Kubernetes(k8s)集群:常用命令,查看负载,命名空间namespace管理

    目录 一.系统环境 二.前言 三.kubectl 3.1 kubectl语法 3.2 kubectl格式化输出 四.kubectl常用命令 五.查看kubernetes集群node节点和pod负载 5 ...

  3. Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列之自签TLS证书及Etcd集群部署(二)

    0.前言 整体架构目录:ASP.NET Core分布式项目实战-目录 k8s架构目录:Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录 一.服务器设置 1.把每一 ...

  4. Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列之集群部署环境规划(一)

    0.前言 整体架构目录:ASP.NET Core分布式项目实战-目录 k8s架构目录:Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录 一.环境规划 软件 版本 ...

  5. Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列之flanneld网络介绍及部署(三)

    0.前言 整体架构目录:ASP.NET Core分布式项目实战-目录 k8s架构目录:Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录 一.flanneld介绍 ...

  6. Centos7 安装部署Kubernetes(k8s)集群

    目录 一.系统环境 二.前言 三.Kubernetes 3.1 概述 3.2 Kubernetes 组件 3.2.1 控制平面组件 3.2.2 Node组件 四.安装部署Kubernetes集群 4. ...

  7. Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录

    0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 k8s架构目录:Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录 一.感谢 在此感谢.net ...

  8. Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列之部署master/node节点组件(四)

    0.前言 整体架构目录:ASP.NET Core分布式项目实战-目录 k8s架构目录:Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录 1.部署master组件 ...

  9. k8s第二回之k8s集群的安装

    1. k8s集群的安装 目录 1. k8s集群的安装 1.架构: 2.环境准备 3.master节点安装etcd 4. master节点安装kubernetes 5.node节点安装kubernete ...

随机推荐

  1. 一例智能网卡(mellanox)的网卡故障分析

    一例智能网卡(mellanox)的网卡故障分析 背景:这个是在centos 7.6.1810的环境上复现的,智能网卡是目前很多 云服务器上的网卡标配,在oppo主要用于vpc等场景,智能网卡的代码随着 ...

  2. 云服务器上搭建cobalt strike遇到的一些小问题

    一.前言: 当你兴高采烈的买了一台云服务器,迫不及待地想去搭建传说中的神器cobalt strike的时候,你可能会遇到以下的一些小问题,这里我会列出对应的解决方法. 二.遇到的一些小问题 1.上传文 ...

  3. Aoac唤醒的软件方案

    Aoac唤醒 这篇文章包含了Win10下的Aoac唤醒和Win11下的Aoac唤醒的不同地方,在结尾处: 从Win10时代开始,通过软件来唤醒机器是一个很常见的事情了,但是很少有文档去将如何通过AOA ...

  4. C#基础_理解类

    构造函数主要是用来创建对象时为对象赋初值来初始化对象.总与new运算符一起使用在创建对象的语句中 .A a=new A(); 构造函数具有和类一样的名称:但它是一个函数具有函数的所有特性,同一个类里面 ...

  5. 【java】IDEA-jar包导出与导入

    导出步骤: 1.CTRL + SHIFT + ALT + S 2.选择:Artifacts ,点击"+",在添加页面中选择:JAR-From modules with depend ...

  6. vue2和vue3的区别?

    vue2和vue3的主要区别在于以下几点: 1.生命周期函数钩子不同 2.数据双向绑定原理不同 3.定义变量和方法不同 4.指令和插槽的使用不同 5.API类型不同 6.是否支持碎片 7.父子组件之间 ...

  7. KingbaseES R6 单节点数据库异机恢复案例

    数据库运行硬件或系统环境如果发生了不可恢复的故障,这时只能采用异机恢复的方式恢复数据库.以下通过例子介绍异机恢复的过程. 一.硬件环境 192.168.237.101 数据库运行源主机 192.168 ...

  8. 微服务系列之网关(二) konga配置操作

    1.konga核心对象 Kong 的四大核心对象:upstream,target,service,route.下面分别说: (1)upstream,字面意思上游,实际项目理解是对某一个服务的一个或者多 ...

  9. FreeSql 导入数据的各种场景总结 [C#.NET ORM]

    前言 导入数据这种脏活.累活,相信大家多多少少都有经历,常见的场景有: 同服务器从A表导数据到B表 批量导入新数据 批量新增或更新数据 跨服务器从A表导数据到B表 每种场景有自己的特点,我们一般会根据 ...

  10. 合理编写C++模块(.h、.cc)

    模块划分 合理编写模块的 demo.h.demo.cc 下例为C++为后端服务编写的探活检测服务 health_server.h #ifndef HEALTH_SERVER_H #define HEA ...