当前位置: 代码迷 >> 综合 >> istio 三日谈之一,环境准备
  详细解决方案

istio 三日谈之一,环境准备

热度:62   发布时间:2023-09-27 19:49:59.0

笔者尝试在一个准生产环境下,利用 istio 来对运行在 Kubernetes 上的微服务进行管理。

这一篇是第一篇,将一些主要的坑和环境准备工作。

内容较多,因此无法写成手把手教程,希望读者有一定 Kubernetes 的操作基础。

准备镜像

初始运行需要的镜像包括以下几个:

  • istio/mixer:0.1.6
  • pilot:0.1.6
  • proxy_debug:0.1.6
  • istio-ca:0.1.6

首先要解决的自然还是镜像的存放问题,官方在源码中提供了很方便的工具,用来根据模板生成在 Kubernetes 中运行 istio 的 YAML 文件:

./updateVersion.sh \-p 10.211.55.86:5000/istio,0.1.6 \-c 10.211.55.86:5000/istio,0.1.6 \-x 10.211.55.86:5000/istio,0.1.6

这一脚本在源码的 install 目录下。

Kubernetes 环境

这里我们使用的集群大概情况是:

  • 1.7.1 版本的 Kubernetes
  • 开启了 RBAC
  • 预备使用的命名空间为:default
  • PVC 自动供给
  • 无互联网连接
  • 具有自己的私库

启动 istio

RBAC 相关

首先,install 目录中提供的 rbac 文件授权范围不足,所以需要手工编辑istio-rbac-beta.yaml,把其中的几个 RoleBinding,改为 ClusterRoleBinding。

kubectl create \-f istio-rbac-beta.yaml

另外缺省的 ClusterRole 中缺乏对 Namespace 的权限,新版本已经修正,目前版本仍需添加:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: istio-pilot
rules:
- apiGroups: ["istio.io"]resources: ["istioconfigs", "istioconfigs.istio.io"]verbs: ["*"]
- apiGroups: ["extensions"]resources: ["thirdpartyresources", "thirdpartyresources.extensions", "ingresses", "ingresses/status"]verbs: ["*"]
- apiGroups: [""]resources: ["configmaps", "endpoints", "pods", "services"]verbs: ["*"]
- apiGroups: [""]resources: ["namespaces", "nodes", "secrets"]verbs: ["get", "list", "watch"]

启动 istio 组件

kubectl create \-f istio.yaml \

创建 PVC

kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: frontend-v1
spec:accessModes:- ReadWriteOnceresources:requests:storage: 1Gi

准备工作负载

这里我们使用官方的 PHP + Apache 镜像作为工作负载来进行下面的测试,例如我们准备好的 YAML 如下:

Deployment:

kind: Deployment
apiVersion: extensions/v1beta1
metadata:name: frontendlabels:name: frontendversion: "1"
spec:replicas: 1template:metadata:labels:name: frontendversion: "1"spec:containers:- name: phpimage: 10.211.55.86:5000/php:7.1.7-apacheports:- containerPort: 80protocol: TCPvolumeMounts:- name: wwwrootmountPath: /var/www/htmlenv:- name: "SERVICE_VERSION"value: "1"      volumes:- name: wwwrootpersistentVolumeClaim:claimName: frontend-v1

服务定义:

kind: Service
apiVersion: v1
metadata:name: svc-frontendlabels:name: frontendversion: "1"
spec:type: NodePortports:- protocol: TCPport: 80targetPort: 80nodePort: 32010  selector:name: frontend

在 Web 目录中我们随便做了个index.php,用来展示当前所在 Pod 和环境变量中的服务版本号,备用。

Tips:一般这类测试,我都懒得重新做一个 Docker 镜像,一般是另外用一个 Pod 挂载同一个 PVC,直接编辑页面文件,或者使用kubectl cp命令进行拷贝。

index.php

<?php
header("Content-type: text/plain");
echo "From: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

delay.php

<?php
header("Content-type: text/plain");
sleep(4);
echo "\n-----------------------------\n";
echo "\nFrom: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

运行成功后,访问该服务的 nodePort,会看到相应的输出内容。

istio 的注入

首先用kubectl delete -f删除上文的服务和 Deployment。

上面为了测试方便,给 Service 使用了 NodePort 类型,这里我们去掉这一服务的 NodePort,用 ClusterIP 的形式运行:

spec:ports:- protocol: TCPport: 80targetPort: 80selector:name: frontend

接下来进行注入操作

istioctl kube-inject -f frontend-v1.yaml > frontend-v1-istio.yaml

观察注入操作会发现,其中多了一个 Sidecar Container(下面的 Image 节内容已经被我修改为本地私库):

    env:- name: POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: POD_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespace- name: POD_IPvalueFrom:fieldRef:fieldPath: status.podIPimage: 10.211.55.86:5000/istio/proxy_debug:0.1.6imagePullPolicy: Alwaysname: proxyresources: {}securityContext:runAsUser: 1337

另外还在pod.beta.kubernetes.io/init-containers注解中进行了初始化:

[{
   "args": ["-p", "15001", "-u", "1337"],"image": "10.211.55.86:5000/istio/init:0.1","imagePullPolicy": "Always","name": "init","securityContext": {
   "capabilities": {
   "add": ["NET_ADMIN"]}}
}, {
   "args": ["-c", "sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%t \u0026\u0026 ulimit -c unlimited"],"command": ["/bin/sh"],"image": "10.211.55.86:5000/alpine","imagePullPolicy": "Always","name": "enable-core-dump","securityContext": {
   "privileged": true}
}]

可以看到上面一共涉及三个镜像:

  • docker.io/istio/proxy_debug:0.1
  • docker.io/istio/init:0.1
  • alpine

经过一番折腾:

  1. 原有 YAML
  2. 注入,生成新的 YAML
  3. 替换新 YAML 中的镜像地址

就把原有的容器应用封装成新的 istio 支持的微服务了。

准备测试素材

另外我们需要准备一个工具服务,用于在 shell 中进行测试:

kind: Deployment
apiVersion: extensions/v1beta1
metadata:name: toollabels:name: toolversion: "1"
spec:replicas: 1template:metadata:labels:name: toolversion: "1"spec:containers:- name: toolimage: 10.211.55.86:5000/php:7.1.7-apacheports:- containerPort: 80protocol: TCPvolumeMounts:- name: wwwrootmountPath: /var/www/htmlvolumes:- name: wwwrootpersistentVolumeClaim:claimName: frontend-v1
---
kind: Service
apiVersion: v1
metadata:name: toollabels:name: tool
spec:ports:- protocol: TCPport: 80targetPort: 80selector:name: tool

同样的,这里也需要执行istioctl kube-inject进行注入,运行之后,就得到一个运行于集群内部的 Linux Shell,istio 中的路由策略经常是客户端和服务器协同完成的,因此上客户和服务器的 Deployment 都需要进行注入操作。

K8S中文文档  docs.kubernetes.org.cn