华相
TA的个人档案
华相_个人页
文章
22
问答
0
视频
0
个人介绍
暂无个人介绍
擅长的技术
- Java
- Python
- Linux
- 数据库
获得更多能力
通用技术能力：
-
容器
高级
能力说明：
熟练掌握Docker各类高级特性，包括容器数据卷、DockerFile构建等；熟练使用Docker封装MySQL、Redis、Tomcat、Apache等镜像，并可在公有云或私有云部署并保持稳定运行。
云产品技术能力：
-
ACP
-
阿里云云计算ACP专业认证考试
获得于2021-04-25 21:16:29
-
阿里云云计算ACP专业认证考试
阿里云技能认证
详细说明-
发表了文章 2021-04-16
注册集群接入MSE
在容器服务的“应用目录”里找到“ack-mse-pilot”填入image（如果没有vpc网络，需要使用公网地址的镜像，即registry-vpc替换成registry）、accessKey、secretKey三个参数，创建即可部署完成后可以参照下面两篇文档做金丝雀发布和无损下线：全链路金丝雀发布无损下线
-
发表了文章 2020-06-12
ACK-Windows节点上使用云盘
环境要求 创建Linux托管集群，添加OS为Windows的节点池来使用Windows节点 在集群上下发flexvolume组件 kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: alicloud-disk-common-windows provisioner: alicloud/disk parameters: type: cloud fstype: ntfs --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: alicloud-disk-efficiency-windows provisioner: alicloud/disk parameters: type: cloud_efficiency fstype: ntfs --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: alicloud-disk-ssd-windows provisioner: alicloud/disk parameters: type: cloud_ssd fstype: ntfs --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: alicloud-disk-available-windows provisioner: alicloud/disk parameters: type: available fstype: ntfs --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: alicloud-disk-controller-runner rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["list", "watch", "create", "update", "patch"] --- apiVersion: v1 kind: ServiceAccount metadata: name: alicloud-disk-controller namespace: kube-system --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: run-alicloud-disk-controller subjects: - kind: ServiceAccount name: alicloud-disk-controller namespace: kube-system roleRef: kind: ClusterRole name: alicloud-disk-controller-runner apiGroup: rbac.authorization.k8s.io --- kind: Deployment apiVersion: extensions/v1beta1 metadata: name: alicloud-disk-controller-windows namespace: kube-system spec: replicas: 1 strategy: type: Recreate template: metadata: labels: app: alicloud-disk-controller spec: nodeSelector: beta.kubernetes.io/os: windows tolerations: - key: "os" operator: "Equal" value: "windows" effect: "NoSchedule" - effect: NoSchedule operator: Exists key: node-role.kubernetes.io/master - effect: NoSchedule operator: Exists key: node.cloudprovider.kubernetes.io/uninitialized serviceAccount: alicloud-disk-controller serviceAccountName: alicloud-disk-controller containers: - name: alicloud-disk-controller image: registry.cn-hangzhou.aliyuncs.com/acs/alicloud-disk-controller:v1.12.6.64f4aa74-windows1809 env: - name: OS_PLATFORM value: "windows" volumeMounts: - name: cloud-config mountPath: 'C:\etc\kubernetes' - name: logdir mountPath: 'C:\var\log\alicloud' volumes: - name: cloud-config hostPath: path: 'C:\etc\kubernetes' type: DirectoryOrCreate - name: logdir hostPath: path: 'C:\var\log\alicloud' type: DirectoryOrCreate --- apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: flexvolume-windows namespace: kube-system labels: k8s-volume: flexvolume spec: selector: matchLabels: name: acs-flexvolume template: metadata: labels: name: acs-flexvolume spec: nodeSelector: beta.kubernetes.io/os: windows tolerations: - key: "os" operator: "Equal" value: "windows" effect: "NoSchedule" containers: - name: acs-flexvolume image: registry.cn-hangzhou.aliyuncs.com/acs/flexvolume:v1.12.6.b4d6e53-windows1809 imagePullPolicy: Always command: ["pwsh.exe"] args: ["-Command", "/entrypoint-windows.ps1"] securityContext: privileged: true env: - name: ACS_DISK value: "true" resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: usrdir mountPath: 'C:\host' volumes: - name: usrdir hostPath: path: 'C:\' updateStrategy: type: RollingUpdate 验证 部署后可以下发下面yaml定义的pvc和deploy来验证存储组件是否已经可用： kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-disk spec: accessModes: - ReadWriteOnce storageClassName: alicloud-disk-ssd-windows resources: requests: storage: 20Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: dynamic-create labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: nodeSelector: beta.kubernetes.io/os: windows tolerations: - key: "os" operator: "Equal" value: "windows" effect: "NoSchedule" containers: - name: nginx image: registry.cn-hangzhou.aliyuncs.com/acs/flexvolume:1.11.2.2af33e7-windows1809 command: ["pwsh.exe"] args: ["-Command", "start-sleep 1000"] volumeMounts: - name: disk-pvc mountPath: 'C:\data' volumes: - name: disk-pvc persistentVolumeClaim: claimName: pvc-disk 如果组件正常，可以看到自动创建出的pv： $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE d-2zeh2yew2t48lu75joy1 20Gi RWO Delete Bound default/pvc-disk alicloud-disk-ssd 2m46s
-
发表了文章 2020-05-22
Windows节点上使用logtail
环境要求 创建Linux托管集群，添加OS为Windows的节点池来使用Windows节点 集群已经部署了日志组件 添加Windows节点的logtail 在kube-system下的configmap alibaba-log-configuration中添加item ## 根据集群所在的region，写入对应的值 win-log-config-path: C:\Program Files (x86)\Alibaba\Logtail\conf\{your region}\ilogtail_config.json 部署Windows节点的daemonset apiVersion: extensions/v1beta1 kind: DaemonSet metadata: labels: k8s-app: win-logtail-ds name: win-logtail-ds namespace: kube-system spec: selector: matchLabels: k8s-app: logtail-ds kubernetes.io/cluster-service: "true" version: v1.0 template: metadata: annotations: scheduler.alpha.kubernetes.io/critical-pod: "" labels: k8s-app: logtail-ds kubernetes.io/cluster-service: "true" version: v1.0 spec: containers: - env: - name: ALIYUN_LOGTAIL_CONFIG valueFrom: configMapKeyRef: key: win-log-config-path name: alibaba-log-configuration - name: ALIYUN_LOGTAIL_USER_ID valueFrom: configMapKeyRef: key: log-ali-uid name: alibaba-log-configuration - name: ALIYUN_LOGTAIL_USER_DEFINED_ID valueFrom: configMapKeyRef: key: log-machine-group name: alibaba-log-configuration - name: ALICLOUD_LOG_DOCKER_ENV_CONFIG value: "true" - name: ALICLOUD_LOG_ECS_FLAG value: "true" - name: ALICLOUD_LOG_DEFAULT_PROJECT valueFrom: configMapKeyRef: key: log-project name: alibaba-log-configuration - name: ALICLOUD_LOG_ENDPOINT valueFrom: configMapKeyRef: key: log-endpoint name: alibaba-log-configuration - name: ALICLOUD_LOG_DEFAULT_MACHINE_GROUP valueFrom: configMapKeyRef: key: log-machine-group name: alibaba-log-configuration - name: ALIYUN_LOG_ENV_TAGS value: _node_name_|_node_ip_ - name: _node_name_ valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName - name: _node_ip_ valueFrom: fieldRef: apiVersion: v1 fieldPath: status.hostIP - name: cpu_usage_limit value: "1.0" - name: mem_usage_limit value: "512" - name: max_bytes_per_sec value: "20971520" - name: send_request_concurrency value: "20" image: registry.cn-hangzhou.aliyuncs.com/log-service/winlogtail:ltsc2019-1.0.0.10 imagePullPolicy: IfNotPresent name: logtail resources: limits: memory: 512Mi requests: cpu: 100m memory: 256Mi securityContext: privileged: false terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: '\\\\.\pipe\docker_engine' name: sock - mountPath: 'c:\ProgramData\docker' name: root readOnly: true - mountPath: 'c:\logtail_host' name: root-c readOnly: true nodeSelector: beta.kubernetes.io/os: windows terminationGracePeriodSeconds: 30 tolerations: - effect: NoSchedule key: os operator: Equal value: windows volumes: - hostPath: path: '\\\\.\pipe\docker_engine' name: sock - hostPath: path: 'c:\ProgramData\docker' name: root - hostPath: path: 'c:\' name: root-c 目前logtail仅限于支持采集stdout的输出至日志服务，后续会支持对日志文件的采集 部署完成后可以使用如下应用去验证是否可用： apiVersion: extensions/v1beta1 kind: Deployment metadata: labels: app: logtail-test name: logtail-test spec: replicas: 1 template: metadata: labels: app: logtail-test name: logtail-test spec: containers: - name: nanoserver image: mcr.microsoft.com/windows/servercore:1809 command: ["powershell.exe"] args: ["ping -t 127.0.0.1 -w 10000"] env: ######### 配置 环境变量 ########### - name: aliyun_logs_logtail-stdout value: stdout - name: aliyun_logs_logttail-tags value: tag1=v1 ################################# nodeSelector: beta.kubernetes.io/os: windows tolerations: - effect: NoSchedule key: os operator: Equal value: windows
-
发表了文章 2020-04-17
纳管集群接入Virtual Node
接入virtual node 在容器服务的应用目录里找到“ack-virtual-node” 在提供的env中填入合适的值，然后安装即可： Key 说明 ALIYUN_CLUSTERID 集群ID（会自动填入） ALIYUN_RESOURCEGROUP_ID 资源组ID（可以留空） ECI_REGION 地域ID（会自动填入） ECI_VSWITCH 虚拟交换机ID（ECI Pod会挂在这个虚拟交换机下面） ECI_SECURITY_GROUP 安全组ID（ECI Pod会挂在这个安全组下面） ECI_ACCESS_KEY Access Key（virtual node用来操作ECI的凭证） ECI_SECRET_KEY Secret Key（virtual node用来操作ECI的凭证） 在纳管集群中，自有资源上的Pod和virtual node创建出来的ECI Pod默认并不互通
-
发表了文章 2020-03-06
纳管集群接入Metric Adapter
在容器服务的应用目录里找到“ack-alibaba-cloud-metrics-adapter” 填入AccessKeyId、AccessKeySecret、RegionId这三个参数，“创建”即可 部署完成后可以参考这里的例子
-
发表了文章 2020-02-04
纳管集群接入事件中心
接入NPD 在容器服务的应用目录里找到“ack-node-problem-detector” 部署NPD要配置的参数较多： alibaba_cloud_plugins：不需要选择ram_role_check，nvidia_gpu_check视情况选择 serviceaccount：填入集群中权限较大的一个，一般自建的有admin-user，可以kubectl -n kube-system get sa来查看 env：填入AccessKeyId、AccessKeySecret、RegionId这三个参数 sls: enabled：如果需要将event归档到日志服务，就将enabled设为true topic：填写您的集群可读名称 project：填写您的集群对应的日志服务project名称 logstore：填写project下已有的某个logstore（如果要使用日志服务的事件中心功能，˙这里要填为k8s-event） internal：如果有专线，可以填为true，否则填为false dingtalk： enabled：如果需要将event告警到钉钉群，就将enabled设为true monitorkinds：选择要接收的告警类型，一般选择Node token：填入钉钉只能群助手的token（不是全部的URL） 创建事件中心 登录日志服务控制台。 在日志应用区域，单击K8s事件中心。 在事件中心管理页面，单击添加。 在添加事件中心页面，配置相关参数。 选择已有Project，可从Project下拉框中选择已创建的Project。(与NPD的参数保持一致) 配置成功后，即可使用事件中心
-
发表了文章 2019-12-30
纳管集群介绍
为什么需要纳管集群？ 因为种种原因，我们可能在云和IDC里拥有多个K8s集群，有可能还同时有多个云商的K8s集群，如何便捷、统一的管理这些集群就成为一个问题，并且在不同的集群上，集群审计、日志采集、监控告警等能力是否能够对齐？这些能力的实现方式是否是对应用透明？ 纳管集群希望能为分布在各处的K8s集群提供统一的使用、管理方式 纳管集群能做哪些事情？ 在ACK控制台管理接入的集群 接入集群审计功能 接入集群事件中心 接入Node Problem Detector（npd） 接入阿里云日志服务 接入Arms-Prometheus 接入Arms-应用监控 接入Ahas-架构感知 接入Ahas-应用限流 接入Metric Adapter 接入Virtual Node 纳管集群不能做的事情 不能帮你在IDC创建K8s集群 不能在接入的集群中部署Ingress controller 纳管集群的费用 一个最简的纳管集群只包含以下资源： 一个弹性网卡（免费） 一个性能保障型内网负载均衡（slb.s1.small-免费） 一个弹性公网IP（按量付费，5Mbps带宽） 其余按使用的功能收取费用 创建纳管集群 创建过程参考这里
-
发表了文章 2019-12-30
纳管集群接入Ahas-应用限流
在容器服务的应用目录里找到“ack-ahas-sentinel-pilot” 填入region_id这一个参数，“创建”即可 如果集群和vpc之间有专线，region_id按专线连接的region填写，如果没有，region_id请填入“cn-public” 创建完成后，可以用下面这个例子验证安装是否成功 注意：如果没有专线，要在应用的annotations里加入"ahasLicenseKey"，获取方法见下图
-
发表了文章 2019-12-30
纳管集群接入Ahas-架构感知
在容器服务的应用目录里找到“ack-ahas-pilot” 填入合适的参数后，“创建”即可，图中红框标注处均需要填入自己集群对应的值 如果集群和vpc之间有专线，region_id按专线连接的region填写，如果没有，region_id请填入“cn-public” license请按下图指引获取 部署完成后可以在“应用高可用服务”里查看集群的拓扑图 如果创建时填入的region是“cn-public”，需要在“公网”里查看集群拓扑图 效果图如下
-
发表了文章 2019-12-26
纳管集群接入Arms-Prometheus
接入Arms-Prometheus 在容器服务的应用目录里找到“ack-arms-prometheus” 填入clusterID、userID、regionID三个参数后，“创建”即可 如果集群和vpc之间有专线，会自动使用 userID需要用带引号 安装完成后可以参考这里查看监控数据和定义告警规则
-
发表了文章 2019-12-26
纳管集群接入Arms-应用监控
接入Arms-应用监控 在容器服务的应用目录里找到“ack-arms-pilot” 填入合适的参数后，“创建”即可，图中红框标注处均需要填入自己集群对应的值 如果集群和vpc之间有专线，会自动使用 创建完成后可以用下面这个例子来验证安装是否成功
-
发表了文章 2019-12-25
纳管集群接入日志服务
接入日志服务 在容器服务的应用目录里找到“ack-sls-log-controller” 填入合适的参数后，“创建”即可，图中红框标注处均需要填入自己集群对应的值 如果集群和vpc有专线打通 InstallParam参数可以去掉'-internet'后缀 Endpoint参数可以在{region-id}后增加'-intranet'后缀 创建完成后可以在控制台下发下面这段yaml验证日志服务是否可用 apiVersion: v1 kind: Pod metadata: name: my-demo spec: containers: - name: my-demo-app image: 'registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest' env: ######### 配置 环境变量 ########### - name: aliyun_logs_log-stdout value: stdout - name: aliyun_logs_log-varlog value: /var/log/*.log - name: aliyun_logs_mytag1_tags value: tag1=v1 ############################### ######### 配置vulume mount ########### volumeMounts: - name: volumn-sls-mydemo mountPath: /var/log volumes: - name: volumn-sls-mydemo emptyDir: {} ############################### 预期会在日志服务对应的project下面有两个logstore："log-stdout"和“log-varlog”和对应的日志内容（日志展示会有一定延迟） 如果集群中有部署ngress-nginx，可以参考这里部署Ingress的采集日志
-
发表了文章 2019-09-18
prometheus operator告警规则（一）：你的cpu够用吗？
ack-prometheus-operator就像一把瑞士军刀，包含非常丰富的功能，安装后会自动部署prometheus、grafana、alertmanager等组件，并会下发很多的监控相关的规则，包括metric采集规则、告警规则和grafana dashboard。但是很朋友看到这些指标和规则后，只能感受到他的强大，却不知道如何发挥它强大的功能，我们这一系列文章就是描述如何快速上手使用ack-prometheus-operator，让这把瑞士军刀发挥出强大的作用 背景知识 Prometheus告警规则 Prometheus查询语法 开始之前 你需要有一个ACK集群，以及配置好可以管理这个集群的kubectl，集群上还要有ingress controller和helm tiller，如果你还没有集群，可以使用ACK快速部署kubernetes集群 安装ack-prometheus-operator，参考这里 CPUThrottlingHigh 很多Kubernetes的用户都会苦恼如何配置cpu的limit，并且不知如何确认自己当前的配置是否合理，这里就来演示如何利用ack-prometheus-operator自带的告警规则发现cpu limit的不合理配置 ack-prometheus-operator部署后默认带有个叫CPUThrottlingHigh的rule，expr如下： 100 * sum by(container_name, pod_name, namespace) (increase(container_cpu_cfs_throttled_periods_total{container_name!=""}[5m])) / sum by(container_name, pod_name, namespace) (increase(container_cpu_cfs_periods_total[5m])) > 25 这个表达式的作用是查出最近5分钟，超过25%的CPU执行周期受到限制的container，这里用到了来自kubelet的两个重要指标： container_cpu_cfs_periods_total：container生命周期中度过的cpu周期总数 container_cpu_cfs_throttled_periods_total：container生命周期中度过的受限的cpu周期总数 下面我们就用一个例子来验证这个告警规则的可靠性： apiVersion: v1 kind: Pod metadata: name: cpu-demo spec: containers: - name: cpu-demo image: vish/stress resources: limits: cpu: "2" requests: cpu: "2" args: - -cpus - "3" 这个pod，我们给他的cpu limit配置成2，然后容器的进程配置申请3个cpu核心的用量，这个pod下发下去，不久就可以在Prometheus的alert页面看到CPUThrottlingHigh这个告警规则变成active 小结 Prometheus为kubernetes提供了丰富的可观测指标，有了这些指标，我们队集群的掌握就告别了盲人摸象的阶段，并且可以利用我们观测到的指标来持续的优化我们的应用配置
-
发表了文章 2019-09-18
Jenkins on ACK实战（三）：容器化的构建
上一篇中，我们演示了如何配置并运行一条简单的流水线，可能有些读者对于上篇文章中的配置还有些疑问： 为何构建任务运行时会有一个slave节点加入 pipeline的写法似乎和Jenkins文档中的例子有点不一样 今天这篇文章就来解答上面两个问题，并解释下构建中的几个stage跟传统环境中的差异 哪里来的slave？ 这些slave节点都是kubernetes-plugin这个插件动态创建的，实际上是在kubernetes运行的一个pod 大家应该还记得，我们在第一篇文章中，检查Jenkins安装结果的时候，查看了cloud的kubernetes配置，这些配置就是给kubernetes-plugin用的 这个插件会扩展pipeline的写法，允许我们自定义执行构建的环境，这也是为什么我们的pipeline会跟常见的有些差异的原因 slave节点配置 参数 作用 名称 kubernetes集群的标识，pipeline中以此选择在哪个集群中做构建 Kubernetes 地址 kubernetes api入口，如果要连接Jenkins master所在的集群，写成https://kubernetes.default 即可 凭据 连接kubernetes api的凭据，如果Jenkins master在集群内且安装了rbac权限，可以留空 Jenkins 地址 slave节点连接Jenkins master的地址 Jenkins 通道 Jenkins master节点连接slave的地址 Pod 模板 slave节点的定义，可以定义调度规则，包含那些容器，挂载哪些配置等 在我们这个环境中，pod模板的定义放在了pipeline里，可以提供更好的可回溯性 这里面还有几个点要注意： Jenkins会在slave pod启动的时候自动注入一个jnlp container，用来和Jenkins master通信 一般来讲，pod中的container都会有至少一个stage与其相对应，且stage一般都是串行执行，所以，container的主进程要配置成阻塞在stdin container之间一般都会有数据传递，默认会给pod上加一个emptydir的volume，mount到每一个container的/home/jenkins/agent目录，并且这个目录作为各个container的workspace 容器中的CI/CD 既然slave节点是Jenkins在kubernetes中动态创建的pod，那么自然我们所有的CI/CD流程都是在容器中进行的，如果说容器中做代码构建和传统环境区别还不算大，那么在后面的docker镜像构建、发布到kubernetes等过程就有了比较大的变化了，也是常常会困扰我们的问题，这里我们要推荐一些新东西出来： 无docker daemon的image build 在容器中做image build并不是新鲜事，常见的有这么几种做法： dind方式，需要privilege权限 挂载/var/run/docker.sock文件到容器里，完全操作主机的docker daemon 这两种方式都对主机有要求，并且在serverless的virtual node上无法使用，我们在示例的pipeline中使用的是kaniko，完全不依赖docker daemon即可完成image build kubernetes-cli插件 在将应用发布到kubernetes的时候，需要用到kubectl，这里有两种方式： 将目标集群的.kube/config文件保存在configmap里，通过volume的方式挂载到容器里，在容器内使用kubectl 将目标集群的任意凭证保存在Jenkins里，通过kubernetes-cli插件来使用kubectl 在我们的例子中使用的是第二种方式 小结 前面两篇文章介绍了如果快速搭建Jenkins环境、演示了一条简单的流水线，本片着重介绍这种构建方式要注意的点以及因这种构建方式而引入的新的工具 后面我们会介绍在这套基于容器的Jenkins环境中的发布实践 参考 kubernetes-plugin kaniko
-
发表了文章 2019-08-15
Jenkins on ACK实战（二）：这是一条简单的流水线
上一篇结束的时候，我们已经部署了一套Jenkins环境，今天我们就在这套环境里来创建一条简单的流水线来做应用的构建并发布到这个集群 开始之前 在集群中创建用到的registry的访问密钥，这里我们使用阿里云容器镜像服务的北京区域 $ docker login -u xxx -p xxx registry.cn-beijing.aliyuncs.com Login Succeeded $ kubectl create secret generic jenkins-docker-cfg -n ci --from-file=/root/.docker/config.json > 注意：如果是在Mac上操作，需要先把~/.docker/config.json里的`credsStore`参数项删除再去login 创建流水线部署的目标环境，这里我们选择部署到这个集群的pro namespace，对于正式环境，请选择不同的集群 $ kubectl create ns pro 在jenkins中创建访问目标集群的密钥 $ kubectl -n kube-system get serviceaccount admin -o go-template --template='{{range .secrets}}{{.name}}{{"\n"}}{{end}}' ${admin-token-6xbcz} $ kubectl -n kube-system get secrets ${admin-token-6xbcz} -o go-template --template '{{index .data "token"}}' | base64 -D eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2V[...] 将获取到的token保存在Jenkins里 配置流水线 创建流水线项目 配置pipeline逻辑，将下面一段pipeline代码写入项目的Pipeline script pipeline { agent { kubernetes { label 'jenkins-pod' defaultContainer 'jnlp' yaml """ apiVersion: v1 kind: Pod metadata: labels: app: jenkins-slave-pod spec: containers: - name: golang image: golang:1.12 command: - cat tty: true - name: kaniko image: registry.cn-beijing.aliyuncs.com/acs-sample/jenkins-slave-kaniko:0.6.0 command: - cat tty: true volumeMounts: - name: ymian mountPath: /root/.docker - name: kubectl image: roffe/kubectl:v1.13.2 command: - cat tty: true - name: busybox image: ymian/busybox command: - cat tty: true volumes: - name: ymian secret: secretName: jenkins-docker-cfg items: - key: config.json path: config.json """ } } stages { stage('Build') { steps { container('golang') { git url: 'https://github.com/HYmian/gin-sample.git' sh """ go build -mod vendor -v """ } } } stage('Image Build And Publish') { steps { container("kaniko") { sh "kaniko -f `pwd`/Dockerfile -c `pwd` -d registry.cn-beijing.aliyuncs.com/${your_repo}/gin-sample" } } } stage('Deploy to pro') { steps { container("kubectl") { withKubeConfig( [ credentialsId: 'pro-env', serverUrl: 'https://kubernetes.default.svc.cluster.local' ] ) { sh ''' kubectl apply -f `pwd`/deploy.yaml -n pro kubectl wait --for=condition=Ready pod -l app=gin-sample --timeout=60s -n pro ''' } } } } } } 我们这里为了演示方便，直接在Jenkins里写pipeline的逻辑，但是在正式使用时，应该将pipeline保存为单独的文件并和项目的代码放在同一个仓库里 注意将代码里的${your_repo}替换成自己的仓库名称 验证流水线，手动触发，成功后可以在blue ocean中看到结果 小结 本文配置了一条包含构建、打包、部署三个stage的简单流水线，pipeline是Jenkins 2.0开始引入的概念，关于pipeline的优势可以参考官方给出的说明 可能在上面一节里，关于agent这一段的定义会让大家更迷惑一点，在下一篇文章里，我们会着重给大家介绍这一部分
-
发表了文章 2019-08-09
Jenkins on ACK实战（一）：部署和初始化
随着云原生时代的到来，一个良好的CI/CD系统成为我们敏捷交付的必不可缺的基础，那我们搭建CI/CD系统的时候，能不能利用云原生的基础设施--kubernetes--来获取一些收益呢？ 我们接下来的这一系列文章就围绕着这个主题来展开--如何围绕着kubernetes来搭建CI/CD系统，kubernetes和CI/CD的工具我们的选择分别是阿里云容器服务(ACK)和Jenkins 开始之前 你需要有一个ACK集群，以及配置好可以管理这个集群的kubectl，集群上还要有ingress controller和helm tiller，如果你还没有集群，可以使用ACK快速部署kubernetes集群 你需要有helm client，并且可以使用上面的kubectl工具的配置管理集群，helm client部署参考这里 获取Jenkins helm chart，如果你可以访问helm repo，这一步可以不用做；如果不能的话，请先把这个repo的内容下载到本地 部署Jenkins 在现有集群中创建名为jenkins的namespace kubectl create ns jenkins 利用helm部署Jenkins helm install --name jenkins --namespace jenkins stable/jenkins \ --set master.tag=lts \ --set master.image=jenkins/jenkins \ --set master.adminPassword=admin \ --set master.jenkinsUriPrefix="/jenkins" \ --set master.installPlugins="{kubernetes:latest,blueocean:latest,job-dsl:latest,kubernetes-cli:latest,prometheus:latest,configuration-as-code:latest}" \ --set master.serviceType=ClusterIP \ --set master.ingress.enabled=true \ --set master.ingress.path="/jenkins" \ --set agent.enabled=false \ --set persistence.storageClass=alicloud-disk-ssd \ --set persistence.size=20Gi \ --set rbac.create=true 等待部署完成 kubectl -n jenkins wait --for=condition=Ready pod -l app.kubernetes.io/instance=jenkins 部署过程中会安装多个插件，这里选择使用阿里云ssd云盘作为pv可以明显提升部署速度，如果换成高效云盘部署时间会长很多 部署参数说明 参数 作用 master.image master.tag 指定镜像名称和tag master.adminPassword 指定Jenkins admin用户密码 master.jenkinsUriPrefix 指定Jenkins master监听的root URI，和ingress选项一起使用 master.installPlugins 指定初始化时需要安装的插件列表 master.serviceType 指定Jenkins master关联的service的类型，默认是Loadbalancer master.ingress.enabled master.ingress.annotations.path 配置ingress并指定URL agent.enabled 是否部署agent persistence.storageClass persistence.size=20Gi 指定pv的storageclass和对应的参数 rbac.create 是否创建rbac权限 检查Jenkins 执行下面的命令获取Jenkins入口 JENKINS_MASTER=kubectl get ing jenkins-1 -o jsonpath='{.status.loadBalancer.ingress[0].ip}' 访问http://${JENKINS_MASTER}/jenkins，可以用前面设置的密码登录进去 在Manage Plugins页面，可以看到部署参数指定的插件已经安装 在Configure System页面，可以看到kubernetes-plugin插件已经配置 在Manage Jenkins页面，可以看到Configuration as Code选项 这里要特别介绍下Configuration as Code这个插件，这是Jenkins一个比较新的子项目，目的是为了将Jenkins的配置定义为简化的、人性化的纯文本 yaml 语法，有了这个项目我们不仅可以快速的启动一个Jenkins，还可以快速的将现有的Jenkins的配置移植过来，而不用再重新手动配置一次 我们可以在页面上apply下面这个URL，可以在Jenkins主页上看到马上就会多出来一个新的project :) https://raw.githubusercontent.com/jenkinsci/configuration-as-code-plugin/master/demos/jobs/multibranch-github.yaml 小结 到这里，Jenkins的部署和初始化就算完成了。我们可以看到，随着云原生的发展各种xxx as code如雨后春笋涌现出来，给我们日常的工作带来了极大的便利，后面我们以本文为基础分享各种CI/CD的最佳实践
-
发表了文章 2019-04-26
kubernetes API 访问控制在阿里云容器服务(ACK)上的实践
提起K8s API的访问控制，很多同学应该都会想到RBAC，这是K8s用来做权限控制的方法，但是K8s对API的访问控制却不止于此，今天我们就来简单介绍下K8s的访问控制以及ACK如何利用这套方法提供便捷的访问控制管理 访问控制简要说明 控制流程如上图所示，我们今天关注点在前两步，也就是图中的Authentication和Authorization Authentication做的是身份校验，Authentication支持的方法包括X509 Client Certs、Password、Plain Tokens、Bootstrap Tokens 和 JWT Tokens，今天我们要实践的就是X509 Client Certs校验方式 API server启动时传入--client-ca-file=SOMEFILE即可启用证书校验，参数指定的文件中必须包含至少一个CA证书用于校验传入的客户端证书。验证通过后，证书中的common name(CN)字段会作为请求的username，organization(O)字段作为请求的group Authorization做的是授权鉴定，一个请求通过Authentication后，会带着一个user和group，Authorization做的就是判断请求的方法(verb)和对象(object)是否在user和group的权限范围内；从1.8版本之后，RBAC模式进入stable状态，也是ACK默认启用的鉴权方式，RBAC模块会通过role/clusterrole和rolebinding/clusterrolebinding来鉴定请求所关联的user和group是否有操作的权限 下面我们通过操作来看下ACK上是如何做这些事的 环境准备 kubernetes 可以通过容器服务管理控制台非常方便地快速创建 Kubernetes 集群。具体过程可以参考这里 一个授予集群权限的子账号 子账号绑定的操作请参考这里 验证 我们按照上面的步骤操作，给子账号绑定default空间下的开发人员角色 登录子账号，在集群的详情页找到kubeconfig的信息，复制其中的user.client-certificate-data字段，执行下面的命令 echo $CERTIFICATE | base64 -D > test.crt openssl x509 -in test.crt -noout -text 会看到类似下面的输出 Certificate: Data: Version: 3 (0x2) Serial Number: 980377 (0xef599) Signature Algorithm: sha256WithRSAEncryption Issuer: O=cb4541f68933d4927b445b1eec47ce8b6, OU=default, CN=cb4541f68933d4927b445b1eec47ce8b6 Validity Not Before: Apr 24 08:19:00 2019 GMT Not After : Apr 23 08:24:49 2022 GMT Subject: O=system:users, OU=, CN=232157355171679750 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) ... 看证书的subject字段，O=system:users CN=232157355171679750，表示使用这个证书作为身份校验的请求，在服务端看来，user是232157355171679750，group是system:users 接下来我们继续看这个user和group在集群中被赋予的权限 ~ kubectl get rolebinding NAME AGE 232157355171679750-default-rolebinding 10s ~ kubectl get rolebinding 232157355171679750-default-rolebinding -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: ... roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cs:ns:dev subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: "232157355171679750" 可以看到user 232157355171679750被绑定了cs:ns:dev这个集群角色，可以操作许多资源，但是都被限制在default这个namespace下(不能查看node，因为node是跨namespace的资源)，因为给这个user绑定是通过rolebinding来做的，是受namespace的约束的(kubectl describe clusterrole cs:ns:dev即可看到这个子账号被授予的所有权限) 我们再给账号扩大一些权限，这次给他绑定整个集群的管理员角色 然后我们就会发现刚才的rolebinding已经被删除了 ~ kubectl get rolebinding No resources found. 因为这次绑定是整个集群范围内的，所以产生的是clusterrolebinding ~ kubectl get clusterrolebinding NAME AGE 232157355171679750-clusterrolebinding 3s 可以用上面的方法继续查看集群管理员角色下的所有权限 但是集群管理员并不是权限最高的角色，权限最高的角色是自定义列表中的cluster-admin，这是kubernetes集群启动后内置的角色，也是主账号创建集群后生成的config文件中绑定的角色 角色和权限的选择 既然kubernetes中内置了许多的role和clusterrole，那我们该如何选择呢？又如何判断当前的角色是否满足了需求呢？ 还好kubectl已经提供了对应的命令来帮助我们快速判断权限是否充分 kubectl auth can-i <verb> <resource> [<resourceName>] 我们还是以一个被绑定了集群管理员的角色为例，下面的kubectl命令均是使用了对应的config文件 ~ kubectl auth can-i delete no yes ~ kubectl auth can-i drain no no - no RBAC policy matched ~ kubectl auth can-i taint no no - no RBAC policy matched ~ kubectl auth can-i cordon no no - no RBAC policy matched ~ kubectl auth can-i label no no - no RBAC policy matched ~ kubectl auth can-i delete pv yes ~ kubectl auth can-i delete pvc yes 我们看到这个角色的可以删除node、pv和pvc，但是不能对node做drain，taint，cordon，label，可以利用这个工具快速定位操作失败是否和权限有关 总结 ACK将阿里云上的子账号系统和kubernetes本身的访问控制非常平滑的连接在一起，对用户非常友好，不需要花太多的精力在RBAC的细节上，极大的降低了使用门槛
-
发表了文章 2018-12-07
使用privateZone统一跨region的镜像仓库访问
在阿里云的不同region里，内网的镜像服务使用的域名是不同的，会带着region的名称。这时候，如果我们的应用需要在不同region的K8s集群部署，就会有些痛苦，如果在不同region使用不同的域名，日常维护上的工作量就增加了；如果使用同样的registry公网域名，日常对镜像的操作速度就会受影响 本文就是针对这种需求，介绍如何使用private zone来实现不同region使用同样域名访问registry内网入口 环境准备 两个region的镜像仓库 一个在北京，内网名称：registry-vpc.cn-beijing.aliyuncs.com/ack-mian/test一个在深圳，内网名称：registry-vpc.cn-shenzhen.aliyuncs.com/ack-mian/test 两个region中的ECS 一台在北京，一台在深圳，均已安装好docker现在两台机器均只能pull自己region的内网名称来拉取镜像 添加zone 在控制台找到"云解析DNS"下的"PrivateZone"，添加两条记录(名字都是mirror.aliyuncs.com)，如下图所示然后两条zone记录均添加CNAME类型的解析记录，分别指向北京和深圳的registry然后按照指向的region，关联到对应region中的VPC 此时，按图中的设置，两台ECS上均可以使用test.mirror.aliyuncs.com/ack-mian/test的名称来pull镜像了 阿里云的镜像服务使用的证书里有绑定域名，上面例子中使用的mirror.aliyuncs.com在绑定域名中，所以才能正常使用，否则会报X509错误 欢迎使用阿里云上的容器镜像服务，简化Registry的搭建运维工作，支持多地域的镜像托管，并联合容器服务等云产品，打造云上使用Docker的一体化体验。
-
发表了文章 2018-11-23
在Istio上创建自定义的ingress-gateway
我们都知道，在istio中可以通过ingress gateway将服务暴露给外部使用，但是我们使用的ingress规则都是落在istio部署时默认创建的istio-ingressgateway上，如果我们希望创建自定义的ingressgateway该怎么操作呢，本文就带大家一步步操作，创建一个自定义的ingressgateway 环境准备 创建Kubernetes集群 阿里云容器服务Kubernetes 1.11.2目前已经上线，可以通过容器服务管理控制台非常方便地快速创建 Kubernetes 集群。具体过程可以参考这里 部署istio 阿里云容器服务通过集群界面部署Istio，具体过程可以参考这里 部署bookinfo 首先为default 命名空间打上标签 istio-injection=enabled kubectl label namespace default istio-injection=enabled 使用Kubectl命令部署Bookinfo示例应用 kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.0.2/samples/bookinfo/platform/kube/bookinfo.yaml 部署完成后效果如下图： $ kubectl get pod,svc NAME READY STATUS RESTARTS AGE pod/details-v1-5d88f495b7-cvxk5 2/2 Running 0 19h pod/productpage-v1-774fd75c99-5l898 2/2 Running 0 19h pod/ratings-v1-64664b6bcf-j7lzh 2/2 Running 0 19h pod/reviews-v1-fd7c6fdf5-4px4g 2/2 Running 0 19h pod/reviews-v2-56b67454cc-fmtl8 2/2 Running 0 19h pod/reviews-v3-86878d875-6xztb 2/2 Running 0 19h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/details ClusterIP 172.21.13.128 <none> 9080/TCP 19h service/kubernetes ClusterIP 172.21.0.1 <none> 443/TCP 21h service/productpage ClusterIP 172.21.7.104 <none> 9080/TCP 19h service/ratings ClusterIP 172.21.7.176 <none> 9080/TCP 19h service/reviews ClusterIP 172.21.1.207 <none> 9080/TCP 19h 创建自定义ingressgateway --- # Source: istio/charts/gateways/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount metadata: name: customgateway-service-account namespace: default labels: app: customgateway --- --- # Source: istio/charts/gateways/templates/clusterrole.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: labels: app: gateways name: customgateway-default # default should replaced by actual namespace rules: - apiGroups: ["extensions"] resources: ["thirdpartyresources", "virtualservices", "destinationrules", "gateways"] verbs: ["get", "watch", "list", "update"] --- --- # Source: istio/charts/gateways/templates/clusterrolebindings.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: customgateway-default # default should replaced by actual namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: customgateway-default # default should replaced by actual namespace subjects: - kind: ServiceAccount name: customgateway-service-account namespace: default --- --- # Source: istio/charts/gateways/templates/service.yaml apiVersion: v1 kind: Service metadata: name: customgateway namespace: default annotations: labels: istio: customgateway spec: type: LoadBalancer selector: istio: customgateway ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 443 --- --- # Source: istio/charts/gateways/templates/deployment.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: customgateway namespace: default labels: istio: customgateway spec: replicas: 1 template: metadata: labels: istio: customgateway annotations: sidecar.istio.io/inject: "false" scheduler.alpha.kubernetes.io/critical-pod: "" spec: serviceAccountName: customgateway-service-account containers: - name: istio-proxy image: "registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/proxyv2:1.0.3" imagePullPolicy: IfNotPresent ports: - containerPort: 80 - containerPort: 443 args: - proxy - router - -v - "2" - --discoveryRefreshDelay - '1s' #discoveryRefreshDelay - --drainDuration - '45s' #drainDuration - --parentShutdownDuration - '1m0s' #parentShutdownDuration - --connectTimeout - '10s' #connectTimeout - --serviceCluster - customgateway - --zipkinAddress - zipkin.istio-system:9411 - --proxyAdminPort - "15000" - --controlPlaneAuthPolicy - NONE - --discoveryAddress - istio-pilot.istio-system:8080 resources: requests: cpu: 10m env: - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace - name: INSTANCE_IP valueFrom: fieldRef: apiVersion: v1 fieldPath: status.podIP - name: ISTIO_META_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name volumeMounts: - name: istio-certs mountPath: /etc/certs readOnly: true - name: customgateway-certs mountPath: "/etc/istio/customgateway-certs" readOnly: true - name: customgateway-ca-certs mountPath: "/etc/istio/customgateway-ca-certs" readOnly: true volumes: - name: istio-certs secret: secretName: istio.customgateway-service-account optional: true - name: customgateway-certs secret: secretName: "istio-customgateway-certs" optional: true - name: customgateway-ca-certs secret: secretName: "istio-customgateway-ca-certs" optional: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: beta.kubernetes.io/arch operator: In values: - amd64 - ppc64le - s390x preferredDuringSchedulingIgnoredDuringExecution: - weight: 2 preference: matchExpressions: - key: beta.kubernetes.io/arch operator: In values: - amd64 - weight: 2 preference: matchExpressions: - key: beta.kubernetes.io/arch operator: In values: - ppc64le - weight: 2 preference: matchExpressions: - key: beta.kubernetes.io/arch operator: In values: - s390x --- --- # Source: istio/charts/gateways/templates/autoscale.yaml apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: customgateway namespace: default spec: maxReplicas: 5 minReplicas: 1 scaleTargetRef: apiVersion: apps/v1beta1 kind: Deployment name: customgateway metrics: - type: Resource resource: name: cpu targetAverageUtilization: 80 --- 上面这段yaml在default namespace定义了一个名叫customgateway的ingressgateway，并为他创建了serviceaccount，HPA等一系列相关的配置，如果我们需要定义多个，需要替换yaml里的default和customgateway为自己想要的名字 定义入口路由 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: selector: istio: customgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - "*" gateways: - bookinfo-gateway http: - match: - uri: exact: /productpage - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 这里最重要的是为Gateway指定规则落在哪个deploy上，这里指定的是istio: customgateway 访问应用 获取自定义ingressgateway的入口然后访问应用 export INGRESS_HOST=$(kubectl -n default get service customgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') export INGRESS_PORT=$(kubectl -n default get service customgateway -o jsonpath='{.spec.ports[?(@.name=="http")].port}') curl -o /dev/null -s -w "%{http_code}\n" http://${INGRESS_HOST}:${INGRESS_PORT}/productpage 如果返回200则说明配置正确 总结 上面通过示例演示了Istio如何创建一个自定义的ingress gateway 欢迎大家使用阿里云上的容器服务，快速搭建微服务的开放治理平台Istio，简单地集成到自己项目的微服务开发中。
-
发表了文章 2018-10-25
Istio Egress Gateway出口流量管理
缺省状态下，Istio服务网格内的Pod，由于其iptables将所有外发流量都透明的转发给了sidecar，所以这些集群内的服务无法访问集群之外的 URL，而只能处理集群内部的目标。 控制出口流量描述了如何通过ServiceEntry将外部服务暴露给集群内的客户端 本文则通过一个官方的用例解释如何通过Egress Gateway配置Istio的出口流量，这个例子主要适用于两种场景： 离开服务网格的所有流量必须流经一组专用节点，这一组节点会有特殊的监控和审查 集群中不是所有节点都有public IP，定义egress网关，通过它引导所有出口流量并将public IP分配给egress网关节点，允许应用节点以受控方式访问外部服务 环境准备 创建Kubernetes集群 阿里云容器服务Kubernetes 1.11.2目前已经上线，可以通过容器服务管理控制台非常方便地快速创建 Kubernetes 集群。具体过程可以参考这里 部署istio 阿里云容器服务在应用目录目前支持istio快速部署，具体过程可以参考这里 部署用例 kubectl apply -f <(istioctl kube-inject -f https://raw.githubusercontent.com/istio/istio/release-1.0/samples/sleep/sleep.yaml) 定义需要向外发送请求的pod export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) 创建ServiceEntry cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: cnn spec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https protocol: HTTPS resolution: DNS EOF 验证配置生效 kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics 如下返回表示配置生效 HTTP/1.1 301 Moved Permanently ... location: https://edition.cnn.com/politics ... HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 ... Content-Length: 151654 ... 创建Gateway cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - edition.cnn.com --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn EOF 创建VirtualService cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - istio-egressgateway - mesh http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway port: 80 route: - destination: host: edition.cnn.com port: number: 80 weight: 100 EOF 再次发送请求 kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics 此时返回应该仍然是成功的，但是我们查看istio-egressgateway的日志 kubectl logs $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') egressgateway -n istio-system | tail 应该会有一条类似这样的记录 [2018-06-14T11:46:23.596Z] "GET /politics HTTP/2" 301 - 0 0 3 1 "172.30.146.87" "curl/7.35.0" "ab7be694-e367-94c5-83d1-086eca996dae" "edition.cnn.com" "151.101.193.67:80" 说明出口流量已经汇入egress gateway，然后由他引导至集群外部 配置解释 在本例中创建了四种资源，真正定义将出口流量转发给egress gateway的是VirtualService http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 80 weight: 100 这一段配置中的match的gateways表示这一条路由规则是作用在mesh上的，也就是整个网格中所有的sidecar上，port表示所有访问80端口的流量才会应用这条规则，因为本例中只提供了80端口的服务，所以这一项是可以省略掉的 destination表示会把所有路由后的流量导入istio-egressgateway.istio-system.svc.cluster.local service的cnn sbuset下的80端口，这里需要注意的是，istio-egressgateway是在Istio部署时定义的service，已经开放了80，443端口，在真实使用中如果要用到别的端口，需要在istio-egressgateway的定义中做对应的修改 同理，VirtualService中的另一部分规则作用在istio-egressgateway上，会把出口流量引导至集群外部 总结 本文通过示例演示了Istio如何对网格内的出口流量做统一的引导。 欢迎大家使用阿里云上的容器服务，快速搭建微服务的开放治理平台Istio，比较简单地集成到自己项目的微服务开发中。 欢迎大家使用阿里云上的容器服务，快速搭建微服务的开放治理平台Istio，比较简单地集成到自己项目的微服务开发中。
-
发表了文章 2018-09-17
利用Helm驱动Kubernetes workload跟随ConfigMap/Secret联动更新
在我们使用kubernetes的过程中，通常都会将应用的配置文件放到ConfigMap或/和Secret中，但是也经常碰到配置文件更新后如何让其生效的问题，今天我们就来演示如何利用Helm来解决这个问题 环境准备 创建Kubernetes集群 阿里云容器服务Kubernetes 1.11.2目前已经上线，集群安装后会自动部署Helm Tiller，具体过程可以参考这里 安装Helm Client Helm Client是我们后续操作的基础，安装方法请参照这里 获取RabbitMQ Chart 为了后面演示Helm的功能，需要获取Chart至本地，可以使用Helm命令获取然后解压 helm fetch stable/rabbitmq tar xvf rabbitmq-2.2.0.tgz 如果网络受限，可以从github上获取 部署RabbitMQ helm upgrade --install rabbitmq rabbitmq \ --set-string rabbitmq.password=123456 \ --set ingress.enabled=true 查看Ingress Controller的EXTERNAL-IP ~ kubectl -n kube-system get svc nginx-ingress-lb NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-lb LoadBalancer 172.19.5.242 47.xxx.61.xxx 80:30544/TCP,443:31608/TCP 11d 然后用浏览器访问EXTERNAL-IP地址，可以看到RabbitMQ管理后台的登录页面，使用下面的命令查看在secret中保存的密码，配合user用户即可登入管理后台 echo "Password : $(kubectl get secret --namespace default rabbitmq -o jsonpath="{.data.rabbitmq-password}" | base64 --decode)" Password : 123456 更新RabblitMQ 如果我们现在希望更将RabbitMQ的密码做一下修改，执行下面的命令 helm upgrade --install rabbitmq rabbitmq \ --set-string rabbitmq.password=1234567 \ --set ingress.enabled=true 查看更新后的密码 echo "Password : $(kubectl get secret --namespace default rabbitmq -o jsonpath="{.data.rabbitmq-password}" | base64 --decode)" Password : 1234567 可以发现secret已经更新，但是使用新的密码登录却会失败，这便是我们在利用ConfigMap和Secret来管理配置文件时常常碰到的问题，ConfigMqp和Secret更新后，使用它们内容的Deployment/Statefulset等workload不能联动更新，下面我们通过对官方的RabbitMQ Chart做一点修改，来实现解决这个问题 修改RabbitMQ Chart 在rabbitmq/templates/statefulset.yaml的spec.template.metadata下加入这一段 annotations: checksum/config: {{ include (print $.Template.BasePath "/secrets.yaml") . | sha256sum }} 如下图所示 添加这一节的效果就是，在rabbitmq/templates/secrets.yaml中有任何内容改变，都会导致statefulset的sepc下的annotation被更新，进而驱动重建pod，达到我们想要的效果 重新执行上面的更新命令，pod重建后即可使用我们制定的密码登录管理后台 总结 本文演示了利用Helm内置Go Template函数和变量来实现kubernetes workload跟随配合自动更新效果 欢迎大家使用阿里云上的容器服务，利用kubernetes集群上自动部署的Helm快速部署和发布应用
-
发表了文章 2018-09-06
Istio Gateway与Kubernetes Ingress Controller对比
在Kubernetes环境中，Kubernetes Ingress用于配置需要在集群外部公开的服务。但是在Istio服务网格中，更好的方法是使用新的配置模型，即Istio Gateway。Gateway允许将Istio流量管理的功能应用于进入集群的流量。 二者在支持的功能上的对比，如下表所示 Istio Gateway 阿里云Ingress Controller NGINX Ingress Controller 根据HTTP Header选择路由规则 支持 仅支持单个Header，不支持多个Header组合 不支持 Header规则支持正则表达式 支持 支持 不支持 服务之间设置权重拆分流量 支持 支持 不支持 Header和权重规则组合使用 支持 支持 不支持 路由规则检查 支持 不支持 不支持 路由规则粒度 service下的不同pod service service 支持的协议 HTTP1.1/HTTP2/gRPC/TCP/Websockets/MongoDB HTTP1.1/HTTP2/gRPC/TCP/Websockets HTTP1.1/HTTP2/gRPC/TCP/Websockets 下面我们看下使用Istio Gateway实现灰度发布时，与Ingress在使用上的差异 Istio Gateway实现灰度发布 环境准备 创建Kubernetes集群 阿里云容器服务Kubernetes 1.10.4目前已经上线，可以通过容器服务管理控制台非常方便地快速创建 Kubernetes 集群。具体过程可以参考这里 部署istio 阿里云容器服务在应用目录目前支持istio快速部署，具体过程可以参考这里 部署用于灰度发布的两个服务 old service apiVersion: extensions/v1beta1 kind: Deployment metadata: name: old-nginx spec: replicas: 2 selector: matchLabels: run: old-nginx template: metadata: labels: run: old-nginx spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/xianlu/old-nginx imagePullPolicy: Always name: old-nginx ports: - containerPort: 80 protocol: TCP restartPolicy: Always --- apiVersion: v1 kind: Service metadata: name: old-nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: old-nginx sessionAffinity: None type: NodePort new service apiVersion: extensions/v1beta1 kind: Deployment metadata: name: new-nginx spec: replicas: 1 selector: matchLabels: run: new-nginx template: metadata: labels: run: new-nginx spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/xianlu/new-nginx imagePullPolicy: Always name: new-nginx ports: - containerPort: 80 protocol: TCP restartPolicy: Always --- apiVersion: v1 kind: Service metadata: name: new-nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: new-nginx sessionAffinity: None type: NodePort 部署后效果如下图 $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.19.0.1 <none> 443/TCP 9h new-nginx NodePort 172.19.8.168 <none> 80:31904/TCP 4h old-nginx NodePort 172.19.12.148 <none> 80:31545/TCP 4h 测试两个服务 $ kubectl run -it --rm bash --image=appropriate/curl --restart=Never curl 172.19.8.168 new $ kubectl run -it --rm bash --image=appropriate/curl --restart=Never curl 172.19.12.148 old 创建Gateway对象 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: helloworld-gateway spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" 确定Istio入口IP和port $ kubectl get svc istio-ingressgateway -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 172.19.14.182 47.1x6.xx.41 80:31380/TCP,443:31390/TCP,31400:31400/... 10h 确认EXTERNAL-IP设置了值 export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http")].port}') export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}') 发布场景 满足特定规则的客户端才能访问new service 例如，我们希望请求头中带有user且值为new的客户端请求才能访问new service 我们可以创建一个对应的VirtualService为通过Gateway进入的流量配置路由 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: helloworld spec: gateways: - helloworld-gateway hosts: - '*' http: - match: - headers: user: exact: new route: - destination: host: new-nginx port: number: 80 - route: - destination: host: old-nginx port: number: 80 客户端测试 $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old 在满足特定规则的客户端请求中会有一定比例访问到new service 例如，我们希望请求头中带有user且值为new的客户端请求有50%的比例访问new service，那么我们可以创建一个这样的VirtualService apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: helloworld spec: gateways: - helloworld-gateway hosts: - '*' http: - match: - headers: user: exact: new route: - destination: host: new-nginx port: number: 80 weight: 50 - destination: host: old-nginx port: number: 80 weight: 50 - route: - destination: host: old-nginx port: number: 80 客户端测试 $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT old $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT old $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT new $ curl -H "user: new" http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old 客户端请求中随机会有一定比例访问到new service 例如，我们仅仅希望20%的客户端请求访问new service，那么我们可以创建一个这样的VirtualService apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: helloworld spec: gateways: - helloworld-gateway hosts: - '*' http: - route: - destination: host: new-nginx port: number: 80 weight: 20 - destination: host: old-nginx port: number: 80 weight: 80 客户端测试 $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT old $ curl http://$INGRESS_HOST:$INGRESS_PORT new 与阿里云容器服务Kubernetes Ingress Controller使用上的对比 阿里云容器服务Kubernetes Ingress Controller提供的灰度发布功能参考这里 因为受限于Kubernetes对Ingress资源的描述，Ingress Controller只能通过各种annotation表达式来支持http路由特性 但是Istio Gateway是通过Custom Resource Definition(CRD)的方式定义一种新的资源，相比之下具有更多优势： 语义规则清晰，更有约束，与Ingress的annotation纯文本定义相比更容易检查错误 各种规则可以自由组合，比如，第一种灰度场景，如果我们希望客户端请求header中同时有user=new和foo=bar才可以访问new service时，我们可以将VirtualService修改如下： apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: helloworld spec: gateways: - helloworld-gateway hosts: - '*' http: - match: - headers: user: exact: new foo: exact: bar route: - destination: host: new-nginx port: number: 80 weight: 50 - destination: host: old-nginx port: number: 80 weight: 50 - route: - destination: host: old-nginx port: number: 80 这种场景，目前Ingress就无法支持 总结 我们可以利用阿里云Kubernetes容器服务，快速搭建一套用于连接、管理以及安全化微服务的开放平台Istio，为应用引入和配置多个相关服务。本文通过几个灰度发布的场景来体验Istio Gateway带来的Ingress功能，并同Kubernetes Ingress做了功能上的对比。欢迎大家使用阿里云上的容器服务，快速搭建微服务的开放治理平台Istio，比较简单地集成到自己项目的微服务开发中。 感谢师兄在本文写作过程中给予的指导:)
2021年04月
-
04.16 19:12:44
发表了文章
2021-04-16 19:12:44
注册集群接入MSE
注册集群接入MSE
2019年09月
-
09.18 20:54:16发表了文章
2019-09-18 20:54:16
prometheus operator告警规则（一）：你的cpu够用吗？
prometheus operator告警规则（一）：你的cpu够用吗？ -
09.18 20:50:42发表了文章
2019-09-18 20:50:42
Jenkins on ACK实战（三）：容器化的构建
Jenkins on ACK实战（三）：容器化的构建
2019年08月
-
08.15 20:01:54发表了文章
2019-08-15 20:01:54
Jenkins on ACK实战（二）：这是一条简单的流水线
Jenkins on ACK实战（二）：这是一条简单的流水线 -
08.09 15:50:03发表了文章
2019-08-09 15:50:03
Jenkins on ACK实战（一）：部署和初始化
Jenkins on ACK实战（一）：部署和初始化
-
发表了文章
2021-04-16
注册集群接入MSE
-
发表了文章
2020-06-12
ACK-Windows节点上使用云盘
-
发表了文章
2020-05-22
Windows节点上使用logtail
-
发表了文章
2020-04-17
纳管集群接入Virtual Node
-
发表了文章
2020-03-06
纳管集群接入Metric Adapter
-
发表了文章
2020-02-04
纳管集群接入事件中心
-
发表了文章
2019-12-30
纳管集群介绍
-
发表了文章
2019-12-30
纳管集群接入Ahas-应用限流
-
发表了文章
2019-12-30
纳管集群接入Ahas-架构感知
-
发表了文章
2019-12-26
纳管集群接入Arms-Prometheus
-
发表了文章
2019-12-26
纳管集群接入Arms-应用监控
-
发表了文章
2019-12-25
纳管集群接入日志服务
-
发表了文章
2019-09-18
prometheus operator告警规则（一）：你的cpu够用吗？
-
发表了文章
2019-09-18
Jenkins on ACK实战（三）：容器化的构建
-
发表了文章
2019-08-15
Jenkins on ACK实战（二）：这是一条简单的流水线
-
发表了文章
2019-08-09
Jenkins on ACK实战（一）：部署和初始化
-
发表了文章
2019-04-26
kubernetes API 访问控制在阿里云容器服务(ACK)上的实践
-
发表了文章
2018-12-07
使用privateZone统一跨region的镜像仓库访问
-
发表了文章
2018-11-23
在Istio上创建自定义的ingress-gateway
-
发表了文章
2018-10-25
Istio Egress Gateway出口流量管理
滑动查看更多
暂无更多信息
暂无更多信息