使用Istio 1.9.2
kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-d0 Ready control-plane,master 7d2h v1.20.5
k8s-d1 Ready <none> 7d2h v1.20.5
k8s-d2 Ready <none> 7d2h v1.20.5
kubectl get pods -n istio-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
istio-egressgateway-54658cd5f5-thj76 1/1 Running 0 7m6s 10.244.1.44 k8s-d1 <none> <none>
istio-ingressgateway-7cc49dcd99-tfkgs 1/1 Running 0 7m6s 10.244.1.43 k8s-d1 <none> <none>
istiod-db9f9f86-j2mjv 1/1 Running 0 7m10s 10.244.2.100 k8s-d2 <none> <none>
kubectl get pods -n sauron--desenvolvimento -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sauron-66dc8ff67d-kgsk2 1/2 Running 0 49s 10.244.2.101 k8s-d2 <none> <none>
sauron-66dc8ff67d-rs8lv 2/2 Running 0 5m27s 10.244.1.46 k8s-d1 <none> <none>
kubectl get services -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-egressgateway ClusterIP 10.99.11.179 <none> 80/TCP,443/TCP,15443/TCP 9m12s
istio-ingressgateway LoadBalancer 10.100.239.142 <pending> 15021:30460/TCP,80:30453/TCP,443:31822/TCP,15012:30062/TCP,15443:31932/TCP 9m12s
istiod ClusterIP 10.104.84.82 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 9m16s
当Kubernetes决定在不同于istio-Ingres gateway节点的节点上部署(envoy injected)pod时,envoy sidecar抛出以下错误,并且pod仍然不正常(就绪探测失败:Get " http://10 . 244 . 2 . 101:15021/healthz/ready ":dial TCP 10 . 244 . 2 . 101:15021:connect:connection denied):
2021-04-13T17:19:31.674447Z warn ca ca request failed, starting attempt 1 in 101.413465ms
2021-04-13T17:19:31.776221Z warn ca ca request failed, starting attempt 2 in 214.499657ms
2021-04-13T17:19:31.799366Z warning envoy config StreamAggregatedResources gRPC config stream closed: 14, connection error: desc = "transport: Error while dialing dial tcp 10.104.84.82:15012: i/o timeout"
2021-04-13T17:19:31.991122Z warn ca ca request failed, starting attempt 3 in 383.449139ms
2021-04-13T17:19:32.375004Z warn ca ca request failed, starting attempt 4 in 724.528493ms
2021-04-13T17:19:43.196955Z warn Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2021-04-13T17:19:45.195718Z warn Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2021-04-13T17:19:47.194598Z warn Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2021-04-13T17:19:49.194990Z warn Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2021-04-13T17:19:51.195400Z warn Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2021-04-13T17:19:52.214848Z warning envoy config StreamAggregatedResources gRPC config stream closed: 14, connection error: desc = "transport: Error while dialing dial tcp 10.104.84.82:15012: i/o timeout"
2021-04-13T17:19:52.674981Z warn sds failed to warm certificate: failed to generate workload certificate: create certificate: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.104.84.82:15012: i/o timeout"
2021-04-13T17:19:53.195269Z warn Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
登录到我的pod bash并执行curl,连接被拒绝:
curl 10.104.84.82:15012
curl: (7) Failed to connect to 10.104.84.82 port 15012: Connection refused
我发现问题出在istio-Ingres gateway没有外部ip的服务上。在用下面的命令设置之后,它工作得很好:
kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"externalIPs":["__YOUR_IP__"]}}'
注意:本文档已失效,请浏览 Istio 官方文档。本书中的 Service Mesh 章节已不再维护,请转到 istio-handbook 中浏览。 我们知道 Istio 通过向 Pod 中注入一个 sidecar 容器来将 Pod 纳入到 Istio service mesh 中的,那么这些 sidecar 容器的注入遵循什么样的规范,需要给每个 Pod 增加哪些配置信息才能纳入 Istio s
注意:Istio 1.10于2018年8月1日发布1.0,关于Istio的更多信息请见Istio官方文档:https://istio.io,中文版:https://istio.io/zh,本书中的 Service Mesh 章节已不再维护,请转到 istio-handbook 中浏览。 Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语,意思是”起航“
Istio 是一个由谷歌、IBM 与 Lyft 共同开发的开源项目,旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。Istio 项目能够为微服务架构提供流量管理机制,同时亦为其它增值功能(包括安全性、监控、路由、连接管理与策略等)创造了基础。这款软件利用久经考验的 Lyft Envoy 代理进行构建,可在无需对应用程序代码作出任何发动的前提下实现可视性与控制能力。Istio 项目是一款强
2.)我已经通过在kubernetes中创建LoadBalancer类型的服务向外部世界公开了我的REACT应用程序,并且我能够从浏览器访问REACT应用程序endpoint。现在,是否可以从节点内部的REACT应用程序访问EXPRESS应用程序而不向外部世界公开我的EXPRESS应用程序?如何实现这一点? 提前谢了。
问题内容: 我已经为kubernetes中的front(REACT)和backend(EXPRESS NODE JS)项目泊坞窗并创建了部署和服务。我已经在Google Cloud Platform中的两个 Pod (即 一个 Pod- > REACT APP和SECOND POD-> EXPRESS NODE JS )的同一节点的Kubernetes(单节点集群)中成功部署了。 题: 1.)如何
注意:本书中的 Service Mesh 章节已不再维护,请转到 istio-handbook 中浏览。 在讲解 Istio 如何将 Envoy 代理注入到应用程序 Pod 中之前,我们需要先了解以下几个概念: Sidecar 模式:容器应用模式之一,Service Mesh 架构的一种实现方式。 Init 容器:Pod 中的一种专用的容器,在应用程序容器启动之前运行,用来包含一些应用镜像中不存在