RSInfoMinds

  If you are preparing for AWS Cloud Practitioner please have a look at the below notes which is more than enough to pass the exam. AWS Personal Health Dashboard provides alerts and remediation guidance when AWS is experiencing events that may impact you. Amazon Aurora is a global-scale relational database service built for the cloud with full MySQL and PostgreSQL compatibility. Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation. Amazon SageMaker provides a suite of built-in algorithms, pre-trained models, and pre-built solution templates to help data scientists and machine learning practitioners get started on training and deploying machine learning models quickly.  AWS Application Discovery Service helps you plan your migration to the AWS cloud by collecting usage and configuration data about your on-premises servers. AWS CloudW...

  A PersistentVolume (PV) in Kubernetes is a pool of pre-provisioned storage resources in a Kubernetes cluster, that can be used across different user environments.  Its lifecycle is separate from a Pod that uses the PersistentVolume. A PersistentVolumeClaim (PVC), is a process of storage requests from PVs by the users in Kubernetes. Kubernetes binds PVs with the PVCs based on the request and property set on those PVs. Kubernetes searches for PVs that correspond to the PVCs’ requested capacity and specified properties, so that each PVC can bind to a single PV.  NOTE: Both the PVCs and the Pod using them must be in the same namespace. PVs are created by the cluster administrator or dynamically by Kubernetes, whereas users/developers create PVCs. PVs are cluster resources provisioned by an administrator, whereas PVCs are a user’s request for storage and resources.  PVCs consume PVs resources, but not vice versa. A PV is similar to a node in terms of cluster resources, ...

  1) Introduction to Docker Containers. 2) Installation of K8s Cluster. 3) Lifecycle of Pod. 4) Deployment and strategies. 5) Cluster Upgrade and worker node management. 6) Labels and Selectors. 7) K8s Service Management. 8) Priority and Preemptions. 9) Network Policies. 10) Volumes. 11) Secrets and ConfigMaps. 12) Horizontal Pod Autoscaling. 13) Namespace and Contexts. 14) Metric Server Configuration. 15) Cluster Access and Role Binding. 16) Web UI Setup. 17) Drain/Taint Nodes. 18) Jobs and Cron. 19) Init and Sidecar containers. 20) ETC Management. 21) Pod Resource Management. 22)  Kubernetes Liveness and Readiness Probes. 23) Ingrees controllers.

  1) SDLC Automation. 2) Cloud Formation. 3) Monitoring and Logging. 4) Elastic Beanstalk. 5) Lambda. 6) API Gateway. 7) ECS. 8) ECS - CodePipeline CICD. 9) OpsWorks. 10) CloudTrail & CloudWatch. 11) SSM, Config, Serivce Catalog, Inspector, Trusted Advisor. GuardDuty. 12) ASG.

  1) Introduction to AWS. 2) EC2 Fundamentals. 3) EC2 Instance Storage. 4) High Availability and Scalability - ELB + ASG. 5) Route 53. 6) Amazon S3. 7) IAM Roles and Policies. 8) Advanced Amazon S3. 9) Amazon S3 Security. 10) CloudFront and AWS Global Accelerator. 11) Decoupling Applications - SQS, SNS, Kinesis, Active MQ. 12) Networking - VPC 13) CloudWatch and CloudTrail.  14) Data & Analytics. 15) Serverless Solutions. 16) Introduction to RDS, Aurora and ElastiCache.  

  What is canary ? Testing out a new feature or upgrade in production is a stressful process.  You want to roll out changes frequently but without affecting the user experience.  To minimize downtime during this phase, set up canary deployments to streamline the transition. When you add the canary deployment to a Kubernetes cluster, it is managed by a service through selectors and labels. The service routes traffic to the pods that have the specified label.  This allows you to add or remove deployments easily. The amount of traffic that the canary gets corresponds to the number of pods it spins up.  I am going to create a nginx deloyment with the below specification: 1) Nginx image version 1.14.2. 2) Deployment with the labels:  app: nginx and version: "1.0" 3) Replicas 3. 4) Updating HTML content as "I am on POD V.10" apiVersion: apps/v1 kind: Deployment metadata:  name: nginx spec:  selector:   matchLabels:    app: nginx ...

  Below post is all about a request from a colleague. 1) There are 20 microservices. 2) All the microservices use a single configmap. 3) Change made to configmap should reflect in the microservices. 4) Microservices can also update the configmap as part of the deployment. In this exampled, I am using nginx and redis deployment sharing a configmap. First creating a configmap from a file: root@masterk8s:/docker# cat cm.txt app1=nginx app2=redis app3=memcached root@masterk8s:/docker# root@masterk8s:/docker# kubectl create configmap app-cm --from-file=cm.txt configmap/app-cm created root@masterk8s:/docker# root@masterk8s:/docker# kubectl get configmap app-cm NAME     DATA   AGE app-cm   1      22s root@masterk8s:/docker# root@masterk8s:/docker# kubectl describe cm app-cm Name:         app-cm Namespace:    default Labels:       <none> Annotations:  <none> Data ==== c...