From overlay networking and SSL to ingress controllers and network security policies, we’ve seen many users get hung up on Kubernetes networking challenges. In this video recording, we dive into Kubernetes networking, and discuss best practices for a wide variety of deployment options.<\/p>\n
Watch the video<\/a><\/p>\n One of the selling points of containers is that containerized Before we delve into Docker optimization tips, let me first explain what The following strategies can help make Docker containers faster.<\/p>\n The more code you have inside your image, the longer it will take to One of the greatest benefits of containers as compared to virtual Image build time is often the biggest kink in your continuous delivery For staff at many organizations, the greatest obstacle to deploying By default, each container can consume as many resources as it wants. Even if your containers are already fast, you can probably make them
\napplications are generally faster to deploy than virtual machines.
\nContainers also usually perform better. But just because containers are
\nfaster by default than alternative infrastructure doesn\u2019t mean that
\nthere are not ways to make them even faster. You can go beyond the
\ndefaults by optimizing Docker container image build time, performance
\nand resource consumption. This post explains how.<\/p>\nDefining \u201cFaster\u201d<\/h2>\n
\nI mean when I write about making containers \u201cfaster.\u201d Within the context
\nof a conversation about Docker, the word faster<\/em> can have several
\nmeanings. It can refer to the execution speed of a process or an
\napplication that runs inside a container. It can refer to image build
\ntime. It can refer to the time it takes to deploy an application, or to
\npush code through the entire delivery pipeline. In this post, I\u2019ll
\nconsider all of these angles by discussing approaches to making Docker
\nfaster in multiple ways.<\/p>\nMake Docker Faster<\/h2>\n
Take a Minimalist Approach to Images<\/h3>\n
\nbuild the image, and for users to download the image. In addition,
\ncode-heavy containers may run sub-optimally because they consume more
\nresources than required. For all of these reasons, you should strive to
\nkeep the code that goes into your container images to the bare minimum
\nthat is required for whatever your image is supposed to do. In some
\ncases, designing minimalist container images may require you to
\nrearchitect your application itself. Bloated applications will always
\nsuffer from slow deployment and weak performance, whether you deploy
\nthem in containers or in something else. You should also resist the
\ntemptation, when writing your Dockerfile, to add services or commands
\nthat are not strictly necessary. For example, if your application
\ndoesn\u2019t need an SSH server, don\u2019t include one. For another example,
\navoid running apt-get upgrade if you don\u2019t need to.<\/p>\nUse a Minimalist Operating System<\/h3>\n
\nmachines is that containers don\u2019t require you to duplicate an entire
\noperating system to host an application. To take advantage of this
\nfeature to greatest effect, you should host your images with an
\noperating system that does everything you need, and nothing more. Your
\noperating system shouldn\u2019t include extra services or data if they do not
\nadvance the mission of your Docker environment. Anything extra is bloat,
\nwhich will undercut the efficiency of your containers. Fortunately, you
\ndon\u2019t have to build your own minimalist operating system for Docker.
\nPlenty of pre-built Linux distributions with small footprints are
\navailable for hosting Docker, such as
\nRancherOS<\/a>.<\/p>\nOptimize Build Time<\/h3>\n
\npipeline. When you have to wait a long time for your Docker images to
\nbuild, you delay your entire delivery process. One way to speed image
\nbuild time is to use registry mirrors. Mirrors make builds faster by
\nreducing the amount of time required to download components when
\nbuilding an image. Combining multiple RUN commands into a single command
\nalso improves build time for images because it reduces the number of
\nlayers in your image, which improves build speed, and optimizes the
\nimage size to boot. Docker\u2019s build cache
\nfeature<\/a>
\nis another useful way to improve build speed. The cache allows you to
\ntake advantage of existing cached images, rather than building each
\nimage from scratch. Finally, creating minimalist images, as discussed
\nabove, will speed build time, too. The less you have to build, the
\nfaster your builds will be.<\/p>\nUse a Containers-as-a-Service Platform<\/h3>\n
\ncontainers quickly and efficiently results from the complexity of
\nbuilding and managing a containerized environment themselves. This is
\nwhy using a Containers-as-a-Service platform, or CaaS, can be handy.
\nWith a CaaS, you get preconfigured environments, as well as deployment
\nand management tools. A CaaS helps to prevent the bottlenecks that would
\notherwise slow down a continuous delivery chain.<\/p>\nUse Resource Quotas<\/h3>\n
\nThis may not always be ideal because poorly designed or malfunctioning
\ncontainers can eat up resources, thereby making other containers run
\nslowly. To help prevent this problem, you can set
\nquotas<\/a> on
\neach container\u2019s compute, memory and disk I\/O allotments. Just keep in
\nmind, of course, that misconfigured quotas can cause serious performance
\nproblems, too; you therefore need to ensure that your containers are
\nable to access the resources they require.<\/p>\nConclusion<\/h2>\n
\nfaster. Optimizing what goes into your images, improving image build
\ntime, avoiding operating system bloat, taking advantage of CaaS and
\nsetting resource quotas are all ways to improve the overall speed and
\nefficiency of your Docker environment.<\/p>\n