Get Started with MPAS
This tutorial shows you how to bootstrap MPAS to a Kubernetes cluster and deploy a simple application.
Prerequisites
- A Kubernetes cluster
- A GitHub access token with
repo
scope - kubectl
Objectives
- Bootstrap MPAS to a Kubernetes cluster
- Deploy a simple application
Install the MPAS CLI
The MPAS CLI is the primary tool for interacting with MPAS. It can be used to bootstrap MPAS to a Kubernetes cluster.
To install the MPAS CLI using brew
:
For other installation methods, see the installation guide.
Bootstrap MPAS
Export your GitHub access token
The MPAS CLI uses your GitHub access token to authenticate with GitHub. To create a GitHub access token, see the GitHub documentation. In addition to that we need to export your GitHub user and an your email address as they are used later.
Bootstrap
To bootstrap MPAS to your Kubernetes cluster, run the following command. If nothing is specified it will use the KUBECONFIG specified in the user’s environment. It is also possible to specify a dedicated config using the –kubeconfig option.
This command will create a new Github repository called mpas-bootstrap
and bootstrap
MPAS to your Kubernetes cluster. The following components will be installed:
- Flux: A Kubernetes operator that will install and manage the other components.
- ocm-controller: A Kubernetes controller that enables the automated deployment of software components using the Open Component Model and Flux.
- git-controller: A Kubernetes controller that will create pull requests in the target Github repository when changes are made to the cluster.
- replication-controller: A Kubernetes controller that
keeps keep component versions in the cluster up-to-date with a version defined by the consumer in the
ComponentSubscription
resource. - mpas-product-controller: A Kubernetes controller, responsible for creating a product. Reconciles the
Product
resource. - mpas-project-controller: A Kubernetes controller responsible for bootstrapping a whole project. Creates relevant access credentials, service accounts, roles and the main GitOps repository and
reconciles the
Project
resource.
The output of the bootstrap is similar to the following:
After completing the bootstrap process, the target github repository will contain
yaml manifests for the components to be installed on the cluster and Flux will
apply all of them to get the components installed. Furthermore the installed Flux
components will
be configured to watch the target github repository for changes in the path ./clusters/my-cluster
.
Clone the git repository
Clone the mpas-bootstrap
repository to your local machine:
Deploy podinfo application
The podinfo application has been packaged as an OCM component and can be retrieved from Github.
Create a secret containing your GitHub credentials that will be used by MPAS to create your project repository.
Create a project that will contain the podinfo application.
Let’s create a directory for the project:
Then, create a
project.yaml
file in the./clusters/my-cluster/podinfo
directory:Then, apply the project to the cluster in a GitOps fashion:
Flux
will detect the changes and apply the project to the cluster.This will create a
namespace
for the project, aserviceaccount
, and RBAC in the cluster. It will also create a GitHub repository for the project, and configureFlux
to manage the project’s resources.Add the needed secrets to the namespace
Flux
is used to deploy all workloads in a GitOps way.Flux
needs a secret in the project namespace that will be used to communicate with github:Note The credentials should have access to GitHub packages.
As part of step 2, a
serviceaccount
was created for the project. We will use this service account to provide the necessary permissions to pull from theghcr
registry.First, create a secret containing the credentials for the service account:
Then, patch the service account to use the secret:
Clone the project repository
Add the podinfo
ComponentSubscription
Create a file under
./subscriptions/
that will contain the subscription declaration.Then, apply the
ComponentSubscription
to the project in a GitOps fashion:Flux
will detect the changes and apply the subscription to the cluster.This will replicate the product referenced by the field
spec.component
in theComponentSubscription
resource from the defined registry inspec.source.url
to thespec.destination.url
registry.Add a
Target
for the podinfo applicationThe target will define where the application will be installed
Then, apply the
Target
to the project in a GitOps fashion:Flux
will detect the changes and apply the target to the cluster.In order for the
Target
to reach aReady
state, the needed secrets should be created in thepodinfo
namespace.First, create a secret containing the credentials for the service account:
Then, add a label to allow the target to select it using the label selector:
Deploy the podinfo application
In order to deploy the podinfo application, we need to create a
ProductDeploymentGenerator
resource:Then, apply the
ProductDeploymentGenerator
to the project in a GitOps fashion:Flux
will detect the changes and apply the resource to the cluster.This will create a pull request in the project repository with the
ProductDeployment
resource that will deploy the podinfo application.Go to the project repository and retrieve the pull request. It should contain a
ProductDeployment
declaration that provides the configuration and all steps needed to deploy the product, as well as avalues.yaml
file. Thevalues
file contains values that should be used to configure the different resources that are part of the product to be deployed. There is a check that should pass before merging the pull request.Once the pull request is merged,
Flux
will detect the changes and deploy the application to the cluster.After a moment the
ProductDeployment
should be deployed successfully. It is possible to verify this with the command:The result should look something like:
The application is deployed in the
podinfo
namespace.