zoukankan      html  css  js  c++  java
  • 利用 istio 来对运行在 Kubernetes 上的微服务进行管理

    尝试在一个准生产环境下,利用 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:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

    准备工作负载

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

    Deployment

    kind: Deployment
    apiVersion: extensions/v1beta1
    metadata:
      name: frontend
      labels:
        name: frontend
        version: "1"
    spec:
      replicas: 1
      template:
        metadata:
          labels:
            name: frontend
            version: "1"
        spec:
          containers:
          - name: php
            image: 10.211.55.86:5000/php:7.1.7-apache
            ports:
            - containerPort: 80
              protocol: TCP
            volumeMounts:
            - name: wwwroot
              mountPath: /var/www/html
            env:
            - name: "SERVICE_VERSION"
              value: "1"      
            volumes:
          - name: wwwroot
            persistentVolumeClaim:
              claimName: frontend-v1

    服务定义:

    kind: Service
    apiVersion: v1
    metadata:
      name: svc-frontend
      labels:
        name: frontend
        version: "1"
    spec:
      type: NodePort
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
        nodePort: 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()."
    ";
    echo "Version: ".$_ENV['SERVICE_VERSION']."
    ";

    delay.php

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

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

    istio 的注入

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

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

    spec:
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      selector:
        name: frontend

    接下来进行注入操作

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

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

        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        image: 10.211.55.86:5000/istio/proxy_debug:0.1.6
        imagePullPolicy: Always
        name: proxy
        resources: {}
        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 u0026u0026 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: tool
      labels:
        name: tool
        version: "1"
    spec:
      replicas: 1
      template:
        metadata:
          labels:
            name: tool
            version: "1"
        spec:
          containers:
          - name: tool
            image: 10.211.55.86:5000/php:7.1.7-apache
            ports:
            - containerPort: 80
              protocol: TCP
            volumeMounts:
            - name: wwwroot
              mountPath: /var/www/html
          volumes:
          - name: wwwroot
            persistentVolumeClaim:
              claimName: frontend-v1
    ---
    kind: Service
    apiVersion: v1
    metadata:
      name: tool
      labels:
        name: tool
    spec:
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      selector:
        name: tool

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

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

    转自:https://www.kubernetes.org.cn/2449.html

  • 相关阅读:
    腾讯TDW:大型Hadoop集群应用[转载]
    [转]常见分布式系统数据分布解析
    一种基于Storm的可扩展即时数据处理架构思考
    storm
    storm
    精华文章
    Dubbo使用解析及远程服务框架
    职责链实现的apache.chain使用
    设计模式之享元模式
    SVN安装与eclipseSVN插件基本使用
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/8023041.html
Copyright © 2011-2022 走看看