Initial mkdocs content

See hyperledger-labs#66

Signed-off-by: James Taylor <[email protected]>

docs/about/community.md

@@ -0,0 +1,3 @@
+# Community
+
+You can find community discussion related to the Kubernetes Builder on the [#fabric-kubernetes](https://discord.com/channels/905194001349627914/945796983795384331) channel on Hyperledger Discord ([invite link](https://discord.gg/hyperledger)).

docs/about/intro.md

@@ -0,0 +1,21 @@
+# Introduction
+
+The Kubernetes external [chaincode builder](../../concepts/chaincode-builder) for Hyperledger Fabric (k8s builder) is an alternative to Fabric's legacy built in Docker chaincode builder, which does not work in a Kubernetes deployment, and the preconfigured chaincode-as-a-service builder, which is more suited to chaincode development and test.
+
+With the k8s builder, the Fabric administrator is responsible for [preparing a chaincode image](../../concepts/chaincode-image), publishing to a container registry, and [preparing a chaincode package](../../concepts/chaincode-package) with coordinates of the contract's immutable image digest.
+When Fabric detects the installation of a `type=k8s` contract, the builder assumes full ownership of the lifecycle of pods, containers, and network linkages necessary to communicate securely with the peer.
+
+
+Advantages:
+
+🚀 Chaincode runs _immediately_ on channel commit.
+
+✨ Avoids the complexity and administrative burdens associated with Chaincode-as-a-Service.
+
+🔥 Pre-published chaincode images avoid code-compilation errors at deployment time.
+
+🏗️ Pre-published chaincode images encourage modern, industry accepted CI/CD best practices.
+
+🛡️ Pre-published chaincode images remove any and all dependencies on a root-level _docker daemon_.
+
+🕵️ Pre-published chaincode images provide traceability and change management features (e.g. Git commit hash as image tag)

docs/about/objectives.md

@@ -0,0 +1,20 @@
+# Objectives
+
+The aim is for the builder to work as closely as possible with the existing [Fabric chaincode lifecycle](https://hyperledger-fabric.readthedocs.io/en/latest/chaincode_lifecycle.html), making sensible compromises for deploying chaincode on Kubernetes within those limitations.
+(The assumption being that there are more people with Kubernetes skills than are familiar with the inner workings of Fabric!)
+
+The two key principles are:
+
+1. **The contents of the chaincode package must uniquely identify the chaincode functions executed on the ledger:**  
+   In the case of the k8s builder the chaincode source code is not actually inside the package.
+   In order not to break the Fabric chaincode lifecycle, the chaincode image must be specified using an immutable `@digest`, not `:label` which can be altered post commit.
+   See [Pull an image by digest (immutable identifier)](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) for more details.
+2. **The Fabric peer manages the chaincode process, not Kubernetes:** 
+   Running the chaincode in server mode, i.e. allowing the peer to initiate the gRPC connection, would make it possible to leave Kubernetes to manage the chaincode process by creating a chaincode deployment.
+   Unfortunately due to limitations in Fabric's builder and launcher implementation, that is not possible and the peer expects to control the chaincode process.
+
+## Status
+
+The k8s builder is [close to a version 1 release](https://github.com/hyperledger-labs/fabric-builder-k8s/milestone/1) and has been tested in a number of Kubernetes environments, deployment platforms, and provides semantic-revision aware [release tags](https://github.com/hyperledger-labs/fabric-builder-k8s/tags) for the external builder binaries.
+
+The current status should be considered as STABLE and any bugs or enhancements delivered as GitHub Issues in conjunction with community PRs.