Cloud Quickstart: Difference between revisions
No edit summary |
No edit summary |
||
Line 87: | Line 87: | ||
==== Services ==== | ==== Services ==== | ||
Since your Pods can come and go as needed, their IP is going to change often. Kubernetes offers a resource called a Service that will allow you to consistently access a Pod or set of Pods by name. You can think of this as a dynamic DNS service. In the Rancher web interface, a service entry will get generated automatically for you anytime you | Since your Pods can come and go as needed, their IP is going to change often. Kubernetes offers a resource called a Service that will allow you to consistently access a Pod or set of Pods by name. You can think of this as a dynamic DNS service. In the Rancher web interface, a service entry will get generated automatically for you anytime you add a '''Port Mapping'''. A good example is creating a database service that can be used by your other Pods in the project: | ||
===== Via Web Interface ===== | ===== Via Web Interface ===== | ||
Line 209: | Line 209: | ||
</div> | </div> | ||
=== Storage === | === Storage === | ||
Docker containers are ephemeral, and any changes you make to them will be lost when they are deleted or replaced. Kubernetes offers options to have your changes survive a Pod restart. I will go over a couple of the most common ones here. | |||
==== Configmaps ==== | |||
Kubernetes offers a key/value store available to your Pods. This is a great way to create configuration files that can be easily updated without having to re-create your whole Docker image. The value can then be mapped to a filename within your Pod(s). As a visual representation of this, the example will create a Nginx Pod with a configmap as the default page. | |||
===== Via Web Interface ===== | |||
<div class="toccolours mw-collapsible mw-collapsed" style="width:400px; overflow:auto;"> | |||
* From the '''Project''' page, select '''Resources->Config Maps''' from the menu at the top | |||
* Click on the '''Add Config Map''' button | |||
* Fill in '''Name''' with <code>default-html</code> | |||
* Make sure '''Namespace''' is filled in | |||
* Fill in '''Key''' with <code>index.html</code> | |||
* Fill in '''Value''' with <code><html><body>Hello World</body></html></code> | |||
* Click on '''Save''' | |||
* From the '''Workloads''' page, click on '''Deploy''' | |||
* Fill in '''Name''' with <code>configmap-example</code> | |||
* Fill in '''Docker Image'' with <code>nginx</code> | |||
* Make sure '''Namespace''' is filled in | |||
* Click on the '''Add Port''' button | |||
* Fill in '''Publish the container port''' with <code>80</code> | |||
* Select in '''As a''' to '''Layer-4 Load Balancer''' | |||
* Fill in '''On listening port''' with <code>80</code> | |||
* Expand the '''Volumes''' section below | |||
* Click on the '''Add Volume...''' button, and select '''Use a config map''' | |||
* Select '''default-html''' from the '''Config Map Name''' drop down list | |||
* Fill in '''Mount Point''' with <code>/usr/share/nginx/html</code> | |||
* Fill in '''Default Mode''' with <code>644</code> | |||
* Click on '''Launch''' | |||
* Once your Pod is ready and accessible, you will notice that Nginx is serving out the "Hello World" contents of your Config Map. You can now update the contents of your Config Map and see the change to your website. Your changes will survive any Pod restarts. | |||
</div> | |||
===== Via Command Line ===== | |||
<div class="toccolours mw-collapsible mw-collapsed" style="width:400px; overflow:auto;"> | |||
* Create a <code>configmap-example.yml</code> file, you will need personalize '''namespace''': | |||
<pre> | |||
apiVersion: v1 | |||
data: | |||
index.html: <html><body>Hello World</body></html> | |||
kind: ConfigMap | |||
metadata: | |||
name: default-html | |||
namespace: user-project1-web | |||
--- | |||
apiVersion: v1 | |||
kind: Pod | |||
metadata: | |||
name: configmap-example | |||
namespace: user-project1-web | |||
labels: | |||
app: confimap-example | |||
spec: | |||
containers: | |||
- name: configmap-example | |||
image: nginx | |||
stdin: true | |||
tty: true | |||
volumeMounts: | |||
- mountPath: /usr/share/nginx/html | |||
name: vol1 | |||
volumes: | |||
- configMap: | |||
defaultMode: 644 | |||
name: default-html | |||
optional: false | |||
name: vol1 | |||
--- | |||
apiVersion: v1 | |||
kind: Service | |||
metadata: | |||
name: configmap-example | |||
namespace: user-project1-web | |||
spec: | |||
ports: | |||
- name: http | |||
port: 80 | |||
protocol: TCP | |||
targetPort: 80 | |||
selector: | |||
app: web-example | |||
type: LoadBalancer | |||
</pre> | |||
* This manifest will do two things: Create a Pod running the hello-world Docker image labeled with '''app: web-example''' and Create an external Service entry that points to any Pod labeled '''app: web-example''' | |||
* Apply this manifest to create the resources: <code>kubectl apply -f web-example.yml</code> | |||
* To get the status of your Pod(s): <code>kubectl get pod -n <namespace></code> | |||
* To get the status of your Service(s): <code>kubectl get service -n <namespace></code> | |||
* You should see the external IP of '''web-example''' service | |||
</div> |
Revision as of 11:50, 8 April 2019
CS Cloud Quickstart Guide
This guide will give you an introduction to using the Computer Science cloud, instructions on starting a simple kubernetes pod, basic networking concepts, and how to use storage. We will show how to do things both in the web user interface and through command line access.
Introduction
The CS cloud is a container-as-a-service resource. It allows you to run Docker based containers on our hardware. Containers allow you to encapsulate your application with all it's needed dependencies and allows the containerized application to run just about anywhere. The CS cloud is based on Kubernetes cluster which is a open-source container orchestration system. We also use Rancher as a UI and proxy interface.
Accessing the Cloud
You access the CS cloud through https://cloud.cs.vt.edu By default, all users get access to the "testing" cluster. This cluster is available for users to play with kubernetes, develop their containerized applications, and Techstaff to test updates to the system. Critical services should not be run on this cluster, we will have other clusters available to actually run containerized user services. You can also use the Rancher UI to control your own kubernetes cluster(s) allowing you to share your personal cluster with others in the department. This can even work behind a private network.
API/Command line access
You can also access the CS cloud via a command line tool called kubectl
.
- Install the kubectl binary on your machine https://kubernetes.io/docs/tasks/tools/install-kubectl/
- You will need a config file to tell kubectl how to connect to the CS cloud, download this file from the Web interface
- Log into https://cloud.cs.vt.edu
- Select the cluster you want to access from the top left menu
- Click on the Cluster menu item at the top, if you are not already there
- Click on the Kubeconfig File button
- You can either download the file or copy and paste the content into your kubectl config file (normally ~/.kube/config on Linux)
- You can also directly access
kubectl
command line directly from the web interface! Just click on the Launch kubectl button.
Creating a Project
When you first log into https://cloud.cs.vt.edu it will show you the clusters you have access to. Normally, this will only be the testing cluster. Also, you won't have any Projects unless someone has shared a Project with you. To get started, you will need to create a Project and a Namespace inside that project:
The Project will need to be created through the web interface.
- Select testing cluster by either clicking the name in the list, or selecting it from the top left menu (Global -> Cluster: testing).
- Select Projects/Namespaces on the top menu
- Click on the Add Project button to create a Project
- Project Name is the only required field, this is set at the cluster scope so the name can conflict with other users' project names. I suggest pre-appending your username to the project name, for example:
mypid-project1
- After you create your project, it will take you to a screen that will allow you to add a namespace to your project.
- Namespaces allow you to group Pods and other resources together, this namespace translates to the Kubernetes namespace so again the names can conflict with other users. Example namespace name:
mypid-project1-db
for grouping all of project1's database pods together. - Click on the Add Namespace button to create a Namespace
- Name is the only field needed
- Click on the Project's title or use the top left menu to select your new Project. This will take you to the Project's page.
- At this point you are ready to start a Pod
Starting a Deployment
Kubernetes groups containers into a Pod. A Pod can be thought of roughly as a single machine with a single IP on the Kubernetes network. Each container running in a Pod can communicate with each other via localhost. The simplest Pod is just a single container, which is what we will show you here. A Deployment is a kubernetes term for a Pod resource that can automatically scale out. For our example, we will only be starting a single Pod.
Example: Ubuntu shell
In this example, we will show how to start up a Ubuntu container and access it as a shell prompt.
Via Web Interface
Via Command Line
Networking
The CS cloud automatically sets up access to the cluster network when you start a Pod. Your Pod gets a random internal IPv4 address that can access other Pods in the cluster network, and the Internet via a gateway. There are also options to access your Pod(s) from external hosts.
Services
Since your Pods can come and go as needed, their IP is going to change often. Kubernetes offers a resource called a Service that will allow you to consistently access a Pod or set of Pods by name. You can think of this as a dynamic DNS service. In the Rancher web interface, a service entry will get generated automatically for you anytime you add a Port Mapping. A good example is creating a database service that can be used by your other Pods in the project:
Via Web Interface
Via Command Line
Externally Accessible Services
The CS cloud offers options for externally accessing your services. This will vary based on which cluster you are using. This example will be using the Testing cluster. By default, when you create an externally accessible service in the Testing cluster, you will get a randomly assigned external IPv6 address. There are other options available, but they will be reserved for special use cases. Contact Techstaff if you have a special network use case. In this example, we will create a simple web page that will be externally accessible via IPv6:
Via Web Interface
Via Command Line
Storage
Docker containers are ephemeral, and any changes you make to them will be lost when they are deleted or replaced. Kubernetes offers options to have your changes survive a Pod restart. I will go over a couple of the most common ones here.
Configmaps
Kubernetes offers a key/value store available to your Pods. This is a great way to create configuration files that can be easily updated without having to re-create your whole Docker image. The value can then be mapped to a filename within your Pod(s). As a visual representation of this, the example will create a Nginx Pod with a configmap as the default page.