Docker cheet sheet

11:02:00 AM No comments
Docker Cheat Sheet is a nice documentation. It provides us Docker basic commands and system and It's easy to understand. But there are less exaples, I reconstructed it with real examples. 

Set up

Pull a base image.
docker pull ubuntu
It's annoy to restore Container ID, you may forget to restore. You can set below alias. With this, you can get the ID of the last-run Container (15 Docker tips in 5 minutes)
alias dl='docker ps -l -q'

Container

To create a Container.
docker run -d ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
To stop a Container.
docker stop `dl`
To start a Container.
docker start `dl`
To restart a Container.
docker restart `dl`
To Connect to a running Container.
docker attach `dl`
To copy file in a Container to the host.
docker cp `dl`:/etc/passwd .
To mount the directory in host to a Container.
docker run -v /home/vagrant/test:/root/test ubuntu echo yo
To delete a Container.
dockr rm `dl`

Info of Container

To show running Containers. With -a option, it shows running and stopped Containers.
docker ps
To show Container information like IP adress.
docker inspect `dl`
To show log of a Container.
docker logs `dl`
To show running process in a Container.
docker top `dl`

Image

To create a image from a Container. For tag name, <username>/<imagename> isrecommended.
docker run -d ubuntu /bin/sh -c "apt-get install -y hello"
docker commit -m "My first container" `dl` tcnksm/hello
To create a image with Dockerfile.
echo -e "FROM base\nRUN apt-get install hello\nCMD hello" > Dockerfile
docker build tcnksm/hello .
To login to a image.
docker run -rm -t -i tcnksm/hello /bin/bash
To push a imges to remote repository. You need to sign up to Docker index in advance. Exmple uploaded image.
docker login
docker push tcnksm/hello
To delete a image
docker rmi tcnkms/hello

Info of Image

To show all images

What is a Docker Container?  In Part 1 of this series, we explore the Docker open source project.  Visit Part 2, to learn how Docker open sources containers work.


Docker container is an open source software development platform. Its main benefit is to package applications in “containers,” allowing them to be portable among any system running the Linux operating system (OS).


Container technology has been around for a while, but momentum and hype around Docker’s approach to containers has pushed this approach to the forefront in the last year. It is one form of container technology.

docker images
To show image information like IP adress.
docker inspect tcnksm/hello
To show command history of a image.
docker history tcnksm/hello

No comments :

Post a Comment

Adding User in ubuntu

10:38:00 AM , No comments

What are User and Group Permissions?
Linux/Unix operating systems have the ability to multitask in a manner similar to other operating systems. However, Linux’s major difference from other operating systems is its ability to have multiple users. Linux was designed to allow more than one user to have access to the system at the same time. In order for this multiuser design to work properly, there needs to be a method to protect users from each other. This is where permissions come in to play.

Read, Write & Execute Permissions
Permissions are the “rights” to act on a file or directory. The basic rights are read, write, and execute.

Read - a readable permission allows the contents of the file to be viewed. A read permission on a directory allows you to list the contents of a directory.
Write - a write permission on a file allows you to modify the contents of that file. For a directory, the write permission allows you to edit the contents of a directory (e.g. add/delete files).
Execute - for a file, the executable permission allows you to run the file and execute a program or script. For a directory, the execute permission allows you to change to a different directory and make it your current working directory. Users usually have a default group, but they may belong to several additional groups.
Viewing File Permissions
To view the permissions on a file or directory, issue the command ls -l <directory/file>. Remember to replace the information in the < > with the actual file or directory name. Below is sample output for the ls command:

1
-rw-r--r-- 1 root root 1031 Nov 18 09:22 /etc/passwd
The first ten characters show the access permissions. The first dash (-) indicates the type of file (d for directory, s for special file, and - for a regular file). The next three characters (rw-) define the owner’s permission to the file. In this example, the file owner has read and write permissions only. The next three characters (r–) are the permissions for the members of the same group as the file owner (which in this example is read only). The last three characters (r–) show the permissions for all other users and in this example it is read only.

Working with Users, Groups, and Directories
The following sections will go over the commands needed to create, delete, and modify user accounts. Groups will be covered, as well as commands for creating and deleting directories. You will be provided with the commands and descriptions needed for working with users, groups, and directories.

Creating and Deleting User Accounts
To create a new standard user, use the useradd command. The syntax is as follows:

1
useradd <name>
The useradd command utilizes a variety of variables, some of which are shown in the table below:

Option Description Example
-d <home_dir> home_dir will be used as the value for the user’s login directory useradd <name> -d /home/<user's home>
-e <date> the date when the account will expire user add <name>** -e <YYYY-MM-DD>
-f <inactive> the number of days before the account expires useradd <name> -f <0 or -1>
-s <shell> sets the default shell type useradd <name> -s /bin/<shell>
You will need to set a password for the new user by using the passwd command. Note, you will need root privileges to change a user password. The syntax is as follows:

1
passwd <username>
The user will be able to change their password at any time using the passwd command with the syntax. Below is an example:

1
2
3
4
5
6
$ passwd
Changing password for lmartin.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
There is another way of creating user accounts that might be easier for first-time administrators. However, you may need to install a new package. The installation command for Debian/Ubuntu is as follows:

1
apt-get install adduser
The adduser command automatically creates a home directory and sets the default group, shell, etc. To create a new standard user with the adduser command the syntax is as follows:

1
adduser <name>
Once you enter the command you will receive a series of prompts; most of this information is optional. However, you should include at least the user’s name (for this example the user name is cjones) and of course a password.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
root@localhost:~# adduser cjones
  Adding user `cjones' ...
  Adding new group `cjones' (1001) ...
  Adding new user `cjones' (1001) with group `cjones' ...
  Creating home directory `/home/cjones' ...
  Copying files from `/etc/skel' ...
  Enter new UNIX password:
  Retype new UNIX password:
  passwd: password updated successfully
  Changing the user information for cjones
  Enter the new value, or press ENTER for the default
      Full Name []: Chuck Jones
      Room Number []: 213
      Work Phone []: 856-555-1212
      Home Phone []:
      Other []:
  Is the information correct? [Y/n] Y
It is important to note that security should always be taken very seriously. Therefore, it is strongly recommended to use unique passwords for each account. Never share or give your password to other users.

To remove a user account, enter the following command:

1
userdel <name>
Issuing the command above will only delete the user’s account. Their files and home directory will not be deleted.

To remove the user, their home folder, and their files, use this command:

1
userdel -r <name>
Understanding Sudo
Root is the super user and has the ability to do anything on a system. Therefore, in order to have protection against potential damage sudo is used in place of root. Sudo allows users and groups access to commands they normally would not be able to use. Sudo will allow a user to have administration privileges without logging in as root. A sample of the sudo command is as follows:

1
sudo apt-get install <package>
Before using sudo, it may need to be installed if it is not part of your distribution. The command for Debian is as follows:

1
apt-get install sudo
For CentOS, the command is as follows:

1
yum install sudo
In order to provide a user with sudo ability, their name will need to be added to the sudoers file. This file is very important and should not be edited directly with a text editor. If the sudoers file is edited incorrectly it could result in preventing access to the system.

Therefore the visudo command should be used to edit the sudoers file. At a command line, log into your system as root and enter the command visudo.

Below is the portion of the sudoers file that shows the users with sudo access.

1
2
3
4
5
# User privilege specification
root    ALL=(ALL:ALL) ALL
cjones  ALL=(ALL:ALL) ALL
kbrown  ALL=(ALL:ALL) ALL
lmartin ALL=(ALL:ALL) ALL
After you have given your user account sudo privileges, save the sudoers file and log out as root. Now log in as your user and test the privileges as your user with sudo access. When a new user needs sudo access, you will now be able to edit the sudoers file with your own login using the following command:

1
sudo visudo
Working with Groups
Linux uses groups as a way to organize users. Groups organize collections of accounts, primarily as a security measure. Control of group membership is administered through the /etc/group file, which shows a list of groups and its members. Every user has a default or primary group. When a user logs in, the group membership is set for their primary group. This means that when a user launches a program or creates a file, both the file and the running program will be associated with the user’s current group membership. A user may access other files in other groups, as long as they are also a member of that group and the access permissions are set. To run programs or create a file in a different group, the user must run the newgrp command to switch their current group. A sample of the newgrp command is as follows:

1
$ newgrp <marketing>
If the user entering the above-referenced command is a member of the marketing group in the /etc/group file, then the current group membership will change. It is important to note that any files created will now be associated with the marketing group rather than the user’s primary group. Users may also change their group by using the chgrp command. The syntax for the chgrp command is as follows:

1
$ chgrp <newgroup>
Creating and Removing Directories
To make a directory use the command:

1
mkdir <directory name>
To make a directory and set the permissions at the same time, use the following option and syntax:

1
mkdir -m a=rwx <directory name>
The -m option is short for mode, and a=rwx means that all users have read, write, and execute permissions on the directory. To see a complete list of all options for the mkdir command enter man mkdir at a command prompt.

To remove a file, use the following:

1
rm <file>
To remove a directory:

1
rm -r <directory name>
It is important to note that if you remove a directory all the files inside will be deleted as well.

Changing Directory and File Permissions
To view file permissions and ownership on files and directories, use the ls -al command. The a option is to show hidden files or all files, and the l option is for the long listing. The output will be similar to the following:

1
2
3
drwxr-xr-x 2 user user 4096 Jan  9 10:11 documents
-rw-r--r-- 1 user user  675 Jan  7 12:05 .profile
drwxr-xr-x 4 user user 4096 Jan  7 14:55 public
The first column with the ten letters and dashes shows the permissions of the file or directory. The second column (with the single number) indicates the number of files or directories contained in the directory. The next column indicates the owner, followed by the group name, the size, date, and time of last access, and finally the name of the file . For example, using the first line from the output above, the details are as follows:

1
2
3
4
5
6
7
``drwxr-xr-x`` are the permissions
``2`` is the number of files or directories
``user`` is the owner
``user`` is the group
``4096`` is the size
``Jan  9 10:11`` is the date/time of last access
``documents`` is the directory
Since a directory itself is a file, any directory will always show 4096 as it’s size. This does not reflect the size of the contents of the directory.
Chmod Command
The command chmod is short for change mode. Chmod is used to change permissions on files and directories. The command chmod may be used with either letters or numbers (also known as octal) to set the permissions. The letters used with chmod are in the table below:

Letter Permission
r Read
w Write
x Execute
X Execute (only if file is a directory)
s Set user or group ID on execution
t Save program text on swap device
u Current permissions the file has for owner
g Current permissions the file has for users in the same group
o Current permissions the file has for others not in the group
It is important to remember that the first character of the first column of a file listing denotes whether it is a directory or a file. The other nine characters are the permissions for the file/directory. The first three characters are for the user, the next three are for the group, and the last three are for others. The example drwxrw-r– is broken down as follows:

d is a directory

rwx the user has read, write, and execute permissions

rw- the group has read and write permissions

r– all others have read only permissions
Note that the dash (-) denotes permissions are removed. Therefore, with the “all others” group, r– translates to read permission only, the write and execute permissions were removed.

Conversely, the plus sign (+) is equivalent to granting permissions: chmod u+r,g+x <filename>

The example above translates as follows:

1
2
3
4
u is for user
r is for read
g is for group
x is for execute
In other words, the user was given read permission and the group was given execute permission for the file. Note, when setting multiple permissions for a set, a comma is required between sets.

Chmod Octal Format
To use the octal format, you have to calculate the permissions for each portion of the file or directory. The first ten characters mentioned above will correspond to a four digit numbers in octal. The execute permission is equal to the number one (1), the write permission is equal to the number two (2), and the read permission is equal to the number four (4). Therefore, when you use the octal format, you will need to calculate a number between 0 and 7 for each portion of the permission. A table has been provided below for clarification.

Octal format for permissions.

Although octal format may seem difficult to understand, it is easy to use once you get the gist of it. However, setting permissions with r, w, and x may be easier. Below are examples of how to use both letters and octal format to set permissions on a file or directory.

Sample syntax: chmod <octal or letters> <file/directory name>

Letter format: chmod go-rwx Work (Deny rwx permission for the group and others)
The output of ls -al after the chmod command above would looks as follows:

1
dr-------- 2 user user 4096 Dec 17 14:38 Work
Octal format: chmod 444 Work

The output of ls -al after the chmod command above would look as follows:

1
dr--r--r-- 2 user user 4096 Dec 17 14:38 Work
An octal table showing the numeric equivalent for permissions is provided below.

Numeric permissions table.

Additional File Permissions
In addition to the most common read/write/execute file permissions, there are some additional modes that you might find useful, specifically the +t mode (sticky bit) and the +s mode (setuid bit). These functions describe the behavior of files and executables in multi-user situations.

When set on a file or directory, the sticky bit, or +t mode, means that only the owner (or root) can delete the file, regardless of which users have write access to this file/directory by way of group membership or ownership. This is useful when a file or directory is owned by a group through which a number of users share write access to a given set of files.

To set the sticky bit on a file named /root/sticky.txt, issue the following command:

1
chmod +t /root/sticky.txt
To remove the sticky bit from a file, use the chmod -t command. Note, to change the sticky bit, you need to be either root or the file owner. The root user will be able to delete files regardless of the status of the sticky bit.

The setuid bit, or +s, when set on files allows users with permissions to execute a given file the ability to run that file with the permissions of file owner. For instance, if the file work was owned by the root user and the marketing group, members of the marketing group could run the work program as if they were the root user. This may pose potential security risks in some cases and executables should be properly evaluated before receiving the +s flag. To set the +s bit on a file named /usr/bin/work, issue the following command:

1
chmod g+s /usr/bin/work
In contrast to the +s mode for the ownership of a file, the effect of the +s mode on a directory is somewhat different. Files created in +s directories receive the ownership of that directory’s user and group, rather than the ownership of the user that created the file and their default group. To set the setguid (group id) option on a directory, use the following command:

1
chmod g+s /var/doc-store/
To set the setuid (user id) for a directory named /var/doc-store, issue the following command:

1
chmod o+s /var/doc-store/
Changing File Ownership
By default, all files are “owned” by the user who creates them and by that user’s default group. To change the ownership of a file, use the chown command in the chown user:group /path/to/file format. In the following example, the ownership of the “list.html” file will be changed to the “cjones” user in the “marketing” group:

1
chown cjones:marketing list.html
To change the ownership of a directory and all the files contained inside, use the recursive option with the -R flag. In the following example, change the ownership of /srv/smb/leadership/ to the “cjones” user in the “marketing” group:

1
chown -R cjones:marketing /srv/smb/leadership/
Leveraging Users and Groups
In many cases, user permissions are used to provide your system with greater security without any direct interaction. Many operating systems create specific system user accounts for different packages during the installation process.

The best practice is to give each user their own login to your system. This protects each user’s files from all other users. Furthermore, using specific accounts for users allows more accurate system logging, particularly when combined with tools like sudo. We recommend avoiding situations where more than one individual knows the password for a user account for maximum security.

In contrast, groups are useful for allowing multiple independent user accounts to collaborate and share files. If you create groups on a machine for common tasks on a per-task basis (e.g. web editors, contributors, content submitters, support) and add relevant users to the relevant groups, these users can all edit and run the same set of files without sharing these files with the world. Use of the chown command with file permissions of 770 and 740 would help accomplish this goal.


No comments :

Post a Comment

Facing issue in sudo apt-get in container ,image

10:13:00 AM , , No comments
First check if you have connection, ping directly to ip 91.189.92.201 that archive.ubuntu.com is pointed to:
ping 91.189.92.201
If you still can't reach the host it's not a dns problem.
Also if you have internet connection, you can make a hack. Just put a row into /etc/hosts file and problem solved:
91.189.92.201 archive.ubuntu.com

some other basic concepts of linux

Keep in mind that the following commands are just a few of the many that exist. I included these because they are often the most frequently used. If you would an entire list go here.

cal-display a calendar
cat-display contents of a file
cd-change directory
chmod-change access permisions
clear-clear the terminal screen
cp-copy file(s) to another location
date-display date
echo-display a message in the terminal screen
exit-close the terminal window
find-search for file(s)
install-(this is where common sense is used...)
ls-list info for file(s) from whatever directory you are in
man-help
netstat-displays network statistics
ping-test network connection
su-change to root user
su (user name)-change to name in parentathes
wget-retrieve files from the internet 

No comments :

Post a Comment

External networking for Kubernetes services

8:40:00 PM No comments
I have recently started running some "real" services (that is, "services being consumed by someone other than myself") on top of Kubernetes (running on bare metal), which means I suddenly had to confront the question of how to provide external access to Kubernetes hosted services. Kubernetes provides two solutions to this problem, neither of which is particularly attractive out of the box:
  1. There is a field createExternalLoadBalancer that can be set in a service description. This is meant to integrate with load balancers provided by your local cloud environment, but at the moment there is only support for this when running under GCE.
  2. A service description can have a list of public IP addresses associated with it in the publicIPS field. This will causekube-proxy to create rules in the KUBE-PROXY chain of your nat table to direct traffic inbound to those addresses to the appropriate local kube-proxy port.
The second option is a good starting point, since if you were to simply list the public IP addresses of your Kubernetes minions in the publicIPs field, everything would Just Work. That is, inbound traffic to the appropriate port on your minions would get directed to kube-proxy by the nat rules. That's great for simple cases, but in practice it means that you cannot have more that N services exposed on a given port where N is the number of minions in your cluster. That limit is difficult if you -- like I do -- have an all-in-one (e.g., on a single host) Kubernetes deployment on which you wish to host multiple web services exposed on port 80 (and even in a larger environment, you really don't want "number of things on port XX" tightly coupled to "number of minions").

Introducing Kiwi

To overcome this problem, I wrote Kiwi, a service that listens to Kubernetes for events concerning new/modified/deleted services, and in response to those events manages (a) the assignment of IP addresses to network interfaces on your minions and (b) creating additional firewall rules to permit traffic inbound to your services to pass a default-deny firewall configuration.
Kiwi uses etcd to coordinate ownership of IP addresses between minions in your Kubernetes cluster.

How it works

Kiwi listens to event streams from both Kubernetes and Etcd.
On the Kubernetes side, Kiwi listens to /api/v1beta/watch/services, which produces events in response to new, modified, or deleted services. The Kubernetes API uses a server-push model, in which a client makes a single HTTP request and then receives a series of events over the same connection. A event looks something like:
{
  "type": "ADDED",
  "object": {
    "portalIP": "10.254.93.176",
    "containerPort": 80,
    "publicIPs": [
      "192.168.1.100"
    ],
    "selector": {
      "name": "test-web"
    },
    "protocol": "TCP",
    "port": 8080,
    "kind": "Service",
    "id": "test-web",
    "uid": "72bc1286-a440-11e4-b83e-20cf30467e62",
    "creationTimestamp": "2015-01-24T22:15:43-05:00",
    "selfLink": "/api/v1beta1/services/test-web",
    "resourceVersion": 245,
    "apiVersion": "v1beta1",
    "namespace": "default"
  }
}
I am using the Python requests library, which it turns out has a bug in its handling of streaming server responses, but I was able to work around that issue once I realized what was going on.
On the Etcd side, Kiwi uses keys under the /kiwi/publicips prefix to coordinate address ownership among Kiwi instances. It listens to events from Etcd regarding key create/delete/set/etc operations in this prefix by calling/v2/keys/kiwi/publicips?watch=true&recursive=true. This is a long-poll request, rather than a streaming request: that means that a request will only ever receive a single event, but it may need to wait for a while before it receives that response. This model worked well with the requests library out of the box.
After receiving an event from Kubernetes, Kiwi iterates over the public IP addresses in the publicIPs key, and for any address that is not already being manged by the local instance it makes a claim on that address by attempting to atomically create a key in etcd under /kiwi/publicips/ (such as /kiwi/publicips/192.168.1.100). If this attempt succeeds, Kiwi on the local minion has claimed that address and proceeds to assign it to the local interface. If the attempt to set that key does not succeed, it means the address is already being managed by Kiwi on another minion.
The address keys are set with a TTL of 20 seconds, after which they will be expired. If an address expires, other Kiwi instances will receive notification from Etcd and ownership of that address will transfer to another Kiwi instance.

Getting started with Kiwi

The easiest way to get started with Kiwi is to use the larsks/kiwi Docker image that is automatically built from the Git repository. For example, if you want to host public ip addresses on eth0 in the range 192.168.1.32/28, you would start it like this:
docker run --privileged --net=host larsks/kiwi \
  --interface eth0 \
  --range 192.168.1.32/28
You need both --privileged and --net=host in order for Kiwi to assign addresses to your host interfaces and to manage the iptables configuration.

An Example

Start Kiwi as described above. Next, plae the following content in a file called service.yaml:
kind: Service
apiVersion: v1beta1
id: test-web
port: 8888
selector:
  name: test-web
containerPort: 80
publicIPs:
  - 192.168.1.100
Create the service using kubectl:
kubectl create -f service.yaml
After a short pause, you should see the address show up on interface eth0; the entry will look something like:
inet 192.168.1.100/32 scope global dynamic eth0:kube
       valid_lft 17sec preferred_lft 17sec
The eth0:kube is a label applied to the address; this allows Kiwi to clean up these addresses at startup (by getting a list of Kiwi-configured addresses with ip addr show label eth0:kube).
The valid_lft and preferred_lft fields control the lifetime of the interface. When these counters reach 0, the addresses are removed by the kernel. This ensure that if Kiwi dies, the addresses can successfully be re-assigned on another node.

No comments :

Post a Comment

Setup SkyDNS on a Kubernetes Cluster

8:17:00 PM No comments


SkyDNS

Today we’re releasing SkyDNS as an open source project on github. SkyDNS is our attempt to solve the problem of finding the services that are running in a large environment. SkyDNS acts as a DNS service that only returns SRV records. Services announce their availability by sending a POST with a small JSON payload. Each service has a Time to Live that allows SkyDNS to expire records for services that haven’t updated their availability within the TTL window. Services can send a periodic POST to SkyDNS updating their TTL to keep them in the pool.
Now when services die, hosts die, datacenters die, or meteors fall, your clients won’t be wasting valuable time making requests to services that aren’t running or aren’t reachable.
When a client is looking for a particular service, it issues a DNS request to SkyDNS with the particulars of the service needed. SkyDNS supports several interesting parameters in the SRV record to facilitate returning the service that is best situated to serve the client.

Environment

SkyDNS understands the last parameter in the DNS query as an Environment. You can put any value here, but for our purpose, words like development, staging, qa, production, and integration make the most sense. The environment parameter allows you to segregate your services so that you can run a single SkyDNS service cluster but serve your entire development environment.

Service

The Service parameter is the name of the service that is running. Yours might be called addressvalid if you’re running an address validation service, or it could be called indexentries if you’re running a service that indexes documents in the background. The service name is the unique name that identifies WHAT your service does.

Version

Services can be versioned to allow for variations in the request/response data without breaking backwards compatibility. The version parameter allows you to request a specific version of a service.

Region

We run services in multiple data centers, so SkyDNS understands locality of a service. Services register themselves as running in a specific region, which allows clients to request a service running in the same region. If you’re running the same service in multiple regions, SkyDNS will use the priority field in the SRV record to return services in the requested region first, with the same priority. Services running in different regions are returned at a lower priority so that the client can use them in case they’re needed but prefer the local services first.

Host

SkyDNS understands the host that a service is running on so that if a client prefers it, the client can request a service on the same host.

UUID

Services are required to have a unique identifier, which allows multiple services at the same version to be running on the same host. If you really wanted to request a specific instance of a service you can specify the UUID in the request and you’ll only receive that specific instance.

Wildcards

The only field that is required in the DNS request is the “Environment” field. Any missing fields are interpreted as “any”, and you can specify “any” at any point along the parameter list.

Introduction

Other tutorials on DevOps Central describe how to manually deploy a Kubernetes cluster on various platforms.
By default, the containers allows for service discovery through the use of dynamic environment variables that are similar to the Docker syntax. For example:
APP_SERVICE_HOST=<app host>
APP_SERVICE_PORT=<app port>
Kubernetes also provides support for a cluster DNS add-on. When this add-on is enabled, Kubernetes Services will automatically create associated DNS records that are resolvable within the containers.
The format of the DNS record is service_name.namespace.cluster_domain. Based on this tutorial, for example, a redis-master Service may use the following domain (assuming the default namespace is being used):
redis-master.default.kubernetes.local

Requirements

  • Functional Kubernetes cluster
  • Kubernetes container subnet: 10.254.0.0/16
  • Kubernetes DNS IP address: 10.254.0.10
  • Kubernetes domain name: kubernetes.local
Note: If you chose another container subnet in your existing Kubernetes cluster, then the skydns PortalIP must reside in that subnet and the Kubelet startup parameter --cluster_dns must match that IP address.

Create Replication Controller Manifest

The Replication Controller manifest will describe the state of the containers within the Pod as well as the number of replicas. The skydns Pod will consist of three containers:
  • etcd - Stores the SkyDNS configuration and DNS records.
  • skydns - The DNS server responding to requests.
  • kube2sky - A bridge between Kubernetes and SkyDNS.
Create a file called skydns-rc.yaml and paste in the following YAML text:
kind: ReplicationController
apiVersion: v1beta1
id: skydns
namespace: default
labels:
  k8s-app: skydns
desiredState:
  replicas: 1
  replicaSelector:
    k8s-app: skydns
  podTemplate:
    labels:
      k8s-app: skydns
    desiredState:
      manifest:
        version: v1beta2
        id: skydns
        dnsPolicy: "Default"
        containers:
          - name: etcd
            image: quay.io/coreos/etcd:latest
            command: [
              "/etcd",
              "-bind-addr=127.0.0.1",
              "-peer-bind-addr=127.0.0.1",
            ]
          - name: kube2sky
            image: kubernetes/kube2sky:1.0
            command: [
              # entrypoint = \"/kube2sky\",
              "-domain=kubernetes.local",
            ]
          - name: skydns
            image: kubernetes/skydns:2014-12-23-001
            command: [
              # entrypoint = \"/skydns\",
              "-machines=http://localhost:4001",
              "-addr=0.0.0.0:53",
              "-domain=kubernetes.local.",
            ]
            ports:
              - name: dns
                containerPort: 53
                protocol: UDP

Create Service Manifest

The Service manifest will expose the DNS service IP address and port to other containers within the cluster.
Create a new service file called skydns-svc.yaml and paste in the following YAML text.
kind: Service
apiVersion: v1beta1
id: skydns
namespace: default
protocol: UDP
port: 53
portalIP: 10.254.0.10
containerPort: 53
labels:
  k8s-app: skydns
selector:
  k8s-app: skydns

Load the Manifests

The manifest files are now ready to be loaded into Kubernetes using the kubectl command.
kubectl create -f ./skydns-rc.yaml
kubectl create -f ./skydns-svc.yaml
The kubectl command can also be used to confirm the state of the new skydns Replication Controller, Pod, and Service.
kubectl get rc
kubectl get pods
kubectl get service

Configure the Kubelet Services

Cluster DNS must now be enabled on all the container nodes. This is done by adding two startup parameters to the Kubelet service. Open the kubelet configuration file on each host and add the following two parameters:
  • --cluster_dns=10.254.0.10
  • --cluster_domain=kubernetes.local
The location of the kubelet configuration file may vary along with the parameter syntax depending on the Linux distribution. For example:

Kubelet on CentOS 7

The /etc/kubernetes/kubelet file should contain the following:
KUBELET_ARGS="--cluster_dns=10.254.0.10 --cluster_domain=kubernetes.local"

Kubelet on Ubuntu

The /etc/default/kubelet may appear similar to this example:
KUBELET_OPTS="--address=0.0.0.0 \
--port=10250 \
--hostname_override=kube-minion \
--etcd_servers=http://kube-master:4001 \
--enable_server=true \
--cluster_dns=10.254.0.10 \
--cluster_domain=kubernetes.local \
--v=0"

Restart the Kubelet

Finally, restart the Kubelet to enable cluster DNS. To restart the service on CentOS:
systemctl restart kubelet
And to restart the service on Ubuntu:
service docker restart
SOURCE

No comments :

Post a Comment

Subscribe to: Posts ( Atom )