@@ -36,152 +36,24 @@ In the following we will look at the files of our Minio Standalone application/c
Minio needs persistent storage to store objects. The idea of persistent data applies to many data applictions, so this fundemental piece is applicable in many scenarios. Without persistent storage, the data stored in an application instance will be stored in the container file system, which will be destroyed as soon as the container restarts. This is true for any application needing to persist data on Slate. So, to persist data in your application use a persistent volume claim, or "PVC".
The file we use to do this is [minio-standalone-pvc.yaml](https://code.ornl.gov/ryu/slate_helm_examples/-/blob/prout-dev/charts/minio-standalone/templates/minio-standalone-pvc.yaml):
The file we use to do this is [minio-standalone-pvc.yaml](templates/minio-standalone-pvc.yaml).
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
# This name uniquely identifies the PVC. This is used in deployment.
name: minio-standalone-pv-claim
spec:
# Read more about access modes here: http://kubernetes.io/docs/user-guide/persistent-volumes/#access-modes
accessModes:
# The volume is mounted as read-write by a single node
- ReadWriteOnce
resources:
# This is the request for storage. Should be available in the cluster.
requests:
storage: 10Gi
```
### The Deployment
A deployment encapsulates [ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) and [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/). If a pod goes down, the replication controller makes sure another pod comes up automatically. This creates the ability to handle pod failures automatically, without you having to worry about them, enabliing stable applications and services.
The file we use to do this is [minio-standaline-deployment.yaml](https://code.ornl.gov/ryu/slate_helm_examples/-/blob/prout-dev/charts/minio-standalone/templates/minio-standalone-deployment.yaml):
```
apiVersion: apps/v1
kind: Deployment
metadata:
# This name uniquely identifies the Deployment
name: minio-standalone
spec:
selector:
matchLabels:
app: minio-standalone # has to match .spec.template.metadata.labels
strategy:
# Specifies the strategy used to replace old Pods by new ones
# This label is used as a selector in Service definition
app: minio-standalone
spec:
# Volumes used by this deployment
volumes:
- name: data
# This volume is based on PVC
persistentVolumeClaim:
# Name of the PVC created earlier
claimName: minio-standalone-pv-claim
containers:
- name: minio
# Volume mounts for this container
volumeMounts:
# Volume 'data' is mounted to path '/data'
- name: data
mountPath: "/data"
# Pulls the lastest Minio image from Docker Hub
image: minio/minio:RELEASE.2020-05-08T02-40-49Z
args:
- server
- /data
env:
# MinIO access key and secret key
- name: MINIO_ACCESS_KEY
valueFrom:
secretKeyRef:
key: SECRET_TOKEN
name: minio-standalone-access-key
- name: MINIO_SECRET_KEY
valueFrom:
secretKeyRef:
key: SECRET_TOKEN
name: minio-standalone-secret-key
ports:
- containerPort: 9000
# Readiness probe detects situations when MinIO server instance
# is not ready to accept traffic. Kubernetes doesn't forward
# traffic to the pod while readiness checks fail.
readinessProbe:
httpGet:
path: /minio/health/ready
port: 9000
initialDelaySeconds: 120
periodSeconds: 20
# Liveness probe detects situations where MinIO server instance
# is not working properly and needs restart. Kubernetes automatically
# restarts the pods if liveness checks fail.
livenessProbe:
httpGet:
path: /minio/health/live
port: 9000
initialDelaySeconds: 120
periodSeconds: 20
```
The file we use to do this is [minio-standaline-deployment.yaml](templates/minio-standalone-deployment.yaml).
### The Service
A service allows us to expose our deployment externally. There are three major service types - the default is ClusterIP, which exposes a service to connection from inside the cluster. The NodePort and LoadBalancer types enable the ability to expose services to external traffic directly.
In this example we use the ClusterIP type in our [minio-standalone-service.yaml](https://code.ornl.gov/ryu/slate_helm_examples/-/blob/prout-dev/charts/minio-standalone/templates/minio-standalone-service.yaml):
```
apiVersion: v1
kind: Service
metadata:
# This name uniquely identifies the service
name: minio-standalone-service
labels:
app: minio-standalone
spec:
type: ClusterIP
ports:
- name: 9000-tcp
port: 9000
targetPort: 9000
protocol: TCP
selector:
# Looks for labels `app:minio-standalone` in the namespace and applies the spec
app: minio-standalone
```
In this example we use the ClusterIP type in our [minio-standalone-service.yaml](templates/minio-standalone-service.yaml).
### The Route
Since we are using ClusterIP, in the service type above, and our MinIO application is accessible via HTTP/HTTPS, we expose the application via a route. If our service used another protocol, besides HTTP/HTTPS, we would use a NodePort service type.
Here is our [route.yaml](https://code.ornl.gov/ryu/slate_helm_examples/-/blob/prout-dev/charts/minio-standalone/templates/route.yaml) file:
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: minio-standalone
spec:
host: minio-standalone.apps.marble.ccs.ornl.gov
to:
# Associate with the service we created
kind: Service
name: minio-standalone-service
port:
# Needs to match name of port in the service file
targetPort: 9000-tcp
tls:
# Terminate TLS at the router, before sending to service. Preferred method of securing a route.
termination: edge
```
Here is our [route.yaml](templates/route.yaml) file.
Simple diagram of networking relationship and the deployment wrapping the pod(s):
@@ -198,42 +70,12 @@ At the end, once we install our minio-standalone application, we will have the a
Network Policies are specifications of how groups of pods are allowed to communicate with each other and other network endpoints. A pod is selected in Network Policy based on a label, defining rules for network traffic, specific to that pod.
In this example, we create a Network Policy for our minio-standalone applicaiton. Here is the [network-policy.yaml](https://code.ornl.gov/ryu/slate_helm_examples/-/blob/prout-dev/charts/minio-standalone/templates/network-policy.yaml) file:
In this example, we create a Network Policy for our minio-standalone applicaiton. Here is the [network-policy.yaml](templates/network-policy.yaml).
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: web-allow-external
namespace: stf007
spec:
podSelector:
matchLabels:
# how we match our application
app: minio-standalone
ingress:
# allow all
- {}
policyTypes:
- Ingress
```
### The Values File
Helm templates provide built-in objects. One of these objects is "Values". This object provides access to values passed into the chart. The contents, in this case, come from [values.yaml](./values.yaml):
Helm templates provide built-in objects. One of these objects is "Values". This object provides access to values passed into the chart. The contents, in this case, come from [values.yaml](./values.yaml).
```
# This can be used to provide variables to your chart.
# A simple example would be resources in the minio-standalone-deployment.yaml:
minio:
resources:
requests:
cpu: 2
memory: 1Gi
limits:
cpu: 2
memory: 1Gi
```
**NOTE**: Please make sure you rename your ```minio.host``` value. This needs to be unique.
