Stackeblockenize the first section of the readme
This commit is contained in:
		
							parent
							
								
									52d7cda186
								
							
						
					
					
						commit
						8c185e407c
					
				
							
								
								
									
										59
									
								
								README.md
								
								
								
								
							
							
						
						
									
										59
									
								
								README.md
								
								
								
								
							|  | @ -6,21 +6,25 @@ | ||||||
| 
 | 
 | ||||||
| The Postgres operator manages PostgreSQL clusters on Kubernetes using the [operator pattern](https://coreos.com/blog/introducing-operators.html). | The Postgres operator manages PostgreSQL clusters on Kubernetes using the [operator pattern](https://coreos.com/blog/introducing-operators.html). | ||||||
| During the initial run it registers the [Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) for Postgres. | During the initial run it registers the [Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) for Postgres. | ||||||
| The Postgresql CRD is essentially the schema that describes the contents of the manifests for deploying individual Postgresql clusters using Statefulsets and [Patroni](https://github.com/zalando/patroni). | The PostgreSQL CRD is essentially the schema that describes the contents of the manifests for deploying individual  | ||||||
|  | PostgreSQL clusters using StatefulSets and [Patroni](https://github.com/zalando/patroni). | ||||||
| 
 | 
 | ||||||
| Once the operator is running, it performs the following actions: | Once the operator is running, it performs the following actions: | ||||||
| 
 | 
 | ||||||
| * watches for new Postgres cluster manifests and deploys corresponding clusters. | * watches for new PostgreSQL cluster manifests and deploys corresponding clusters | ||||||
| * watches for updates to existing manifests and changes corresponding properties of the running clusters. | * watches for updates to existing manifests and changes corresponding properties of the running clusters | ||||||
| * watches for deletes of the existing manifests and deletes corresponding database clusters. | * watches for deletes of the existing manifests and deletes corresponding clusters | ||||||
| * acts on an update to the operator definition itself and changes the running clusters when necessary (i.e. when the docker image inside the operator definition has been updated.) | * acts on an update to the operator definition itself and changes the running clusters when necessary  | ||||||
| * periodically checks running clusters against the manifests and acts on the differences found. |   (i.e. when the docker image inside the operator definition has been updated) | ||||||
|  | * periodically checks running clusters against the manifests and acts on the differences found | ||||||
| 
 | 
 | ||||||
| For instance, when the user creates a new custom object of type postgresql by submitting a new manifest with kubectl, the operator fetches that object and creates the corresponding kubernetes structures (StatefulSets, Services, Secrets) according to its definition. | For instance, when the user creates a new custom object of type ``postgresql`` by submitting a new manifest with  | ||||||
|  | ``kubectl``, the operator fetches that object and creates the corresponding Kubernetes structures  | ||||||
|  | (StatefulSets, Services, Secrets) according to its definition. | ||||||
| 
 | 
 | ||||||
| Another example is changing the docker image inside the operator. In this case, the operator first goes to all Statefulsets | Another example is changing the docker image inside the operator. In this case, the operator first goes to all StatefulSets | ||||||
| it manages and updates them with the new docker images; afterwards, all pods from each Statefulset are killed one by one | it manages and updates them with the new docker images; afterwards, all pods from each StatefulSet are killed one by one | ||||||
| (rolling upgrade) and the replacements are spawned automatically by each Statefulset with the new docker image. | (rolling upgrade) and the replacements are spawned automatically by each StatefulSet with the new docker image. | ||||||
| 
 | 
 | ||||||
| ## Status | ## Status | ||||||
| 
 | 
 | ||||||
|  | @ -29,42 +33,44 @@ Please, report any issues discovered to https://github.com/zalando-incubator/pos | ||||||
| 
 | 
 | ||||||
| ## Running and testing the operator | ## Running and testing the operator | ||||||
| 
 | 
 | ||||||
| The best way to test the operator is to run it in minikube. Minikube is a tool to run Kubernetes cluster locally. | The best way to test the operator is to run it in [minikube](https://kubernetes.io/docs/getting-started-guides/minikube/).  | ||||||
|  | Minikube is a tool to run Kubernetes cluster locally. | ||||||
| 
 | 
 | ||||||
| ### Installing and starting minikube | ### Installing and starting minikube | ||||||
| 
 | 
 | ||||||
| See [minikube installation guide](https://github.com/kubernetes/minikube/releases) | See [minikube installation guide](https://github.com/kubernetes/minikube/releases) | ||||||
| 
 | 
 | ||||||
| Make sure you use the latest version of Minikube. | Make sure you use the latest version of Minikube. | ||||||
| After the installation, issue the | 
 | ||||||
|  | After the installation, issue | ||||||
| 
 | 
 | ||||||
|     $ minikube start |     $ minikube start | ||||||
| 
 | 
 | ||||||
| Note: if you are running on a Mac, make sure to use the [xhyve driver](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#xhyve-driver) | Note: if you are running on a Mac, make sure to use the [xhyve driver](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#xhyve-driver) | ||||||
| instead of the default docker-machine one for performance reasons. | instead of the default docker-machine one for performance reasons. | ||||||
| 
 | 
 | ||||||
| One you have it started successfully, use [the quickstart guide](https://github.com/kubernetes/minikube#quickstart) in order | Once you have it started successfully, use [the quickstart guide](https://github.com/kubernetes/minikube#quickstart) in order | ||||||
| to test your that your setup is working. | to test your that your setup is working. | ||||||
| 
 | 
 | ||||||
| Note: if you use multiple kubernetes clusters, you can switch to minikube with `kubectl config use-context minikube` | Note: if you use multiple Kubernetes clusters, you can switch to Minikube with `kubectl config use-context minikube` | ||||||
| 
 | 
 | ||||||
| ### Create ConfigMap | ### Create ConfigMap | ||||||
| 
 | 
 | ||||||
| ConfigMap is used to store configuration of the operator | ConfigMap is used to store the configuration of the operator | ||||||
| 
 | 
 | ||||||
|     $ kubectl --context minikube  create -f manifests/configmap.yaml |     $ kubectl --context minikube  create -f manifests/configmap.yaml | ||||||
| 
 | 
 | ||||||
| ### Deploying the operator | ### Deploying the operator | ||||||
| 
 | 
 | ||||||
| First you need to install the service account definition in your minikube cluster. | First you need to install the service account definition in your Minikube cluster. | ||||||
| 
 | 
 | ||||||
|     $ kubectl --context minikube create -f manifests/serviceaccount.yaml |     $ kubectl --context minikube create -f manifests/serviceaccount.yaml | ||||||
| 
 | 
 | ||||||
| Next deploy the postgers-operator from the Docker image Zalando is using: | Next deploy the postgres-operator from the docker image Zalando is using: | ||||||
| 
 | 
 | ||||||
|     $ kubectl --context minikube create -f manifests/postgres-operator.yaml |     $ kubectl --context minikube create -f manifests/postgres-operator.yaml | ||||||
| 
 | 
 | ||||||
| If you perfer to build the image yourself follow up down below. | If you prefer to build the image yourself follow up down below. | ||||||
| 
 | 
 | ||||||
| ### Check if CustomResourceDefinition has been registered | ### Check if CustomResourceDefinition has been registered | ||||||
| 
 | 
 | ||||||
|  | @ -74,11 +80,11 @@ If you perfer to build the image yourself follow up down below. | ||||||
| 	postgresqls.acid.zalan.do     CustomResourceDefinition.v1beta1.apiextensions.k8s.io | 	postgresqls.acid.zalan.do     CustomResourceDefinition.v1beta1.apiextensions.k8s.io | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| ### Create a new spilo cluster | ### Create a new Spilo cluster | ||||||
| 
 | 
 | ||||||
|     $ kubectl --context minikube  create -f manifests/minimal-postgres-manifest.yaml |     $ kubectl --context minikube  create -f manifests/minimal-postgres-manifest.yaml | ||||||
| 
 | 
 | ||||||
| ### Watch Pods being created | ### Watch pods being created | ||||||
| 
 | 
 | ||||||
|     $ kubectl --context minikube  get pods -w --show-labels |     $ kubectl --context minikube  get pods -w --show-labels | ||||||
| 
 | 
 | ||||||
|  | @ -97,9 +103,11 @@ We can use the generated secret of the `postgres` robot user to connect to our ` | ||||||
| 
 | 
 | ||||||
| The operator can be configured with the provided ConfigMap (`manifests/configmap.yaml`). | The operator can be configured with the provided ConfigMap (`manifests/configmap.yaml`). | ||||||
| 
 | 
 | ||||||
| #### Use Taints and Tolerations for Dedicated Postgres Nodes | #### Use taints and tolerations for dedicated PostgreSQL nodes | ||||||
| 
 | 
 | ||||||
| To ensure Postgres pods are running on nodes without any other application pods, you can use [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) and configure the required toleration in the operator ConfigMap. | To ensure Postgres pods are running on nodes without any other application pods, you can use  | ||||||
|  | [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) and configure the  | ||||||
|  | required toleration in the operator ConfigMap. | ||||||
| 
 | 
 | ||||||
| As an example you can set following node taint: | As an example you can set following node taint: | ||||||
| 
 | 
 | ||||||
|  | @ -107,7 +115,7 @@ As an example you can set following node taint: | ||||||
| $ kubectl taint nodes <nodeName> postgres=:NoSchedule | $ kubectl taint nodes <nodeName> postgres=:NoSchedule | ||||||
| ``` | ``` | ||||||
| 
 | 
 | ||||||
| And configure the toleration for the Postgres pods by adding following line to the ConfigMap: | And configure the toleration for the PostgreSQL pods by adding following line to the ConfigMap: | ||||||
| 
 | 
 | ||||||
| ``` | ``` | ||||||
| apiVersion: v1 | apiVersion: v1 | ||||||
|  | @ -119,7 +127,7 @@ data: | ||||||
|   ... |   ... | ||||||
| ``` | ``` | ||||||
| 
 | 
 | ||||||
| Or you can specify and/or overwrite the tolerations for each postgres instance in the postgres manifest: | Or you can specify and/or overwrite the tolerations for each PostgreSQL instance in the manifest: | ||||||
| 
 | 
 | ||||||
| ``` | ``` | ||||||
| apiVersion: "acid.zalan.do/v1" | apiVersion: "acid.zalan.do/v1" | ||||||
|  | @ -134,7 +142,8 @@ spec: | ||||||
|     effect: NoSchedule |     effect: NoSchedule | ||||||
| ``` | ``` | ||||||
| 
 | 
 | ||||||
| Please be ware that the taint and toleration only ensures that no other pod gets scheduled to the "postgres" node but not that Postgres pods are placed on such a node. This can be achieved by setting a node affinity rule in the ConfigMap. | Please be aware that the taint and toleration only ensures that no other pod gets scheduled to a PostgreSQL node  | ||||||
|  | but not that PostgreSQL pods are placed on such a node. This can be achieved by setting a node affinity rule in the ConfigMap. | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| # Setup development environment | # Setup development environment | ||||||
|  |  | ||||||
		Loading…
	
		Reference in New Issue