Last month, Stone Door Group teamed up with Mirantis to deliver a free, 4-part series of one-hour workshops on various DevOps topics to sharpen your Docker and Kubernetes skills. Our first webinar focused on how to get Docker Enterprise running in 1 hour. 

Our second webinar focused on “Docker Tips for Better Productivity” and we demonstrated ways administrators can gain an edge in their Docker administration. Topics included building efficient and lightweight containers, optimizing Docker networking, and ways to leverage the Docker API for automation.

Our third webinar in this series  “Docker Tips for Better Security” demonstrated ways administrators can leverage the full features of Docker Enterprise Edition for corporate compliance and regulatory requirements. Topics include in depth review of content sourcing and scanning, best practices on securing registries, and implementing appropriate authorization for container runtimes.

Our final webinar in the 4-part series focuses on Kubernetes Tips for Better Productivity. This session offers tips for administrators looking to gain an edge in their Docker administration. Topics include building efficient and lightweight containers, optimizing Docker networking, and ways to leverage the Docker API for automation.

Links to Recordings

• Session #1 - Getting Docker Enterprise Edition Running in 1 Hour

• Session #2 - Docker Tips for Better Productivity

• Session #3 Docker Tips for Better Security

• Session #4 Kubernetes Tips for Better Productivity

Kubernetes Tips for Better Productivity Webinar Recording:

About the Presenter

Amber Ernst is a Docker Certified Associate and Docker Accredited Instructor for Stone Door Group, a Professional Docker Value Added Reseller. Amber is a Docker and Kubernetes expert who currently teaches all courses in Docker’s official training catalog and is based in San Antonio, TX.

About Stone Door Group Docker CE to EE Accelerator

Our Docker CE-to-EE Accelerator℠ transforms your development instance of Docker CE into a compliant, enterprise container platform. We understand your developers’ passion for momentum and your security team’s need for regulatory compliance. Our engagements increase the velocity of feature releases while implementing operational, security, and regulatory requirements. For more information, drop us a line at letsdothis@stonedoorgroup.com.

THE FOLLOWING IS A CURATED LIST OF QUESTIONS FROM THE Q&A DURING OUR WEBINAR THAT CONTAIN INFORMATION ABOUT DOCKER SECURITY

If our developers do not set default memory limits, how could we set up system reservations to prevent Kubernetes pods from using all the memory on the machines? Is there a system-reservation that can be set?

Operations should be setting these default memory limitations (at least in production) as a catch-all for exactly the situation described, where your developers don’t include limits.

Default limits are a great tool to help prevent mishaps, setting a limit ensures those connections are closed at a specified point.

How should provisioning limits be set within the resource availability limits?

 The request should be equal or less than the limit to avoid overprovisioning. Usually, I just make them equal.

https://kubernetes.io/docs/concepts/policy/limit-range/

Are there any criteria for setting up a limit range based on the resource availability? Do you have any best practices?

We encourage people to set limit = reservation to avoid overprovisioning.

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

 

Can the default resources be given as a percentage of available resources or it needs to be already given in absolute numbers?

I always have assigned it in absolute numbers, since that’s how I think about the number of resources that my process needs. If I have something that I’m expecting to allocate 2GB of memory, that’s what I expect it to allocate. As a developer, you can’t know exactly where the pod will get deployed or what size or resources will be available.

When a label is assigned or changed, is it logged somewhere? Would it be possible to track this in the future if we need for audit purposes?

Yes, you can check the logs of the Kube API server. The Docker Universal Control Panel (UCP) also logs all API requests in its audit logs when enabled.

If you are not using UCP, another great way to manage your Kubernetes clusters, particularly in production where auditing is necessary, would be to use a GitOps workflow. In this situation, you would not be hitting kubectl directly. If you wanted to do something to your cluster, you could commit these to a Git repository and have an agent (Jenkins, Flux, etc.) assigned to monitor the repository and match the state of your cluster described in your repo.

The reasoning behind this is the indelible history of your Git, here you could look at your commit history and see any changes that have been made to your Kubernetes cluster.

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Can Helm be used together with Jenkins?

Absolutely, Helm is just a templating and deployment engine. Jenkins can easily deploy to it.