I am really interested about how google LB communicate with Serverless NEG pod, what does it have between them?
Related
I'm K8s newbie building 2 services, service A and service B, in a K8s cluster. Service A needs to call service B as part of service A's code. What are my options in terms of the API should I have for service B? Is a REST API, e.g., built using Python Flask, an option typically used for this kind of service-to-service communication within a K8s cluster? What other options do I have?
I have to following setup:
A VPC network V and a VPC Connector for V using CIDR range "10.8.0.0/28" (EDITED)
The following services A and B are connected to the VPC via the Connector
Cloud Run Service A: This service is set to ingress=internal to secure the API. Its egress is set to or private-ranges-only
Cloud Run Service B: This service provides an API for another Service C within the Azure Cloud. B also needs access to Service A's API. The egress and ingress are set to all to route all outgoing traffic through the VPC connector and allow for a successful request on internal Service A.
The current problem is the following: Requests from Service C -> Service B return in a 504 Gateway Timeout. If the egress of Service B is changed to private-ranges-only the request of Service C succeeds but in return all requests of B -> A return 403 Forbidden since traffic is no longer routed through the VPC Connector because Cloud Run does not allow for private-ranges to send traffic to Service A(afaik). All requests of Cloud Run Services to other Cloud Run Services are currently issued to "*.run.app" URLs.
I can not come up with an idea for a possible and convenient fix for this setup. Is there an explanation why egress=all in Service B results in a Gateway Timeout of requests from Service C. I tried to follow logs from the VPC but did not see any causes.
The following changes were necessary to make it run:
Follow this guide to create a static outbound ip for Service B
Remove previous created VPC Connector (created with CIDR range not subnet as in guide)
Update Cloud Run Service B to use VPC Connector created during Step 1
Since removing the static outbound ip is breaking the setup, I assume the azure service demands a static ip to communicate with.
I have a K8s cluster that should whitelist a Cloud Run server, so I would like to know the IP address or IP range of the Cloud Run server.
As found here:
https://github.com/ahmetb/cloud-run-faq#is-there-a-way-to-get-static-ip-for-outbound-requests
Is there a way to get static IP for outbound requests?
Currently not, since Cloud Run uses a dynamic serverless machine pool by Google and its IP addresses cannot be controlled by Cloud Run users.
However, there is a workaround to route the traffic through a Google Compute Engine instance by running a persistent SSH tunnel inside the container and making your applications use it.
I have a question regarding Kubernetes networking.
I know that in Docker swarm if I want to run difference containers on difference servers, I need to create an overlay network, and then all the containers (from all the servers) will be attached to this network and they can communicate with each other (for example, I can ping from container A to container B).
I guess that in Kubernetes there isn't an overlay network - but another solution. For example, I would like to create 2 linux containers on 2 servers (server 1: ubuntu, server 2: centos7), so how do the pods communicate with each other if there isn't an overlay network?
And another doubt - can I create a cluster which consists of windows and linux machines with kubernetes?I mean, a multi platform kubernetes which all the pods communicate with each other.
Thanks a lot!!
In kubernetes, pods communicate with each other through service. To access any pod within cluster, it must be exposed using clusterIP service. So if you created service before creating pods, you will have env variable for each available service within container. Using that you can ping or access services and in turn pods.
For example:
Suppose you have two pods U1 and C1 and those are exposed by service named U-SVC and C-SVC respectively.
So if you want to access C1 from U1, you will have C-SVC service env variables(C-SVC_SERVICE_HOST,C-SVC_SERVICE_PORT) within container which you can use for access.
Also if DNS server set for your cluster, you can access service without env varibles.
we built a Docker Swarm cluster, over several cloud providers.
Everything works but we have new constraints and need to restrict network communications between the cloud providers.
Is it possible to build a Docker Swarm cluster with "local load balancing"? What I mean by this question is, is it possible to use:
- one cloud provider for Swarm managers, with network access to Swarm workers;
- two cloud providers for Swarm workers, with network access to the Swarm managers, but no network access between these cloud providers?
In that case, would the load balancing still work if someone runs a web request towards one of the workers?
Please find below a drawing of the targeted architecture.