Moved K8S architecture into architectures

Author: Chris Wiechmann

architecture/README.md

@@ -15,6 +15,7 @@ For each architecture example there will be corresponding detailed information.
 | :---          | :---                 | 
 | [AWS EC2 HA-Setup 1 Region / 2 Zones](aws-ec2-ha-one-region-2-zones)|Example deployment architecture based on classic AWS-EC2 instances for a high availability solution in an AWS region with 2 availability zones.|
 | [Classic-Setup with native Filebeat](classic-simple-filebeat-native)|Very simple example of a classically deployed API gateway (3 nodes).|
+| [Kubernetes/OpenShift deployment](kubernetes)|Deployment in a Docker-Orchestration framework such as Kubernetes|
 
 # Architecture FAQ
 
@@ -24,7 +25,7 @@ No, the solution is designed to run based on Docker containers. It is also plann
 
 ## Can we get rid of API Builder and instead leverage policies in API Gateway/Manager for API detail lookup and other requirements?
 
-No, a large part of the logic of the solution is in the API Builder application. Implementing this in policies might be possible, but managing & updating the individual customer installations would be very time-consuming and error-prone. So the customer has to reference the appropriate API builder image and you know by version exactly what code base the customer is running.
+No, a large part of the logic of the solution is in the API Builder application. Implementing this in policies might be possible, but managing & updating the individual customer installations would be very time-consuming and error-prone. So the customer has to reference the appropriate API-Builder image and you know by version exactly what code base the customer is running.
 
 ## Can we minimize the number of dependencies? Elastic Search, Logstash, Kibana and FileBeat agents are mandatory. Can API Builder and MemCache be made optional?
 

imgs/kubernetes/all_components_incl_filebeat.png renamed to architecture/kubernetes/all_components_incl_filebeat.png

@@ -33,7 +33,7 @@ is for an environment where the API management platform is external to Kubernete
 
 Further deployment options and customizations are described in this document.  
 
-![Kubernetes architecture all components](../imgs/kubernetes/all_components_overview_ext_api-management.png)
+![Kubernetes architecture all components](../architecture/kubernetes/all_components_overview_ext_api-management.png)
 
 ### Get started
 
@@ -150,7 +150,7 @@ Traffic accross the available Logstashes. With that, it works almost the same as
 connections.  
 The following diagram illustrates the approach:  
 
-![Filebeat and Logstash via NodePort](../imgs/kubernetes/filebeat_logstash_nodeport_3_worker_nodes.png)  
+![Filebeat and Logstash via NodePort](../architecture/kubernetes/filebeat_logstash_nodeport_3_worker_nodes.png)  
 
 This is an example setup:  
 ```
@@ -266,7 +266,7 @@ To customize the solution according to your needs, you can configure it using yo
 We recommend that you create your own Helm chart that contains all the necessary resources.  
 You then link your custom resources in your `myvalues.yaml` for the final deployment of the solution. The following illustrates the recommended approach:  
 
-![Customized deployment with Helm](../imgs/kubernetes/customized_deployment_with_helm.png)
+![Customized deployment with Helm](../architecture/kubernetes/customized_deployment_with_helm.png)
 
 ### Create your own Helm-Chart
 ```
@@ -474,7 +474,7 @@ If you are already running the Axway API management solution in a Kubernetes env
 
 The following shows Filebeat and API-Management in a Kubernetes cluster:  
 
-![Kubernetes architecture all components](../imgs/kubernetes/all_components_incl_filebeat.png)  
+![Kubernetes architecture all components](../architecture/kubernetes/all_components_incl_filebeat.png)  
 
 One way to provide Filebeat with the necessary log files of the API-Gateway in a central volume. All API-Gateways write to this volume and Filebeat reads & streams the corresponding documents/events.