Secrets can be defined as Kubernetes objects employed to store sensitive data such as user name and passwords with encryption.
There are multiple ways of creating secrets in Kubernetes.
• Creating from txt files.
• Creating from yaml file.
Creating From Text File
In order to create secrets from a text file such as user name and password, we first need to store them in a txt file and use the subsequent command.
$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt
Creating From Yaml File
apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
password: <User Password>
username: <User Name>
Creating the Secret
$ kubectl create –f Secret.yaml
secrets/tomcat-pass

Using Secrets

Once we have created the secrets, it can be consumed in a pod or the replication controller as −
• Environment Variable
• Volume
As Environment Variable
In order to use the secret as environment variable, we’ll use env under the spec section of pod yaml file.
env:
– name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: tomcat-pass
As Volume
spec:
volumes:
– name: “secretstest”
secret:
secretName: tomcat-pass
containers:
– image: tomcat:7.0
name: awebserver
volumeMounts:
– mountPath: “/tmp/mysec”
name: “secretstest”
Secret Configuration As Environment Variable
apiVersion: v1
kind: ReplicationController
metadata:
name: appname
spec:
replicas: replica_count
template:
metadata:
name: appname
spec:
nodeSelector:
resource-group:
containers:
– name: appname
image:
imagePullPolicy: Always
ports:
– containerPort: 3000
env: —————————–> 1
– name: ENV
valueFrom:
configMapKeyRef:
name: appname
key: tomcat-secrets
Within the above code, under the env definition, we are using secrets as environment variable within the replication controller.
Secrets As Volume Mount
apiVersion: v1
kind: pod
metadata:
name: appname
spec:
metadata:
name: appname
spec:
volumes:
– name: “secretstest”
secret:
secretName: tomcat-pass
containers:
– image: tomcat: 8.0
name: awebserver
volumeMounts:
– mountPath: “/tmp/mysec”
name: “secretstest”

Kubernetes – Network Policy

Network Policy defines how the pods within the equivalent namespace will communicate with each other and the network endpoint. It requires extensions/v1beta1/networkpolicies to be enabled within the runtime configuration within the API server. Its resources use labels to select the pods and define rules to allow traffic to a specific pod in addition to which is defined within the namespace.
First, we need to configure Namespace Isolation Policy. Basically, this kind of networking policies are required on the load balancers.

kind: Namespace
apiVersion: v1
metadata:
annotations:
net.beta.kubernetes.io/network-policy: |
{
"ingress": 
{
"isolation": "DefaultDeny"
}
}
$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy = 
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

Once the namespace is created, we need to create the Network Policy.

Kubernetes – API

Kubernetes API serves as a foundation for declarative configuration schema for the system. Kubectl command-line tool can be employed to create, update, delete, and get API object. Kubernetes API acts a communicator among different components of Kubernetes.

Adding API to Kubernetes

Adding a new API to Kubernetes will add new features to Kubernetes, which will increase the functionality of Kubernetes. However, alongside it will also increase the cost and maintainability of the system. In order to create a balance between the cost and complexity, there are a few sets defined for it.
The API which is getting added should be useful to more than 50% of the users. There is no other way to implement the functionality in Kubernetes. Exceptional circumstances are discussed within the community meeting of Kubernetes, and then API is added.

API Changes

In order to increase the capability of Kubernetes, changes are continuously introduced to the system. It is done by Kubernetes team to add the functionality to Kubernetes without removing or impacting the existing functionality of the system.
To demonstrate the general process, here is an (hypothetical) example −
• A user POSTs a Pod object to /api/v7beta1/…
• The JSON is unmarshalled into a v7beta1.Pod structure
• Default values are applied to the v7beta1.Pod
• The v7beta1.Pod is converted to an api.Pod structure
• The api.Pod is validated, and any errors are returned to the user
• The api.Pod is converted to a v6.Pod (because v6 is the latest stable version)
• The v6.Pod is marshalled into JSON and written to etcd
Now that we have the Pod object stored, a user can GET that object in any supported API version. For example −
• A user GETs the Pod from /api/v5/…
• The JSON is read from etcd and unmarshalled into a v6.Pod structure
• Default values are applied to the v6.Pod
• The v6.Pod is converted to an api.Pod structure
• The api.Pod is converted to a v5.Pod structure
• The v5.Pod is marshalled into JSON and sent to the user
The implication of this process is that API changes must be done carefully and backward compatibly.

API Versioning

To make it easier to support multiple structures, Kubernetes supports multiple API versions each at different API path such as /api/v1 or /apsi/extensions/v1beta1
Versioning standards at Kubernetes are defined in multiple standards.
Alpha Level
• This version contains alpha (e.g. v1alpha1)
• This version may be buggy; the enabled version may have bugs
• Support for bugs can be dropped at any point of time.
• Recommended to be employed in short term testing only as the support may not be present all the time.
Beta Level
• The version name contains beta (e.g. v2beta3)
• The code is fully tested and the enabled version is supposed to be stable.
• The support of the feature will not be dropped; there may be some small changes.
• Recommended for only non-business-critical uses because of the potential for incompatible changes in subsequent releases.
Stable Level
• The version name is vX where X is an integer.
• Stable versions of features will appear within the released software for many subsequent versions.
So, this brings us to the end of blog. This Tecklearn ‘Concept of Secrets , Network Policy and Kubernetes API’ blog helps you with commonly asked questions if you are looking out for a job in DevOps. If you wish to learn Kubernetes and build a career in DevOps domain, then check out our interactive, Continuous Orchestration using Kubernetes Training, that comes with 24*7 support to guide you throughout your learning period. Please find the link for course details:

Continuous Orchestration using Kubernetes

Continuous Orchestration using Kubernetes Training

About the Course

Tecklearn has specially designed this Continuous Orchestration using Kubernetes Training Course to advance your skills for a successful career in this domain. Kubernetes training helps you master the container orchestration tool. As part of the training, you will learn detailed Kubernetes, architecture of Kubernetes, what are Kubernetes Pods, node, how to deploy Kubernetes, creating a Kubernetes cluster, what are the various services available and how Kubernetes makes container orchestration simple. You will get an in-depth knowledge of these concepts and will be able to work on related demos. Upon completion of this online training, you will hold a solid understanding and hands-on experience with Kubernetes.

Why Should you take Continuous Orchestration using Kubernetes Training?

• The average salary for people who possess Kubernetes as a skill is $117,000. – PayScale.com
• Apple, Capital One, AT&T, Oracle, Raytheon & many other MNC’s worldwide use Kubernetes across industries.
• The Kubernetes orchestration engine powers some of the biggest and most complex deployments in the world.

What you will Learn in this Course?

Introduction to DevOps
• What is Software Development
• Software Development Life Cycle
• Why DevOps?
• What is DevOps?
• DevOps Lifecycle
• DevOps Tools
• Benefits of DevOps
• How DevOps is related to Agile Delivery
• DevOps Implementation
Continuous Orchestration using Kubernetes
• Containers and Container Orchestration
• Introduction to Kubernetes
• Docker Swarm vs Kubernetes
• Kubernetes Architecture
• Deploying Kubernetes using Kubeadms
• Alternate ways of deploying Kubernetes
• Understanding YAML
• Creating a Deployment in Kubernetes using YAML
• Creating a Service in Kubernetes
• Installing Kubernetes Dashboard
• Deploying an App using Dashboard
• Using Rolling Updates in Kubernetes

527