Tejas Jain

Kubernetes (K8s) is an open-source container-orchestration platform for automating application deployment, management and scaling. Concepts 1. Kubernetes uses the concepts of pods - an object that consists of one or more containers which share network namespace 2. Kubernetes automates deploying, scaling and managing containerized application on a group (cluster) of (bare metal or virtual) servers, such as ensuring that in case a container within a pod crashes, it will be restarted. Use case: A developer needs 5 application containers on a host. The way he can do it using docker is type the command: "docker run <application_name>" individually 5 times, to create 5 containers on the host machine. What if a production environment requires 200 containers? If you have an automation script that does run the above command 200 times to create 200 containers, how do you monitor them? How do you ensure the underlying host resources aren't stretched or depleted? K8s to the res

Container = Namespaces + CGroups + Layered Filesystem Namespaces A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace but are invisible to other processes. Namespaces limit how much you can see and therefore use: 1. PID 2. Network 3. UTS 4. Mount 5. IPC 6. User CGroups (Control Groups) Control groups are a Linux kernel feature which allows processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. CGroups limit how much you can use: 1. CPU 2. Memory Layered Filesystem Different files and directory structures are layered in order and on top of each other to be reflected as one directory tree.      Layered Filesystem allows reuse and push/pull deltas. It's an advanced multilayered unificati

1.  Google Cloud Interconnect Security Cloud Interconnect does not encrypt the connection between your on-premises network and Google's network. Cloud VPN cannot be used with Dedicated Interconnect For additional security, use application-level encryption or your own VPN 2. While using Cloud CDN, the default time-to-live (TTL) for content caching is 3600 seconds = 60 mins 3. Cloud NAT sends only the translation logs and error logs to Cloud Logging service. 4. GCP Dedicated Interconnect - On Premises network device requirements:     10-Gbps circuits, single mode fiber or 100-Gbps circuits, single mode fiber     IPv4 link local addressing     LACP, even if you are using single circuit     EBGP-4 with multi-hop     802.1Q VLANs 5. While using Cloud VPN, the recommended MTU to be configured on the peer VPN  gateway = 1460 bytes 6. Each instance must have at least one network interface. The maximum number of network instances per instance is 8, depending on the instance's machine

Virtual Private Cloud (VPC) VPC Networks Global resources (not associated with any zone) and include subnets, routes and firewall rules VPC Networks do not have any IP addresses associated with them (unlike AWS) Resources within a VPC can communicate with one another using the internal IP addresses By default, resources in two different VPCs cannot communicate with each other. The communication can be facilitated by VPC Network Peering VPC networks support IPv4 unicast traffic only. They do not support broadcast, multicast or IPv6 traffic within the network   VPC Subnets Subnets represent VPC Network partitions using one or more useful IP address ranges Subnets are regional resources. Each subnet comprises of a range of IP addresses. These can be primary IP ranges or secondary IP ranges (alias) A network must have at least one subnet before it can be used More than one subnet per region can be created VPC Network supports following modes of subnet creation:     Auto Mode VPC networks

Google Cloud Network Constructs VPC VPC Routes Firewall Rules VPC Peering Shared VPC Internal and External IPs Static and Ephemeral IPs VPC Subnets Private Access  VPC Flow Logs Hybrid Connectivity Cloud VPN Cloud Interconnect Cloud Router Cloud NAT Cloud Peering Cloud Load Balancing Cloud CDN Cloud DNS

AWS Organizational Hierarchy AWS Organizations "must" be the starting point of your AWS deployment. (unless you are absolutely sure that it won't scale.. highly unlikely!!) An AWS Organization comprises of multiple "Organizational Units (OUs)". OUs comprise of other OUs or member "AWS Accounts".  Image credits : Here Tip : Design the OUs such that they complement with your organizational hierarchy and businesses and sub-divisions. For eg.  Company XYZ maps to an AWS Organization,     --  Finance maps an OU,         --   Investment Banking within Finance maps to a sub-OU               -- Investment Banking Prod environment maps to an AWS Account               -- Investment Banking Non-Prod environment gets another AWS Account               -- Investment Banking Dev environment gets another AWS Account        --   Fixed Income within Finance maps to another sub-OU       --    Retail within Finance maps to another sub-OU          and so on...   OUs insid

Google Cloud Armor is Google's Network Security service that provides protection against DDoS and web application based attacks. If you have been thinking about enabling Google Cloud Armor for leveraging its DDoS protection and WAF capabilities, you must know the following restrictions: 1. Cloud Armor cannot be enabled on non-HTTP Load balancers. 2. If your HTTP load balancers have Cloud CDN enabled on them, then you cannot enable Cloud Armor on them.       3. If your HTTP Load Balancer has backend buckets instead of backend services, you cannot enable Cloud Armor. This is evident in the below snapshot, where the only option you get is to enable Armor for "Load Balancer backend service". The above restriction is also mentioned in the official GCP document. Click here :  Cloud Armor Limitations . Summary: You can enable Cloud Armor only on HTTP load balancers which have backend services (not buckets) as the backend resources.