GitOps and Kubernetes

Todd Ekenstam, Billy Yuen, Alex Matyushentsev, Jesse Suen

• Editorial: Manning Publications
• Año: 2021
• ISBN:
  9781617297274
• Categoría: Informatique
• Categoría: Aspects sociaux de l'informatique

GitOps and Kubernetes introduces a radical idea—managing your infrastructure with the same Git pull requests you use to manage your codebase. In this in-depth tutorial, you'll learn to operate infrastructures based on powerful-but-complex technologies such as Kubernetes with the same Git version control tools most developers use daily. With these GitOps techniques and best practices, you'll accelerate application development without compromising on security, easily roll back infrastructure changes, and seamlessly introduce new team members to your automation process.

Part 1. Background

This part of the book covers background and gives you an introduction to GitOps and Kubernetes.

Chapter 1 walks you through the journey of software deployment evolution and how GitOps became the latest practice. It also covers the many key concepts and benefits of GitOps.

Chapter 2 provides key concepts of Kubernetes and why its declarative nature is perfect for GitOps. It also covers the core operator concept and how to implement a simple GitOps operator.

After you grasp the core concepts of GitOps and Kubernetes, you will be ready to dive into the patterns and processes required to adopt GitOps in your deployments. Part 2 covers the GitOps CI/CD pipeline along with environment setup and promotion as well as different deployment strategies. It also covers how you can secure your deployment process and reviews several configuration management tools and various techniques to manage Secrets in GitOps. There is also a chapter devoted to observability as it is related to GitOps.

1 Why GitOps?

This chapter covers

• What is GitOps?
• Why GitOps is important
• GitOps compared with other approaches
• Benefits of GitOps

Kubernetes is a massively popular open source platform that orchestrates and automates operations. Although it improves the management and scaling of infrastructure and applications, Kubernetes frequently has challenges managing the complexity of releasing applications.

Git is the most widely used version-control system in the software industry today. GitOps is a set of procedures that uses the power of Git to provide both revision and change control within the Kubernetes platform. A GitOps strategy can play a big part in how quickly and easily teams manage their services’ environment creation, promotion, and operation.

Using GitOps with Kubernetes is a natural fit, with the deployment of declarative Kubernetes manifest files being controlled by common Git operations. GitOps brings the core benefits of Infrastructure as Code and immutable infrastructure to the deployment, monitoring, and life-cycle management of Kubernetes applications in an intuitive, accessible way.

1.1 Evolution to GitOps

Two everyday tasks in managing and operating computer systems are infrastructure configuration and software deployment. Infrastructure configuration prepares computing resources (such as servers, storage, and load balancers) that enable the software application to operate correctly. Software deployment is the process of taking a particular version of a software application and making it ready to run on the computing infrastructure. Managing these two processes is the core of GitOps. Before we dig into how this management is done in GitOps, however, it is useful to understand the challenges that have led the industry toward DevOps and the immutable, declarative infrastructure of GitOps.

1.1.1 Traditional Ops

In a traditional information technology operations model, development teams are responsible for periodically delivering new versions of a software application to a quality-assurance (QA) team that tests the new version and then delivers it to an operations team for deployment. New versions of software may be released once a year, once a quarter, or at shorter intervals. It becomes increasingly difficult for a traditional operations model to support increasingly compressed release cycles.

The operations team is responsible for the infrastructure configuration and deployment of the new software application versions to that infrastructure. The operations team’s primary focus is to ensure the reliability, resilience, and security of the system running the software. Without sophisticated management frameworks, infrastructure management can be a difficult task that requires a lot of specialized knowledge.

Figure 1.1 Traditional IT teams are typically composed of separate development, QA, and operations teams. Each team specializes in a different aspect of the application development process.

it operations IT operations is the set of all processes and services that are both provisioned by an IT staff to internal or external clients and used by the staff to provide a business’s technology needs. Operations work can include responding to tickets generated for maintenance work or customer issues.¹

Because three teams are involved, often with different management-reporting structures, a detailed handoff process and thorough documentation of the application changes are needed to ensure that the application is adequately tested, appropriate changes are made to infrastructure, and the application is installed correctly. These requirements, however, cause deployments to take a long time and reduce the frequency at which deployments can be made. Also, with each transition between teams, the possibility that essential details will not being communicated increases, possibly leading to gaps in testing or incorrect deployment.

Figure 1.2 In the traditional deployment flow, the development team opens a ticket for the QA team to test a new product version. When the testing is successful, the QA team opens a ticket for the operations team to deploy the latest version to production.

Fortunately, most development teams compile, test, and produce their deployable artifacts by using automated build systems and a process called continuous integration (CI). But the new code’s deployment is often a manual process performed by the operations team, involving lengthy manual procedures or partial automation through deployment scripts. In a worst-case scenario, the operations engineer manually copies the executable binary file to the needed location on multiple servers and manually restarts the application to make the new binary version take effect. This process is error prone and offers few options for controls such as review, approval, auditability, and rollback.

Continuous Integration (CI) CI involves automated building, testing, and packaging of software applications. In a typical development workflow, software engineers make code changes that are checked into the central code repository. These changes must be tested and integrated with the main code branch intended to be deployed to production. A CI system facilitates the review, building, and testing of code to ensure its quality before merging to the main branch.

With the rise of cloud computing infrastructure, the interfaces that manage compute and network resources have become increasingly based on application programming interfaces (APIs), allowing for more automation but requiring more programming skills to implement. This fact, coupled with many organizations’ search for ways to optimize operations, reduce deployment times, increase deployment frequency, and improve their computing systems’ reliability, stability, and performance, led to a new industry trend: DevOps.

1.1.2 DevOps

DevOps is both an organizational structure and a mindset change with an emphasis on automation. An operations team is no longer responsible for deployment and operation; the application’s development team takes on these responsibilities.

devops DevOps is a set of software development practices that combine software development (Dev) and IT operations (Ops) to shorten the system development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.²

Figure 1.3 shows how, in a traditional operations model, the organization is divided by functional bou...