In this scenario you will learn how to use low-level primitives of Kubernetes to manage apps. Especially, we'll be using the stock market micro-services app you're already familiar with from the container basics scenario.
Congrats!! You've mastered the second level of containerized apps building.
Note that via kubectl-in-action you can learn even more Kubernetes CLI tricks and gather tips around debugging, RBAC, etc.
OK, so you're a container Jedi Master now, but you have no seat on the council, yet. So if you wanna hang with Yoda and the gang, you can now continue with the next scenario where we'll have a look at how to use an enterprise Kubernetes distribution (OpenShift) to manage containerized apps.
Understanding the YAML app manifest
A Kubernetes YAML file or manifest defines the container orchestration bits of your application, including but not limited to:
- workloads like pods or deployments
- networking related stuff such as services or Ingress
- data and storage related things, for example volumes and persistent volumes
- other things that you as an appops usually don't need to care about, for example nodes and access control
Let's have a look at a concrete example, so things become clearer. Remember the
stock-con microservices from the previous scenario? We define each of these as an app in Kubernetes, consisting of a
deployment and a
service, like so (source):
apiVersion: apps/v1beta1 kind: Deployment metadata: labels: app: stock-con name: stock-con spec: replicas: 1 template: metadata: labels: app: stock-con spec: containers: - name: stock-con image: quay.io/mhausenblas/stock-con:0.3 env: - name: DOK_STOCKGEN_HOSTNAME value: stock-gen - name: DOK_STOCKGEN_PORT value: "9999" ports: - containerPort: 9898 protocol: TCP --- apiVersion: v1 kind: Service metadata: labels: app: stock-con name: stock-con spec: type: ClusterIP ports: - name: http port: 80 protocol: TCP targetPort: 9898 selector: app: stock-con