问题标签 [istio-sidecar]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
istio - 来自 Sidecar 代理的 TLS 发起失败并出现错误 [TLS 错误:268436576:SSL 例程:OPENSSL_internal:]
我正在尝试直接从 sidecar 代理容器启动 mTLS 连接到外部服务,而无需任何出口网关。
我当前的配置如下所示。如您所见,在联系外部服务之前,我正在尝试使用客户端证书将 http 请求升级为 https。
不确定我的配置是否正确。
从容器中,我尝试使用 http 访问服务,但得到 503。在进一步检查 sidecar 代理日志时,我看到 OpenSSL 内部错误,但没有任何原因。想知道这里出了什么问题或被遗漏了。
任何指针都会非常有帮助。
谢谢
spring-boot - 在 istio sidecar 代理下运行的 Spring-boot 抛出 HTTP 403 错误
在同一个命名空间下部署了 ServiceA 和 ServiceB 服务。启用了 istio 来验证请求身份验证。对服务的任何调用都需要具有带有有效 jwt 令牌的“Authrization”标头。它通过RequestAuthenication和AuthorizationPolicy集进行验证。它按预期工作,我可以使用有效的身份验证令牌进行 http 调用。现在 ServiceA 需要与 ServiceB 对话。我使用了 service-name serviceb..<namespace-name>.svc.cluster.local
。调用已传递给 ServiceB,但由于 HTTP 403 失败。它需要 auth 令牌标头。如何在没有身份验证令牌的情况下允许同一命名空间内的服务之间的调用?我正在尝试找到一个示例来自定义AuthorizationPolicy, 以便它允许在与受信任服务相同的命名空间中调用而无需身份验证令牌。请让我知道,是否有可能或是否有替代方法。
我在服务下运行的所有 pod 都是 spring-boot 并使用 RestTemplate 在服务之间调用。
以下是使用的 istio 身份验证策略
istio - Istio 一直使用已删除的 pod IP
我们正在使用 Istio 1.8.1 并已开始使用无头服务来获得使用 Istio mTLS 的直接 pod 到 pod 通信。这一切都很好,但我们最近注意到,有时在杀死我们的一个 pod 后,我们会在很长一段时间内(很多分钟)得到 503 没有健康的上游错误。如果我们回到“正常”服务,我们会收到一些 503 错误,然后问题很快得到解决(但我们无法将请求定向到我们需要做的特定 pod)。
我们使用 kubectl sniff 跟踪了 envoy 容器的通信,可以看到在 pod 被杀死后,现有连接会保持很长一段时间,甚至还会尝试与之前杀死的 pod IP 建立新连接。
我们对相关服务的目标规则进行了断路器配置,但这似乎也没有帮助。我们还尝试设置“PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES”,这似乎改善了 503 错误情况,但奇怪的是干扰了 pod 到 pod 的直接 IP 配置。
有人对我们收到 503 错误的原因或如何避免它们有任何建议吗?
kubernetes - Istio 排除匹配不适用于没有 jwt 主体的 healthz api
我的 RequestAuthentication 是这个
我的 AuthorizationPolicy 是这个
我的要求是我不希望 jwt auth 检查 healthz(我的情况是 /message/ping),但我总是得到 上面的响应是“RBAC:访问被拒绝”
kubernetes - Istio 排除政策
有人可以解释一下这项政策的含义吗,我已经尝试了一整天,但没有以正确的方式进行
请求请提及命名空间相关性。提前致谢。
jenkins - 无法 curl 以保护来自本地 minikube 集群的 HTTP
所以我有minikube 0.16.0 installed
还istio 1.7.3
因此,根据命令,我在每次部署时都使用特使边车kubectl label namespace default istio-injection=enabled
现在,谈到这个问题,我无法curl
从任何 pod 内部执行任何操作,即使从sleep-diag
,我总是会收到 request timed out 消息,但它确实适用于非安全http
例如,在安装时jenkins
,我试图curl
反对这个url
但没有成功:
但即使我尝试让我们说:
虽然我可以pod
在本地集群之外,但对此有什么想法吗?
例如,尝试jenkins
像这样安装,使用helm
:
显然它会失败,因为我无法https
从本地集群访问任何内容,即使指定NodePort
我有同样的问题:
有任何想法吗?
kubernetes - Istio 和 Hashicorpt Vault 代理 Sidecar 无法正常工作
我正在使用本地 k8s v1.19 和带有 1.8.0 的 Istio。当我将 istio 网格注入到hub-dev
我们的微服务运行的位置时,我被困在正确地一起运行它们。Vault 正在运行dev
命名空间。
我遇到的第一个问题是 Vault 和 Istio sidecar 无法以某种方式正常运行,应用程序无法按如下方式初始化。我尝试使用下面的注释来初始化第一个保管库,但它没有解决下面的问题。
- vault.hashicorp.com/agent-init-first:真
- vault.hashicorp.com/agent-inject:真
这是 pod status 的输出并描述
当我尝试下面的注释时,它解决了上述问题,但是这次当 pod 开始运行时,它无法找到/vault/secrets
路径,但不知何故,当我检查代理和应用程序的日志时,它可以被读取,并且/vault/secrets
文件夹存在于 pod 中.
即使文件夹存在,这里也是应用程序的日志
在这里,我有一些可能与保险柜本身有关的 PUT 错误,但我很困惑保险柜如何注入机密。
最后,当我检查 istio-proxy 日志时,我可以看到 GET 或 PUT 请求返回 200。
envoyproxy - lua envoyFilter 在 istio-sidecar 中被忽略
我正在尝试使 envoyFilter 在 istio-sidecar 中工作。
看起来 :
- 发生注射。由于我的过滤器存在于集群的资源中,并且每当我更新过滤器时,istiod 都会推送到我的边车。(而且我的 pod 和我的过滤器在同一个命名空间中)
- 我用来选择的标签出现在 pod 上。
但是我的脚本完全被忽略了。请问,我错过了什么?
PS:我从特使的 ref 那里得到了 lua:
- https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/lua_filter.html?highlight=request_handle#configuration
- https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/lua_filter#respond
编辑:好吧,我们无法让它工作并切换到 Nginx。最近的一项功能可以完成工作。
istio - 禁用向作业 pod 注入 Istio sidecar
如何为 Kubernetes 禁用 Istio sidecar 注入Job
?
Sidecar 仍然被注入。
prometheus - 由于 Istio-sidecar 路由失败,无法从 Prometheus 访问 Alertmanagers Endpoint
设置: 我有一个小型 aws k8s 集群,其中基础设施组件部署为 helm 图表。其中一个组件是令人敬畏的 Prometheus 图表(请参见此处)。组件之间的网络通信应该使用 Istio Service Mesh 进行配置。
问题: Prometheus 找到 k8s 服务的kube-prometheus-alertmanager的单个端点,然后根据端点的 IP 地址不断尝试与它通信,而不是将其引用为“kube-prometheus-alertmanager..svc.cluster”。本地”主机。
由于同一节点上的 istio sidecar 并不真正知道 IP,但为 kube-prometheus-alertmanager..svc.cluster.local 主机定义了出站路由,因此它找不到对应的路由并一直告诉 prometheus 容器因为可以找到对应的路由,所以只能提供 404 HTTP 响应。因此,在 prometheus POD 的 istio-proxy sidecar 容器中,我们看到如下行:
其中 404 NR "-" 清楚地表示边车容器在路由请求时遇到的问题。
Wish: 很高兴听到让 Prometheus 使用 Endpoints 的最佳策略,但要与 Istio 成为朋友。
提前致谢!