Kubernetes - do or do not, there is no try
•Download as PPTX, PDF•
0 likes•196 views
James Strong presented on adopting Kubernetes. He began by outlining why Kubernetes may be a good solution based on factors like workload variability and infrastructure management needs. He then discussed steps to adopt containers like establishing local development environments and container security. For adopting Kubernetes, he recommended forming a working group, enabling local development with tools like kind and minikube, creating documentation, and hosting workshops. Key aspects of scaling Kubernetes include logging, monitoring, metrics, security, and provisioning. He stressed the importance of upskilling teams, joining the community, and automation.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kubernetes - do or do not, there is no try
Similar to Kubernetes - do or do not, there is no try (20)
Recently uploaded
Recently uploaded (20)
Kubernetes - do or do not, there is no try
- 1. Kubernetes: Do Or Do Not, There Is No Try James Strong - Cloud Native Director Dec 3, 2020, 5:45 PM - 6:45 PM
- 2. strongjz @strongjz James Strong Cloud Native Director - Contino AWS APN Ambassador A Cloud Guru Instructor Kentucky CNCF Meetup Organizer Certified Kubernetes Administrator
- 5. 01 | Introduction 02 | Why Kubernetes? 03 | Adopting Containers 04 | Adopting Kubernetes 05 | Case Study Agenda 5
- 6. ● What problem are you solving? ● How variant is your traffic? ● Is your team familiar with containerized applications? ● Do you have a good release process? ● Do you want to separate the management of the infrastructure from the applications? ● Do you frequently have too much or not enough compute power for your applications and deployment processes? Why Kubernetes?
- 7. Adopting Containers ● Make it easy! ● Set up a base container with common tools/technologies ● Enable local development
- 8. Adopting Containers ● Private Registries ● Secure Containers ● Office Hours ● Automate, automate, automate.
- 9. Adopting Kubernetes ● Working Group ● Enable Local Development (kind, minikube) ● Create a reference application and good docs ● Workshops
- 11. Scaling Kubernetes ● Logging ● Monitoring ● Metrics ● Security ● Cluster Provisioning
- 12. Create A Team ● Existing Teams using container tech ● Upskill other teams ● Hiring new team members
- 13. Join the Community ● CNCF Slack ● Kubernetes SIG ● Meetups ● CNCF Membership
- 15. Takeaways ● Build internal Knowledge ● Scale Appropriately ● Enterprise Operating Model ● Automation ● Automation ● Automation
- 17. Amazon Elastic Container Registry
- 18. Amazon Elastic Kubernetes Service
- 19. AWS App Mesh
- 20. Amazon Elastic Container Service
- 21. AWS Proton
- 23. ● https://contino.github.io/intro-k8/ ● https://acloud.guru/learn/advanced-networking-with-kubernetes-for-aws ● https://github.com/contino/kubernetes-best-practices ● https://github.com/contino/kubernetes-command-cheat-sheet ● https://katacoda.com/contino/courses/kubernetes ● https://www.contino.io/insights/what-is-cloud-native-architecture-and-why-is-it-so-important ● https://www.contino.io/insights/3-things-every-cto-should-know-about-kubernetes Contino Kubernetes Resources
- 25. Atlanta atlanta@contino.io Thank You contino.io continohq contino London london@contino.io New York newyork@contino.io Melbourne melbourne@contino.io Sydney sydney@contino.io
Editor's Notes
- It’s not just kubernetes.
- James Because of the complexity of operations and migration We also should be asking, what problem are you trying to solve? What problem do you think k8 will solve? With 2 gcloud instances, 100 nginx containers, we can sustain one million per seconds. I’ve seen the demo First principles, kubernetes is an orchestration platform for containers, are the applications or teams familiar with containers Kubernetes does help with the release process, making it standard across teams
- Make it easy! Set up a base container with common tools/technologies. Enable local development Automate, automate, automate.
- Private Registries Secure Containers Office Hours Automate, automate, automate.
- James Enable local development (kind, minikube) Create a reference application and good docs Workshops and user groups.
- Logging Monitoring Metrics Cluster Provisioning
- Public and Private options AWS IAM permissions CVS vuln scanning Immutable image tagging
- Bottlerocket OS EKS Optimized AMI Eksctl EKS anywhere ALB ingress controller native integration with ALB Cloudwatch agent for logging
- Traffic Routing mTLS Canary Deploys 1. AWS App Mesh has several components that power the service mesh functionality. 2. A virtual service is an abstraction of a real service. 3. Virtual routers handle traffic for one or more virtual services within the mesh. After creating a virtual router, routes can be created and associated to it to direct incoming requests to different virtual nodes. 4. A virtual node acts as a logical pointer to a particular task group, such as an Amazon ECS service or a Kubernetes deployment We will be deploying all of this in the lab using our ping, data, and admin service. ENvoy proxy for monitoring . Envoy proxy controls all 2, outgoing and in coming traffic 3. It emits statsd metrics that can be sent to 4. Cloud Watch for storage 5. Also you can run the AWS X-ray agent inside the application pod to emit 6. metrics to AWS X-Ray for traffic flow analsyt 7. Application Logs can also be sent to cloud watch Some of the AWS App mesh functionality includes 1. Service to service communication and abstraction to enable 2. Network traffic control and Advance application rollouts such Canary deployments 3. App mesh adds in Observability by Exposing Statsd metrics, adding in tracing with AWS X-Ray and Integrating with Cloud Watch for application and mesh logs and alerting 4. It includes Fault isolation by adding configurable retry polices for routes inside AWS App mesh , This can mitigate failed requests by selecting a new host and rerouting traffic.
- ECS-optimized AMIs The AWS Copilot command line interface (CLI) commands simplify building, releasing, and operating production-ready containerized applications on Amazon ECS
- AWS Proton helps you update out-of-date applications with a single click. For Proton, an environment represents the set of shared resources and policies that Proton services are deployed into. An environment applies to all stacks deployed for a service instance. A Proton service is an instantiation of a service template, normally including several service instances and a pipeline. A Proton service instance is an instantiation of a service template in a specific environment. A service template is a complete definition of the infrastructure and pipeline for a Proton service. Schema file (schema.yaml) The schema file uses the OpenAPI format and includes some of the metadata that Proton requires and a definition of all the input and output parameters that are injected in the Jinja parameterized CloudFormation and pipeline templates. The parameter definitions contain such information as the name of the parameter, a description, type, whether the parameter is required, its default value, and other options if applicable. Proton validates and verifies inputs based on the schema file. CloudFormation file (cloudformation.yaml) The CloudFormation templates define infrastructure and resources that are used for the service. As an administrator, you write these templates using standard CloudFormation methods, and then use Jinja to indicate the input and output parameters as defined in the schema. CloudFormation file (pipeline.yaml) The pipeline CloudFormation templates define the pipeline that is used for the service. You write these templates using standard CloudFormation methods, and then use Jinja to indicate the input and output parameters as defined in the schema. Manifest file (manifest.yaml) The manifest file includes a list of the templates that will be used to define provisioning of the service infrastructure and the service pipeline.
- The team brought in Contino to define a Cloud and Containers strategy that is scalable across the entire IT organization. Two pilots were completed - each app was onboarded to the internal Kubernetes platform, the CI/CD process was automated, delivery pipelines were designed and processes were defined and standardized. Additionally, Contino established a CCOE (Cloud Center of Excellence) to help drive the cloud strategy and help upskill the Catalyst team to scale further transformation efforts. Automated app deployment - 40% CCOE - Workshops and working group Playbooks and strategic arch Developer Experience - Local Dev, FAQ, path to production