环境 istio 1.5.2 多ingressGateway 什么场景会需要多个 ingressGateway 多租户。Istio 租户模型- Namespace tenancy 描述了“命名空间”租户模型，不同集群的相同 namespace 视为一个租户。这种模型下，各租户的资源应当是隔离的，ingressgateway和各种secret（如证书）就是租户的资源。 同一个租户，需要公共/私有的入口。私有ingressGateway 在公有云上可以理解为一个内网的lb，当有业务不在k8s集群内时，集群外的业务要访问集群内的业务，一般是通过这个内网的lb；多个云SP通过专线互联时，同一个云跨AZ时；这些都对应多集群网格的构建场景，私有的ingressGateway是非常必要的，特别是Gateway方式的多集群网格，更应该选择内网lb作为集群间互通的入口，而不是mTLS的公网gateway。 components.ingressGateways 好消息是：components.ingressGateways 是一个list, 可见设计意图里包含多个 ingreessgateway。相应的，components.egressGateways 也是同样的。 $ istioctl profile dump --config-path components.ingressGateways - enabled: true k8s: hpaSpec: maxReplicas: 5 metrics: - resource: name: cpu targetAverageUtilization: 80 type: Resource minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 100m memory: 128Mi strategy: rollingUpdate: maxSurge: 100% maxUnavailable: 25% name: istio-ingressgateway 坏消息是：上面定义的多个ingressgateway 的 label 不生效(截止1.

根据官方文档：认证 章节的描述，Istio 提供两种认证机制(PeerAuthentication，RequestAuthentication)，PeerAuthentication 解决工作负载间的问题，RequestAuthentication 解决用户端的问题。本文关注用 RequestAuthentication 来保护“裸”应用。以下是需要先从官网了解的相关知识： 认证 Request authentication 环境 istio 1.5.2 RequestAuthentication 先看看 manifest 长什么样子，下面是官网的一个样例，主要由两个字段构成 selector，jwtRules。 apiVersion: "security.istio.io/v1beta1" kind: "RequestAuthentication" metadata: name: "jwt-example" namespace: istio-system spec: selector: matchLabels: istio: ingressgateway jwtRules: - issuer: "testing@secure.istio.io" jwksUri: "https://raw.githubusercontent.com/istio/istio/master/security/tools/jwt/samples/jwks.json" Reference: Request authentication 描述了manifest 的完整定义。 Reference: JWTRule 描述了 jwtRules 的定义。 Selector selector 通过 label 机制选择适用该策略的目标工作负载。 您可以将JWT策略添加到入口网关（上面的样例就是）。 这通常用于为绑定到网关的所有服务而不是单个服务定义JWT策略。下面是官方文档的原文 You can also add a JWT policy to an ingress gateway (e.g., service istio-ingressgateway.istio-system.svc.cluster.local). This is often used to define a JWT policy for all services bound to the gateway, instead of for individual services.

在进行本节练习之前，先按照官方用例 Authorization on Ingress Gateway 完成 httpbin 的部署，httpbin 这个应用真的很好用。 $ kubectl apply -f samples/httpbin/httpbin.yaml -n test-mesh $ kubectl apply -f samples/httpbin/httpbin-gateway.yaml -n test-mesh 从公网访问 http://your-lb-ip/，预期显示的是 httbin 的 swagger ui。/ip，/anything，/headers 等 restful api 会给我们调试验证带来极大的帮助。如下面的 /anything 请求，其行为是 “Returns anything that is passed to request”。 $ curl http://your-lb-ip/anything { "args": {}, "data": "", "files": {}, "form": {}, "headers": { "Accept": "*/*", "Content-Length": "0", "Host": "your-lb-ip", "User-Agent": "curl/7.54.0", "X-B3-Parentspanid": "7d83460f9c0bb319", "X-B3-Sampled": "1", "X-B3-Spanid": "e2a3c9482108d0b5", "X-B3-Traceid": "149ddcb0970898197d83460f9c0bb319", "X-Envoy-Internal": "true", "X-Forwarded-Client-Cert": "By=spiffe://cluster.

在引入 Kubernetes 时，我们需要提供对应的 CI/CD 方案。 需求&痛点 私有的统一认证，授权。角色，权限管控。 审计合规。主要包括测试人员发版，发版有历史，可审计追溯。 多云，多集群。 功能产品化。如：发版，扩容，回滚，下线。 “回滚”机制要求“编排文件”也需要用版本控制工具管理起来，版本化。 选型 rancher drone spinnaker helm 生态 为什么选择 Kubeapps Kubeapps 在整理这篇的时候，特意确认了 kubeapps 的最新架构，一些组件的名字已经发生了改变。 需求描述中的“编排文件版本化”，这正是 helm 的特性，虽然社区有其它的解决方案，但 helm 目前仍是那个应用最广泛的，成熟且有丰富的生态。 kubeapps 基于 helm。 kubeapps 是产品化的，而不是一个“轮子”。 封装良好的 api，极容易复用和扩展。这些 api 包括：整合了chartmuseum，并提供了chartsvc；tiller-proxy api；apprepository api；搜索 api，基于mongo的缓存，定时同步。 权限透明。它的权限完全是基于 Kubernetes 的 RBAC 机制，是透明的。 前端 React。 chartmuseum chartmuseum 是 helm 的 charts 仓库。 无状态 几乎支持所有云的对象存储作为后端，简单，安全。 由于我们的业务主要是在腾讯云，我们希望用其 cos 服务作为存储 backend。我们为社区提供了两个pr，完善了 chartmuseum 对腾讯云 cos 的支持。 https://github.com/helm/chartmuseum/pull/239 https://github.com/chartmuseum/storage/pull/30 系统架构 charts 的维护 charts 通过 git 进行版本控制，通过 MergeRequest(gitlab 的概念，github 叫 PullRequest) 提交变更，合并操作触发 CI 自动推送到 chartmuseum。下面是 CI 脚本，helm 的 push 插件需要自行安装。

本文的内容已经过时，未来的发行版将删除addon，请详见官方的博客Reworking our Addon Integrations，addon 整合已经不是社区未来的方向，所以可以极早向上游部署方式看齐，这是一个好的方向。 本文将部署 Istio 的监控，观测附加组件 grafana、tracing、kiali 。标题中使用了“体验”这个词，所以本文所做的练习只是用于体验，切不可用于生产，且行文的表述都是基于“体验”这个前提，体验完后，请务必清理。这种建议主要基于以下考虑: 安全。在没有应用“认证”、“授权”机制前，这些服务裸奔在公网是危险的，即使有的系统有帐密。 存储。这些服务都是有状态的，涉及状态数据的存储，如：promethues、grafana、kiali、tracing。这些 Pod 一旦重建，数据就会丢失。一般地，需要我们适配 k8s 标准化过的存储机制，如：storageClass、pv、pvc等。 组件部署 查看支持的 addonComponents，以及默认的配置值。 $ istioctl profile dump --config-path addonComponents 2020-06-10T01:37:35.653332Z info proto: tag has too few fields: "-" grafana: enabled: false k8s: replicaCount: 1 istiocoredns: enabled: false kiali: enabled: false k8s: replicaCount: 1 prometheus: enabled: true k8s: replicaCount: 1 tracing: enabled: false grafana 在 override 文件中添加 addonComponents.grafana.enabled=true 项后，应用到集群。 apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system spec: profile: default addonComponents: grafana: enabled: true components: ingressGateways: - name: istio-ingressgateway enabled: true k8s: serviceAnnotations: # https://cloud.

istio 1.5.0 于北京时间2020年3月6日发布，该版本在架构上有很大的变化(Istio 1.5 新特性解读)，做出这些改变的原因及其重大意义这里不做赘述，有大量的文章做了阐述，本文聚焦于探索 istio-1.5.0 的行为。文中的练习是在腾讯云的容器服务 tke-1.16.3 上进行的，会涉及到一些云平台相关的实现。 安装istio 使用 istioctl 安装是官方推荐的方式(Customizable Install with Istioctl)，helm 安装方式已经被标记为 deprecated，且已经不支持 helm3。istioctl 安装实践，一般选择一个profile（生产环境，社区推荐基于 default），然后用自定义的值进行覆盖，一般而言，我们只需要编写这个 override 文件(这里的文件名是 profile-override-default.yaml)，不需要修改 charts （当然charts是可以被修改的）。 apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system spec: profile: default 另一面，override 文件中的项，以及项的节点层次怎么找呢？建议两种方式：1，通过 istioctl profile dump default 命令可以打印一些，但不够全；2，查看 charts （install/kubernetes/operator/charts/） 里各子项目的 values 文件定义，这种方式最可靠，对值的行为还可以辅以 templates 文件更深入的了解，推荐这种。 有了 override 文件后，就可以使用下面的命令生成 manifest，manifest 是 k8s 的定义。建议把 override 文件和生成的 manifest 文件都通过版本控制工具维护起来，在每次对 override 操作后，对比前后的差异。 $ istioctl manifest generate -f profile-override-default.yaml > manifest-override-default.

我们在使用腾讯云容器服务(tke)的过程中，遇到"no route to host"问题，这里记录为运维日志。 环境 tke 1.12.4(1.14.3) 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64 kube-proxy ipvs模式 /usr/bin/kube-proxy –proxy-mode=ipvs –ipvs-min-sync-period=1s –ipvs-sync-period=5s –ipvs-scheduler=rr –masquerade-all=true –kubeconfig=/etc/kubernetes/kubeproxy-kubeconfig –hostname-override=172.21.128.111 –v=2 运行时：Docker version 18.06.3-ce, build d7080c1 排查过程 请详见tke团队roc的文章Kubernetes 疑难杂症排查分享: 诡异的 No route to host 其它找到的一些有用的文章 https://engineering.dollarshaveclub.com/kubernetes-fixing-delayed-service-endpoint-updates-fd4d0a31852c https://fuckcloudnative.io/posts/kubernetes-fixing-delayed-service-endpoint-updates/ 中文版本 五元组：源IP地址，源端口，目的IP地址，目的端口，和传输层协议这五个量组成的一个集合 终局 kube-proxy ipvs conn_reuse_mode setting causes errors with high load from single client #81775 该issue说明了最终的解决方案，是通过操作系统来解决的。2020年7月，我们将所有TKE集群的节点更换为“CentOS 7.6 64bit TKE-Optimized”后，没有再出现过问题。关于如何判定自己的内核有没有应用这个修订，issue中有说明。

我们在使用腾讯云容器服务(tke)的过程中，遭遇了kube-proxy的ipvs模式udp转发规则过期问题，过程记录。 环境 tke 1.12.4 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64 kube-proxy ipvs模式 /usr/bin/kube-proxy –proxy-mode=ipvs –ipvs-min-sync-period=1s –ipvs-sync-period=5s –ipvs-scheduler=rr –masquerade-all=true –kubeconfig=/etc/kubernetes/kubeproxy-kubeconfig –hostname-override=172.21.128.111 –v=2 运行时：Docker version 18.06.3-ce, build d7080c1 操作和现象 目标节点：172.21.128.109, 该节点有coredns, coredns的svc ClusterIP: 172.23.127.235。执行封锁后，执行drain操作。操作后的现象：业务大量报错“getaddrinfo failed: Name or service not known (10.010s)”,持续约8分钟. 和腾讯云的伙伴复盘时关注dns的变化.操作后会看到新的pod在172.21.128.111节点生成，在集群的任意节点上查看ipvs规则,发现tcp规则已更新成新podip，但udp规则还是老的podip。 # kubectl drain 172.21.128.109 # kubectl get pod -n kube-system -o wide|grep dns coredns-568cfc555b-4vdgk 1/1 Running 0 66s 172.23.3.41 172.21.128.111 <none> coredns-568cfc555b-7zkfz 1/1 Running 0 77d 172.23.0.144 172.21.128.10 <none> # ipvsadm -Ln|grep -A2 172.

下载和导入虚拟机. 下载 cdh-quickstart-vm 导入 vm初始信息收集 [cloudera@quickstart ~]$ uname -a Linux quickstart.cloudera 2.6.32-573.el6.x86_64 #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/issue CentOS release 6.7 (Final) Kernel \r on an \m vm里的cdh服务当前是使用操作系统的init系统管理的，而不是"Cloudera Manager" By default, the Cloudera QuickStart VM run Cloudera's Distribution including Apache Hadoop (CDH) under Linux's service and configuration management. If you wish to migrate to Cloudera Manager, you must run one of the following commands.

目标 概念 本地开发 本地环境(Mac OS X) 下载 export JAVA_HOME=$(/usr/libexec/java_home -v 1.8) export SPARK_HOME="$HOME/opt/spark-2.3.2-bin-hadoop2.6" export PYTHONPATH=$SPARK_HOME/python:$SPARK_HOME/python/lib/py4j-0.10.7-src.zip:$PYTHONPATH export PATH=$SPARK_HOME/bin:$PATH python环境 virtualenv -p python3 spark-python3 source spark-python3/bin/activate pip install pyspark deactivate(仅从当前venv环境脱离时执行) helloworld ./bin/spark-submit examples/src/main/python/wordcount.py README.md spark-shell IDE(PyCharm) 首选项-Project Interpreter helloworld解读 RDD partition 转换 行动 lazy evaluation shuffle 并行化 partition 与并发 worker,executor,task,job Spark Streaming, DStream socket ./bin/spark-submit examples/src/main/python/streaming/network_wordcount.py localhost 9999 web ui, http://localhost/4040 kafka https://search.maven.org/search?q=g:org.apache.spark%20AND%20v:2.3.2 , 放置于jars目录,或者在命令行指定 spark.io.compression.codec snappy (conf/spark-defaults.conf lz4依赖冲突,2.2.2没有此问题) 两种模式: receiver, direct .