Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Commit

Permalink
Merge pull request #1357 from dholbach/fix-1205
Browse files Browse the repository at this point in the history
Restructure Helm related docs
  • Loading branch information
Daniel Holbach authored Sep 14, 2018
2 parents 274ae24 + b563ac8 commit c5db6d2
Show file tree
Hide file tree
Showing 9 changed files with 377 additions and 360 deletions.
6 changes: 4 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ Its major features are:

- [Automated git → cluster synchronisation](/site/introduction.md#automated-git-cluster-synchronisation)
- [Automated deployment of new container images](/site/introduction.md#automated-deployment-of-new-container-images)
- [Integrations with other devops tools](/site/introduction.md#integrations-with-other-devops-tools) ([Helm](/site/helm/helm-integration.md) and more)
- [Integrations with other devops tools](/site/introduction.md#integrations-with-other-devops-tools) ([Helm](/site/helm-integration.md) and more)
- No additional service or infrastructure needed - Flux lives inside your
cluster
- Straight-forward control over the state of deployments in the
Expand Down Expand Up @@ -78,11 +78,13 @@ Get started by browsing through the documentation below:
- [FAQ](/site/faq.md) and [frequently encountered issues](https://github.com/weaveworks/flux/labels/FAQ)
- [How it works](/site/how-it-works.md)
- [Considerations regarding installing Flux](/site/installing.md)
- [Flux <-> Helm integration](/site/helm-integration.md)
- Get Started with Flux
- [Standalone Flux](/site/standalone/installing.md)
- [Flux using Helm](/site/helm/get-started.md)
- [Flux using Helm](/site/helm-get-started.md)
- Operating Flux
- [Using Flux](/site/using.md)
- [Helm Operator](/site/helm-operator.md)
- [Troubleshooting](/site/troubleshooting.md)
- [Frequently encountered issues](https://github.com/weaveworks/flux/labels/FAQ)
- [Upgrading to Flux v1](/site/upgrading-to-1.0.md)
Expand Down
218 changes: 28 additions & 190 deletions chart/flux/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,12 +12,37 @@ a [Kubernetes](http://kubernetes.io) cluster using the [Helm](https://helm.sh) p

## Prerequisites

- Kubernetes 1.9+
### Kubernetes

Kubernetes >= v1.9 is recommended. Kubernetes v1.8 (the first to support
Custom Resources) appears to have problems with repeated application of
custom resources (see https://github.com/kubernetes/kubernetes/issues/53379).
This means fluxd can fail to apply changes to FluxHelmRelease resources.

### Helm

Tiller should be running in the cluster, though
[helm-operator](../../site/helm-operator.md) will wait
until it can find one.

# Git repo

- One repo containing both desired release state information and Charts
themselves.
- Release state information in the form of Custom Resources manifests is
located under a particular path ("releaseconfig" by default; can be
overriden).
- Charts are colocated under another path ("charts" by default; can be
overriden). Charts are subdirectories under the charts path.
- Custom Resource namespace reflects where the release should be done.
Both the Helm release and its corresponding Custom Resource will
live in this namespace.
- Example of a test repo: https://github.com/weaveworks/flux-helm-test

## Installation

We put together a simple [Get Started
guide](../../site/helm/get-started.md) which takes about 5-10 minutes to follow.
guide](../../site/helm-get-started.md) which takes about 5-10 minutes to follow.
You will have a fully working Flux installation deploying workloads to your
cluster.

Expand Down Expand Up @@ -211,191 +236,4 @@ Update Weave Flux version with:
helm upgrade --reuse-values flux \
--set image.tag=1.3.2 \
weaveworks/flux
```

### Installing Weave Flux helm-operator and Helm with TLS enabled

#### Installing Helm / Tiller

Generate certificates for Tiller and Flux. This will provide a CA, server certs for tiller and client certs for helm / weave flux.

The following script can be used for that (requires [cfssl](https://github.com/cloudflare/cfssl)):

```bash
export TILLER_HOSTNAME=tiller-server
export TILLER_SERVER=server
export USER_NAME=flux-helm-operator
mkdir tls
cd ./tls
# Prep the configuration
echo '{"CN":"CA","key":{"algo":"rsa","size":4096}}' | cfssl gencert -initca - | cfssljson -bare ca -
echo '{"signing":{"default":{"expiry":"43800h","usages":["signing","key encipherment","server auth","client auth"]}}}' > ca-config.json
# Create the tiller certificate
echo '{"CN":"'$TILLER_SERVER'","hosts":[""],"key":{"algo":"rsa","size":4096}}' | cfssl gencert \
-config=ca-config.json -ca=ca.pem \
-ca-key=ca-key.pem \
-hostname="$TILLER_HOSTNAME" - | cfssljson -bare $TILLER_SERVER
# Create a client certificate
echo '{"CN":"'$USER_NAME'","hosts":[""],"key":{"algo":"rsa","size":4096}}' | cfssl gencert \
-config=ca-config.json -ca=ca.pem -ca-key=ca-key.pem \
-hostname="$TILLER_HOSTNAME" - | cfssljson -bare $USER_NAME
```

Alternatively, you can follow the [Helm documentation for configuring TLS](https://docs.helm.sh/using_helm/#using-ssl-between-helm-and-tiller).

Next deploy Helm with TLS and RBAC enabled;

Create a file called `helm-rbac.yaml`. This contains all the RBAC configuration for Tiller:

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: tiller
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: tiller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
---
# Helm client serviceaccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: helm
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: tiller-user
namespace: kube-system
rules:
- apiGroups:
- ""
resources:
- pods/portforward
verbs:
- create
- apiGroups:
- ""
resources:
- pods
verbs:
- list
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: tiller-user-binding
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tiller-user
subjects:
- kind: ServiceAccount
name: helm
namespace: kube-system
```

Deploy Tiller:

```bash
kubectl apply -f helm-rbac.yaml
# Deploy helm with mutual TLS enabled
helm init --upgrade --service-account tiller \
--override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}' \
--tiller-tls \
--tiller-tls-cert ./tls/server.pem \
--tiller-tls-key ./tls/server-key.pem \
--tiller-tls-verify \
--tls-ca-cert ./tls/ca.pem
```

To check if Tiller installed succesfully with TLS enabled, try `helm ls`. This should give an error:

```bash
# Should give an error
$ helm ls
Error: transport is closing
```

When providing the certificates, it should work correctly:

```bash
helm --tls \
--tls-ca-cert ./tls/ca.pem \
--tls-cert ./tls/flux-helm-operator.pem \
--tls-key ././tls/flux-helm-operator-key.pem \
ls
```

### deploy weave flux helm-operator

First create a new Kubernetes TLS secret for the client certs;

```bash
kubectl create secret tls helm-client --cert=tls/flux-helm-operator.pem --key=./tls/flux-helm-operator-key.pem
```

> note; this has to be in the same namespace as the helm-operator is deployed in.

Deploy flux with Helm;

```bash
helm repo add weaveworks https://weaveworks.github.io/flux
helm upgrade --install \
--set helmOperator.create=true \
--set git.url=$YOUR_GIT_REPO \
--set helmOperator.tls.enable=true \
--set helmOperator.tls.verify=true \
--set helmOperator.tls.secretName=helm-client \
--set helmOperator.tls.caContent="$(cat ./tls/ca.pem)" \
flux \
weaveworks/flux
```

#### Check if it worked

Use `kubectl logs` on the helm-operator and observe the helm client being created.

#### Debugging

##### Error creating helm client: failed to append certificates from file: /etc/fluxd/helm-ca/ca.crt

Your CA certificate content is not set correctly, check if your configMap contains the correct values. Example:

```bash
$ kubectl get configmaps flux-helm-tls-ca-config -o yaml
apiVersion: v1
data:
ca.crt: |
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
kind: ConfigMap
metadata:
creationTimestamp: 2018-07-04T15:27:25Z
name: flux-helm-tls-ca-config
namespace: helm-system
resourceVersion: "1267257"
selfLink: /api/v1/namespaces/helm-system/configmaps/flux-helm-tls-ca-config
uid: c106f866-7f9e-11e8-904a-025000000001
```
```
File renamed without changes.
119 changes: 119 additions & 0 deletions site/helm-integration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,119 @@
# Design overview

Chart release information is described through Kubernetes Custom Resource (CR) manifests.

Flux-Helm Integration implementation consists of two parts:

1. *Flux agent* monitors user git repo containing deployment configuration for applications/services, ie Custom Resource manifests. On detecting changes it applies the manifests, resulting in creation or update of Custom Resources.

2. [*Helm operator*](helm-operator.md) deals with Helm Chart releases. The operator watches for changes of Custom Resources of kind FluxHelmRelease. It receives Kubernetes Events and acts accordingly, installing, upgrading or deleting a Chart release.

## More detail

- Kubernetes Custom Resource (CR) manifests contain all the information needed to do a Chart release. There is 1-2-1 releationship between a Helm Chart and a Custom Resource.

- Custom resource manifests can be provided several/all in one file, or in individual files.

- Flux works, at the moment, with one git repo. For Helm integration this repo will initially contain both the desired Chart release information (CR manifests) and Chart directories for each application/service.

- All Chart release configuration is located under one git path. All Chart directories are located under one git path. The git paths must be subdirectories under the repo root.

- [Helm operator](helm-operator.md) uses (Kubernetes) shared informer caching and a work queue, that is processed by a configurable number of workers.

# Custom Resource manifest content

- name of the resource must be unique across all namespaces
- namespace is where both the Custom Resource and the Chart, whose deployment state it describes, will live
- chartgitpath ... this Chart's path within the repo
- releasename is optional. Must be provided if there is already a Chart release in the cluster that Flux should start looking after. Otherwise a new release is created for the application/service when the Custom Resource is created. Can be provided for a brand new release - if it is not, then Flux will create a release names as $namespace-$CR_name
- customizations section contains user customizations overriding the Chart values


## Example of manifest content

```yaml
---
apiVersion: helm.integrations.flux.weave.works/v1alpha2
kind: FluxHelmRelease
metadata:
name: mongodb
namespace: myNamespace
spec:
chartGitPath: mongodb
releaseName: mongo-database
values:
image: bitnami/mongodb:3.7.1-r1
```
## Required fields
- name
- namespace
- chartGitPath ... path (from repo root) to a Chart subdirectory
## Optional fields
- image
- resources -> requests -> memory (nested)
- releaseName:
- if a release already exists and Flux should start managing it, then
releasename must be provided
- if releasename is not provided, Flux will construct a release name
based on the namespace and the Custom Resource name (ie
$namespace-$CR_name)
```yaml
- values:
foo: value1
bar:
baz: value2
oof:
- item1
- item2
```
- `automated` annotations define which images Flux will automatically
deploy on a cluster. You can use glob, semver or regex expressions.
Here's an example for a single image:

```yaml
apiVersion: helm.integrations.flux.weave.works/v1alpha2
kind: FluxHelmRelease
metadata:
name: podinfo-dev
namespace: dev
annotations:
flux.weave.works/automated: "true"
flux.weave.works/tag.chart-image: glob:dev-*
spec:
chartGitPath: podinfo
releaseName: podinfo-dev
values:
image: stefanprodan/podinfo:dev-kb9lm91e
```

For multiple images:

```yaml
apiVersion: helm.integrations.flux.weave.works/v1alpha2
kind: FluxHelmRelease
metadata:
name: podinfo-prod
namespace: prod
annotations:
flux.weave.works/automated: "true"
flux.weave.works/tag.init: semver:~1.0
flux.weave.works/tag.app: regex:^1.2.*
spec:
chartGitPath: podinfo
releaseName: podinfo-prod
values:
init:
image: quay.io/stefanprodan/podinfo:1.2.0
app:
image: quay.io/stefanprodan/podinfo:1.0.0
```

In general a dictionary of key value pairs (which can be nested) for overriding Chart parameters. Examples of parameter names:

- image
- resources -> requests -> memory (nested)
Loading

0 comments on commit c5db6d2

Please sign in to comment.