HTTP load balancer in GCP has lot of moving parts like global forwarding rules, target proxies, URL map, backend services and instance groups.
Since I found difficult in setting up my HTTP load balancer, I have written the below answer that aggregates the steps for setting up HTTP load balancer in GCP.
This question is a part of another question's answer, which is about building an autoscaled and load-balanced backend.
At first, GCP offers two types of load balancer, namely the Network and HTTP(s) load balancers. You can find the differences between Network Vs HTTP(s) load balancer here. From this point, I will be calling HTTP load balancer as HLB(coz it is too long).
Here is the architecture of HLB taken from GCP:
As you have seen from the above architecture, there are lot of moving parts for setting up the HLB. Now, We are going to build it from backwards starting from Instance template, Instance group to Forwarding rules.
1. Instance Template: Though instance template is not needed to set up HLB, as you can use even unmanaged instance group and attach it with HLB. I prefer having an instance template and managed instance group, so that autoscaling feature can also be added for the group of homogeneous instances. I have written the steps for creating an instance template here.
Lets assume the instance template to be sample-template.
2. Managed Instance Group: Please go through the steps for creating managed instance group and autoscaling here. Autoscaling and load balancing are independent of each other. Both offers health check. From my perspective, setting up the health check for both load balancer and autoscaling are redundant and I think health check for load balancer alone would do good.
Lets assume the managed instance group to be autoscale-managed-instance group, which is autoscaled and created based on sample-template.
3. service Endpoint: You need to specify the service endpoint which will be used by the HLB. The command for setting up the service endpoint in gcloud:
gcloud compute instance-groups managed \
set-named-ports \
autoscale-managed-instance group \
--named-ports http:80 \
--region asia-northeast1
The above command creates a service endpoint in the instance group that helps the HLB to communicate with the homogeneous instances in the group.
4. Health Check: This is essential so as to assure that HLB routes traffic only to healthy instances. The command to create the health check:
gcloud compute http-health-checks create sample-health-check
5. Backend services: This service routes the traffic to all the backend instances i.e instances in the instance group. It also associates the health check of the instances and make sure it routes traffic only to healthy instances. The command for creating the backend service:
gcloud compute backend-services create \
sample-backend-service \
--http-health-checks sample-health-check
The above command creates a backend service and associates itself to the health check created at the previous step. Now, adding the instance group to the backend service by running the following command:
gcloud compute backend-services add-backend sample-backend-service \
--instance-group \
sample-managed-instance-group \
--balancing-mode RATE \
--max-rate-per-instance 100 \
--instance-group-region asia-northeast1
The above command attaches the instance group to backend-service and also spread the load based on the number of requests using the balancing-mode flag. max-rate-per-instance is used by the autoscaler, if you had set the autoscaler policy based on load balancer utilisation.
6. URL map: Creating a URL map that maps the HTTP request URL to your backend service. The command for creating the URL map:
gcloud compute url-maps create sample-map \
--default-service sample-backend-service
When you choose Content-based load balancer, you need to add many entries in URL maps, so that it routes the request to appropriate backend service.
7. Target HTTP proxy: This step associates the target proxy to the URL map. The command for creating target HTTP proxy:
gcloud compute target-http-proxies \
create sample-target-proxy \
--url-map sample-map
8. Forwarding rules: This is the final step which gives an global external IP address to the HLB.
gcloud compute forwarding-rules \
create sample-forward \
--global \
--ports 80 \
--target-http-proxy sample-target-proxy
Now, accessing the HLB's IP address in the browser gives the web page served by instances in the instance group. This finally sets up an Highly scalable web application which is both autoscaled and load balanced.
This is part 3 of 3-part series about building an autoscaled, load-balanced backend.
Related
I'm new to aws so forgive me if the question is trivial.
I have a Cluster running a single fargate service with two tasks that is hosting my internal api service. I can access the api via the main level and everything works.
https://<serviceid>.execute-api.us-east-1.amazonaws.com/lookupx will return the lookupx result from one of two tasks as determined by the load balancer.
I would like to get the result from each task. I know the ein for each task and I know the private IPs.
What do I need to do in in order to access a specific task in a call?
Why do I care? The service reads 40+ files from s3 at startup into memory and provides an endpoint to lookup a value and return corresponding data. I'd like to add an endpoint to reload a file on demand, but I need to make sure both tasks get updated. Not my design and I do not have time and budget to rebuild. Just looking for a better solution than restarting the tasks, reloading all 40+ files, just to update one. Wasn't bad with weekly updates, kinda sucks with daily updates.
Please notice private IP can change after task is restarted.
You can run extra scheduled/on demand task with the same or different task definition to find the service via AWS API, get its current tasks and their IPs and then call your API for all of them.
the script can be bash or any other supported language
https://aws.amazon.com/developer/tools/
with bash
you can list all service tasks:
aws ecs list-tasks --cluster <clusterName> --service <serviceName>
and their ip:
aws ecs describe-tasks --cluster <clusterName> --tasks <taskARN1 taskARN2> --query 'tasks[].attachments[].details[?name==`privateIPv4Address`].value[]'
I have done the below steps.
Created an EKS Cluster
Installed aws-iam-authenticator client binary
Execute "aws eks update-kubeconfig --name <cluster_name>"
Execute "kubectl get svc"
I am able to view the services available in my cluster. When I see ~/.kube/config file it is using an external command called "aws-iam-authenticator".
My understanding is that "aws-iam-authenticator" uses my ~/.aws/credentials and retrieves the token from AWS(aws-iam-authenticator token -i cluster-1) and uses that token for "kubectl get svc" command. Is my understanding correct?
If my understanding correct, where does heptio comes into picture in this flow? Does Heptio Authenticator be deployed automatically when creating the EKS Cluster?
Basically, Heptio authenticator = aws-iam-authenticator.
You can check the details on here. If your aws-iam-authenticator is working fine, then you don't need to care about heptio additionally. They just renamed it.
Am facing 2 issues with Spinnaker new installation.
I could not see my Application load balancers listed in dropdown of load balancers tab while creating pipeline. We are currently using only app. load balancers in our current set up. I tried editing the JSON file of pipeline with below config and it didn't work. I verfied it by checking the ASG created in my AWS account and checked if there is any ELB/Target group associated but I couldn't see any.
"targetGroups": [
"TG-APP-ELB-NAME-DEV"
],
Hence, I would like to confirm how I can get support of App. ELB into Spinnaker installation and how to use it.
Also I have an ami search issue found.My current set up briefing is below.
One managing account - prod where my spinnaker ec2 is running & my prod application instances are running
Two managed accounts - dev & test where my application test instances are running.
When I create a new AMI in my dev AWS account and am trying to search the newly created AMI from my Spinnaker and it failed with error that it couldn't search the AMI first. Then I shared my AMI in dev to prod after which it was able to search it but failed with UnAuthorized error
Please help me clarify
1. If sharing is required for any new AMI from dev -> Prod or our spinnakerManaged role would take care of permissions
2. How to fix this problem and create AMI successfully.
Regarding #1, have you created the App Load Balancer through the Spinnaker UI or directly through AWS?
If it is the former, then make sure it follows the naming convention agreed by Spinnaker (I believe the balancer name should start with the app name)
I'm pretty new to Kubernetes and clusters so this might be very simple.
I set up a Kubernetes cluster with 5 nodes using kubeadm following this guide. I got some issues but it all worked in the end. So now I want to install the Web UI (Dashboard). To do so I need to set up authentication:
Please note, this works only if the apiserver is set up to allow authentication with username and password. This is not currently the case with the some setup tools (e.g., kubeadm). Refer to the authentication admin documentation for information on how to configure authentication manually.
So I got to read authentication page of the documentation. And I decided I want to add authentication via a Static Password File. To do so I have to append the option --basic-auth-file=SOMEFILE to the Api server.
When I do ps -aux | grep kube-apiserver this is the result, so it is already running. (which makes sense because I use it when calling kubectl)
kube-apiserver
--insecure-bind-address=127.0.0.1
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota
--service-cluster-ip-range=10.96.0.0/12
--service-account-key-file=/etc/kubernetes/pki/apiserver-key.pem
--client-ca-file=/etc/kubernetes/pki/ca.pem
--tls-cert-file=/etc/kubernetes/pki/apiserver.pem
--tls-private-key-file=/etc/kubernetes/pki/apiserver-key.pem
--token-auth-file=/etc/kubernetes/pki/tokens.csv
--secure-port=6443
--allow-privileged
--advertise-address=192.168.1.137
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
--anonymous-auth=false
--etcd-servers=http://127.0.0.1:2379
Couple of questions I have:
So where are all these options set?
Can i just kill this process and restart it with the option I need?
Will it be started when I reboot the system?
in /etc/kubernetes/manifests is a file called kube-apiserver.json. This is a JSON file and contains all the option you can set. I've appended the --basic-auth-file=SOMEFILE and rebooted the system (right after the change of the file kubectl wasn't working anymore and the API was shutdown)
After a reboot the whole system was working again.
Update
I didn't manage to run the dashboard using this. What I did in the end was installing the dashboard on the cluster. copying the keys from the master node (/etc/kubernetes/admin.conf) to my laptop and did kubectl proxy to proxy the traffic of the dashboard to my local machine. Now I can access it on my laptop through 127.0.0.1:8001/ui
I just found this for a similar use case and the API server was crashing after adding an Option with a file path.
I was able to solve it and maybe this helps others as well:
As described in https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/#constants-and-well-known-values-and-paths the files in /etc/kubernetes/manifests are static pod definitions. Therefore container rules apply.
So if you add an option with a file path, make sure you make it available to the pod with a hostPath volume.
I have used AWS Community AMI for configuring Spinnaker. I am able to get the lists of ELB, AMI and Security Groups while creating Server Group. But, I am not getting the Instance types in the custom drop down list. Any idea about what could be going wrong?
Spinnaker Cluster Error
It looks like you are not having a correct IAM role assigned to the user whose access keys you are using for the spinnaker integration with AWS.
Mostly if you used the spinnaker.Check if you have enough rights in AWS.
If not then create a role and assign AWS POWER USER ACCESS to your user and then try to get the integration .
Spinnaker is a tool which would need AWS EC2 Full access atleast as it directly access EC2 spin up its server groups.
Instance types are cached in the browser's local storage. You can explicitly refresh the cache via the 'Refresh all caches' link:
If you show the network tab of your browser's console (prior to clicking 'Refresh all caches'), you should see a request to http://localhost:8084/instanceTypes.
If the response contains your instance types, you should be good to go.