Magnum的使用

1.Prepare your session to be able to use the various openstack clients including magnum, neutron, and glance. 

Create a new shell, and source the devstack openrc script::

source /opt/stack/devstack/openrc admin admin

    Magnum has been tested with the Fedora Atomic micro-OS and CoreOS. Magnum will likely work with other 
micro-OS platforms, but each requires individual support in the heat template.

2.The Fedora Atomic micro-OS image will automatically be added to glance.  You can add additional images 

manually through glance. To verify the image created when installing devstack use::

glance image-list</span>

  +--------------------------------------+---------------------------------+-------------+------------------+-----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size      | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+-----------+--------+
  | 7f5b6a15-f2fd-4552-aec5-952c6f6d4bc7 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824  | active |
  | bd3c0f92-669a-4390-a97d-b3e0a2043362 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632   | active |
  | 843ce0f7-ae51-4db3-8e74-bcb860d06c55 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163   | active |
  | 02c312e3-2d30-43fd-ab2d-1d25622c0eaa | fedora-21-atomic-3              | qcow2       | bare             | 770179072 | active |
  +--------------------------------------+---------------------------------+-------------+------------------+-----------+--------+

3. Create a keypair for use with the baymodel::

test -f ~/.ssh/id_rsa.pub || ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
    nova keypair-add --pub-key ~/.ssh/id_rsa.pub testkey


4.Create a baymodel. This is similar in nature to a flavor and describes to magnum how to construct the bay. The coe (Container Orchestration Engine) and keypair need to be specified for the baymodel::
magnum baymodel-create --name k8sbaymodel \
                           --image-id fedora-21-atomic-3 \
                           --keypair-id testkey \
                           --external-network-id ${NIC_ID} \
                           --dns-nameserver 8.8.8.8 \
                           --flavor-id m1.small \
                           --docker-volume-size 5 \
                           --coe kubernetes



5.Create a bay. Use the baymodel name as a template for bay creation. This bay will result in one master kubernetes node and one minion node::

magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 1

    Bays will have an initial status of CREATE_IN_PROGRESS.  Magnum will update the status to CREATE_COMPLETE when it is done creating the bay.  Do not create containers, pods, services, or replication controllers before magnum finishes creating the bay.  They will likely not be created, and may cause magnum to become confused.



6. The existing bays can be listed as follows::
magnum bay-list

    +--------------------------------------+---------+------------+-----------------+
    | uuid                                 | name    | node_count | status          |
    +--------------------------------------+---------+------------+-----------------+
    | 9dccb1e6-02dc-4e2b-b897-10656c5339ce | k8sbay  | 1          | CREATE_COMPLETE |
    +--------------------------------------+---------+------------+-----------------+


7. More detailed information for a given bay is obtained via::
magnum bay-show k8sbay

    After a bay is created, you can dynamically add/remove node(s) to/from the bay by updating the node_count attribute. For example, to add one more node::

magnum bay-update k8sbay replace node_count=2

    Bays in the process of updating will have a status of UPDATE_IN_PROGRESS. Magnum will update the status to UPDATE_COMPLETE when it is done updating the bay.

8. A bay can be deleted as follows::
magnum bay-delete k8sbay

    Note: If you choose to reduce the node_count, magnum will first try to remove empty nodes with no containers running on them. If you reduce node_count by more than the number of empty nodes, magnum must remove nodes that have running containers on them. This 
action will delete those containers. We strongly recommend using a replication controller before reducing the node_count so any  removed containers can be automatically recovered on your remaining nodes.