There is a project migrated from legacy to GCP.
On GCP everything runs on microservices.
May be around 40-50 microservice.
I would like to automate this microservices but there is no endpoint exposed in this project.
How could you automate a microservice where there are no endpoints?
What type of architecture, you could use to test this?
Db: Firestore (nosql)
Thanks
M
In my view you can do it following way:
Use ClusterIP or NodePort to access those POD.
Spin up a new POD which will access your target POD to communicate.
You can enable POD to POD communication based on labels and enabling network policy.
You can use calico as network policy agent.
You can view the log of your testing pod using kubectl logs [pod name] or from logging service of your cloud provider or even using daemonset that you could install.
The testing POD can periodically send traffic. So you can use thread to call the target service and keep the thread in sleep mode for a while or you can use kubernetes cronjob to call the target service. Based on your usecase it will be chosen.
Let me know if it meets your requirements or you have more to elaborate?
In terms of finding out how to test your micro-services on the Google Cloud Platform, I would suggest referencing our documentation on "Microservices Architecture on Google App Engine" as it will explain and guild you how to implement your services onto GCP. You may also look into this document as well as it provides the best practices for designing APIs to communicate between microservices.
Additionally, user "ARINDAM BANERJEE" has a great example you can follow as well.
Related
I'm new to these both technologies but have trouble understanding what exactly do these two do different, a use case example will be very helpful.
AWS ECS is the container orchestration service that allows deployment, scale of the containers. Let's say you have 10 apps to be deployed on EC2 machines. ECS will provide you an easy way to deploy and manage them, scale the app when needed etc.
Now, these 10 apps might want to talk to each other. One way is to use the ip address and make an RPC call to the other application. However, this process doesn't scale. What if the machine is restarted or the app or the app is moved to another EC2 machine etc.
So, you require a middleware that manages the mapping of app to the EC2 machine so that the application doesn't need to bother about how to call the other application.
AWS AppMesh provides exactly that middleware. It provides an application level networking so that your service can communicate with other services.
ECS - Platform to run containers as task/service in a clustered manner.
when multiple containers are running in an ecs cluster they may want to talk with each other OR other aws services. These containers should know where other containers/services are by means of ip/endpoint..etc. That's where service discovery comes into picture.
Appmesh - Appmesh is a service discovery tool plus a lot more feature. One of them is to ensuring reliable communication between containers.
Appmesh uses envoy as sidecar in ecs to implement service discovery(plus many more) functionality.
Most of the time Appmesh is used in conjunction with Aws CloudMap.
Can we run an application that is configured to run on multi-node AWS EC2 K8s cluster using kops (project link) into local Kubernetes cluster (setup using kubeadm)?
My thinking is that if the application runs in k8s cluster based on AWS EC2 instances, it should also run in local k8s cluster as well. I am trying it locally for testing purposes.
Heres what I have tried so far but it is not working.
First I set up my local 2-node cluster using kubeadm
Then I modified the installation script of the project (link given above) by removing all the references to EC2 (as I am using local machines) and kops (particularly in their create_cluster.py script) state.
I have modified their application yaml files (app requirements) to meet my localsetup (2-node)
Unfortunately, although most of the application pods are created and in running state, some other application pods are unable to create and therefore, I am not being able to run the whole application on my local cluster.
I appreciate your help.
It is the beauty of Docker and Kubernetes. It helps to keep your development environment to match production. For simple applications, written without custom resources, you can deploy the same workload to any cluster running on any cloud provider.
However, the ability to deploy the same workload to different clusters depends on some factors, like,
How you manage authorization and authentication in your cluster? for example, IAM, IRSA..
Are you using any cloud native custom resources - ex, AWS ALBs used as LoadBalancer Services
Are you using any cloud native storage - ex, your pods rely on EFS/EBS volumes
Is your application cloud agonistic - ex using native technologies like Neptune
Can you mock cloud technologies in your local - ex. Using local stack to mock Kinesis, Dynamo
How you resolve DNS routes - ex, Say you are using RDS n AWS. You can access it using a route53 entry. In local you might be running a mysql instance and you need a DNS mechanism to discover that instance.
I did a google search and looked at the documentation of kOps. I could not find any info about how to deploy to local, and it only supports public cloud providers.
IMO, you need to figure out a way to set up your local EKS cluster, and if there are any usage of cloud native technologies, you need to figure out an alternative way about doing the same in your local.
The true answer, as Rajan Panneer Selvam said in his response, is that it depends, but I'd like to expand somewhat on his answer by saying that your application should run on any K8S cluster given that it provides the services that the application consumes. What you're doing is considered good practice to ensure that your application is portable, which is always a factor in non-trivial applications where simply upgrading a downstream service could be considered a change of environment/platform requiring portability (platform-independence).
To help you achieve this, you should be developing a 12-Factor Application (12-FA) or one of its more up-to-date derivatives (12-FA is getting a little dated now and many variations have been suggested, but mostly they're all good).
For example, if your application uses a database then it should use DB independent SQL or no-sql so that you can switch it out. In production, you may run on Oracle, but in your local environment you may use MySQL: your application should not care. The credentials and connection string should be passed to the application via the usual K8S techniques of secrets and config-maps to help you achieve this. And all logging should be sent to stdout (and stderr) so that you can use a log-shipping agent to send the logs somewhere more useful than a local filesystem.
If you run your app locally then you have to provide a surrogate for every 'platform' service that is provided in production, and this may mean switching out major components of what you consider to be your application but this is ok, it is meant to happen. You provide a platform that provides services to your application-layer. Switching from EC2 to local may mean reconfiguring the ingress controller to work without the ELB, or it may mean configuring kubernetes secrets to use local-storage for dev creds rather than AWS KMS. It may mean reconfiguring your persistent volume classes to use local storage rather than EBS. All of this is expected and right.
What you should not have to do is start editing microservices to work in the new environment. If you find yourself doing that then the application has made a factoring and layering error. Platform services should be provided to a set of microservices that use them, the microservices should not be aware of the implementation details of these services.
Of course, it is possible that you have some non-portable code in your system, for example, you may be using some Oracle-specific PL/SQL that can't be run elsewhere. This code should be extracted to config files and equivalents provided for each database you wish to run on. This isn't always possible, in which case you should abstract as much as possible into isolated services and you'll have to reimplement only those services on each new platform, which could still be time-consuming, but ultimately worth the effort for most non-trival systems.
I currently have a hosted (GCP) microservice environment that is under development. When working on a service I currently run the environment locally. I run all the services that the service I am working on needs to communicate to.
This provides a bad developer experience because:
I have to spin up every service; there can be a lot
running so many services can use a lot of my system resources
If any of those services need a DB, I have to set that up too
I'm looking for a soution to this. Idealy, I will run just the single service locally and connect to the rest of the services in the hosted environment.
Do any of the popular service meshes offer this as an option? I'm looking at Istio and Kuma primarily. Are there any alternatives solutions that come to mind?
For remote development/debugging I would suggest to have a look at Telepresence.
https://www.telepresence.io/
It is even recommended by Kubernetes docs:
Using telepresence allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster.
https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/
Istio on the other hand enables you to do shadow deployment and canary or blue/green deployment. You can e.g. run a service and send certain user (based on the header) to a new version. You can mirror traffic to a service or shift traffic from 0 to 100 % step by step. I'd say it's more for testing your new service under load or gradually releasing a new version.
Google Cloud Platform has made hybrid- and multi-cloud computing a reality through Anthos which is an open application modernization platform. How does Anthos work for distributed data platforms?
For example, I have my data in Teradata On-premise, AWS Redshift and Azure Snowflake. Can Anthos joins all datasets and allow users to query or perform reporting with low latency? What is the equivalent of GCP Anthos in AWS and Azure?
Your question is wide. Anthos is designed for managing and distributing container accross several K8S cluster.
For a simpler view, imagine this: you have the Anthos master, and its direct node are K8S masters. If you ask Anthos Master to deploy a pod on AWS for example. Anthos master forward the query to K8S master deployed on EKS, and your pod is deployed on AWS.
Now, rethink your question: what about the data? Nothing magic, if your data are shared across several clusters you have to federate them with a system designed for this. It's quite similar than with only one cluster and with data on different node.
Anyway, you point here the real next challenge of multi-cloud/hybrid deployment. Solutions will emerge from this empty space.
Finally your last point: Azure and AWS equivalent. There isn't.
The newest Azure ARC seems to be light: it only allow to manage VM out of Azure Platform with an agent on it. Nothing as manageable as Anthos. for example: You have 3 VM on GCP and you manage them with Azure ARC. You deployed on each an NGINX and you want to set up a loadbalancer in from of your 3 VM. I don't catch how you can do this with Azure ARC. With Anthos, it's simply a service exposition of K8S -> The Loadbalancer will be deployed according with the cloud platform implementation.
About AWS, outpost is an hardware solution: you have to buy AWS specific hardware and to plug it in your OnPrem infrastructure. Need more investment on prem in your move to cloud strategy? Hard to convince. And not compliant with other cloud provider. BUT ReInvent is coming next month. Maybe an outsider?
I started to learn about the implementation of Istio upon ｍｕｌti-clusters recently. There are two ways, one is using one control plane to monitor multi-clusters, the other one is deploying a control plane in each cluster and let them communicate with each other.
If I understand the concept of service registry correctly, it is used for service discovery in Istio. Is there anyway to check or monitor which services are registered in the service registry?
You can use:
istioctl proxy-status
check https://istio.io/docs/reference/commands/istioctl/#istioctl-proxy-status for more info